{"push_id":780848921,"size":8,"distinct_size":4,"ref":"refs/heads/mand-lock","head":"269ea595db383189239e2582016583f7e2055d3b","before":"23e9b65fb8eafbda3a7ceca8907613221685b38c","commits":[{"sha":"fe7b37960bbef791d9bed79760b61b1d40ca81cd","author":{"email":"652d1e34e1876dd82d643021ce9a3641bdac3966@redhat.com","name":"Krutika Dhananjay"},"message":"features/shard: Fix incorrect op_ret in READV\n\nChange-Id: I31ac99b290f82f4b74236c206193f7641c73d4dc\nBUG: 1259651\nSigned-off-by: Krutika Dhananjay <kdhananj@redhat.com>\nReviewed-on: http://review.gluster.org/12099\nReviewed-by: Pranith Kumar Karampuri <pkarampu@redhat.com>\nTested-by: NetBSD Build System <jenkins@build.gluster.org>","distinct":false,"url":"https://api.github.com/repos/anoopcs9/glusterfs/commits/fe7b37960bbef791d9bed79760b61b1d40ca81cd"},{"sha":"b5fff7326e9203c650eb5d395bc5a338075821f1","author":{"email":"52add29bc15c0f3832a373982b132796d33ff6c3@redhat.com","name":"Anoop C S"},"message":"protocol-client/server: Fix incorrect grace-timeout value in logs\n\nWhen grace-timer is initialized via server/client init,\nthe default or reconfigured value for grace-timeout is\ndisplayed incorrectly in both server and client logs.\nThis is because we use gf_time_fmt() to format this\ngrace-timeout value with gf_timefmt_s as the time format\nas shown below:\n\ngf_time_fmt (timestr, sizeof timestr, conf->grace_ts.tv_sec,\n                     gf_timefmt_s);\n\ngf_timefmt_s format is a wrapper for %s format specification\nused in strftime library call which populates the number\nof seconds since the Epoch [1970-01-01 00:00:00 +0000 (UTC)].\nBut this particular format is dependent on timezone\n[1970-01-01 05:30:00 +0530 (IST)]and thus displayed incorrectly\nin logs.\n\nExample:\nFor IST with default grace-timeout value 10, it is displayed\nas -19790 which is calculated as follows,\n1970-01-01 00:00:10 - 1970-01-01 05:30:00 = -19790 seconds.\n\nChange-Id: I1bdf5d12b2167323f86f0ca52a37ffb316b3f0a2\nBUG: 1227667\nSigned-off-by: Anoop C S <anoopcs@redhat.com>\nReviewed-on: http://review.gluster.org/11930\nTested-by: NetBSD Build System <jenkins@build.gluster.org>\nReviewed-by: Raghavendra Talur <rtalur@redhat.com>\nTested-by: Gluster Build System <jenkins@build.gluster.com>\nReviewed-by: Jeff Darcy <jdarcy@redhat.com>","distinct":false,"url":"https://api.github.com/repos/anoopcs9/glusterfs/commits/b5fff7326e9203c650eb5d395bc5a338075821f1"},{"sha":"76233f0cf43125a83b79de3ca5dc742fc9850cce","author":{"email":"36ab91862badf129e22a0765506a8b181227d4e1@redhat.com","name":"vmallika"},"message":"test: fix spurious failure from ./tests/basic/quota-nfs.t\n\nBefore checking for the quota usage,\numount and mount NFS mountpoint to flush the NFS cached data.\n\nThis test is fails on NetBSD, so marking the test as bad-test\n\nChange-Id: I1f30f5d9a919b3959c9f158366bd2f47569c8e03\nBUG: 1258766\nSigned-off-by: vmallika <vmallika@redhat.com>\nReviewed-on: http://review.gluster.org/12075\nTested-by: NetBSD Build System <jenkins@build.gluster.org>\nTested-by: Gluster Build System <jenkins@build.gluster.com>\nReviewed-by: Manikandan Selvaganesh <mselvaga@redhat.com>\nReviewed-by: Jeff Darcy <jdarcy@redhat.com>","distinct":false,"url":"https://api.github.com/repos/anoopcs9/glusterfs/commits/76233f0cf43125a83b79de3ca5dc742fc9850cce"},{"sha":"378b625698fe01ed2c3a6f4f065a699b2d573947","author":{"email":"10460665c63c1e41b922ea2cdf63084aa1a91e2a@redhat.com","name":"Ravishankar N"},"message":"tests: check free space only on gluster mount\n\nChange-Id: I06de4f555e66fac2594676572c8f8a4ee08f8131\nBUG: 1251346\nSigned-off-by: Ravishankar N <ravishankar@redhat.com>\nReviewed-on: http://review.gluster.org/12096\nReviewed-by: Raghavendra Talur <rtalur@redhat.com>\nTested-by: NetBSD Build System <jenkins@build.gluster.org>\nTested-by: Gluster Build System <jenkins@build.gluster.com>","distinct":false,"url":"https://api.github.com/repos/anoopcs9/glusterfs/commits/378b625698fe01ed2c3a6f4f065a699b2d573947"},{"sha":"c5629f1f8d3cf6363dde4a57110f58b191c2c7f4","author":{"email":"52add29bc15c0f3832a373982b132796d33ff6c3@redhat.com","name":"Anoop C S"},"message":"features/locks: Fixing mandatory-locking code path\n\nThis is the initial change to fix the mandatory locking\noption to be done per-file basis or on the complete volume.\n'locks.mandatory-locking' option is available as part of\nthis change which will accept one among the following\nvalues:\n'off'      - disable mandatory-locking [default option]\n'per-file' - per file mandatory-locking according to linux\n             kernel semantics\n'complete' - volume-wide complete mandatory-locking.\n\nChange-Id: I14c489b3f8af5ebcbfa155a03f0c175e9558ac46\nBUG: 762184\nSigned-off-by: Anoop C S <anoopcs@redhat.com>","distinct":true,"url":"https://api.github.com/repos/anoopcs9/glusterfs/commits/c5629f1f8d3cf6363dde4a57110f58b191c2c7f4"},{"sha":"4168052a641b8f17fdf41b9b23e2853fa9d6cec2","author":{"email":"52add29bc15c0f3832a373982b132796d33ff6c3@redhat.com","name":"Anoop C S"},"message":"features/locks: Include zerofill fop in locks translator\n\nAs of now zerofill call is not considered inside locks\ntranslator. But when mandatory-locking is enabled for a\nvolume, then we may need to check for conflicting locks\nbefore performing zerofill operation on a particular file.\nThis patch is intended to intercept zerofill fop inside\nlocks translator.\n\nChange-Id: I2d6de45f9f3e58865a8ff31c0d1a53dc5be15aff\nBUG: 762184\nSigned-off-by: Anoop C S <anoopcs@redhat.com>","distinct":true,"url":"https://api.github.com/repos/anoopcs9/glusterfs/commits/4168052a641b8f17fdf41b9b23e2853fa9d6cec2"},{"sha":"26b08927ff383497ccf7f7554b88250b7b8d80e4","author":{"email":"52add29bc15c0f3832a373982b132796d33ff6c3@redhat.com","name":"Anoop C S"},"message":"features/locks: Adding support for 'optimal' mandatory-lock mode\n\nAs of now volume set option for mandatory-locking includes\neither per-file based or volume-wide lock modes. This change\nintroduces another acceptable value 'optimal' for this option\nwhich allows the following semantics:\n\n[1] Each read/write/truncate will check for conflicting\n    mandatory locks and correspondingly blocks/allows the\n    fop.\n[2] Locks from POSIX clients will be always advisory and\n    any other POSIX client can do read/write/truncate without\n    conflict/overlap byte-range check.\n[3] No clients are allowed to read/write into regions where a\n    conflicting/overlapping mandatory byte-range lock is being\n    held by another client.\n[4] Any gfapi client who require a mandatory lock on a\n    particular byte-range will have to use the\n    glfs_common_lock() API to do so.\n[5] All native client lock requests will be treated as\n    advisory by default.\n\nThis particular change is effective with the following change\nhttp://review.gluster.org/#/c/11177/ which introduces the\ngf_common_lock() API in libgfapi.\n\nChange-Id: I72c2a75b66858bb43f33fd954ccc02700367d66b\nBUG: 762184\nSigned-off-by: Anoop C S <anoopcs@redhat.com>","distinct":true,"url":"https://api.github.com/repos/anoopcs9/glusterfs/commits/26b08927ff383497ccf7f7554b88250b7b8d80e4"},{"sha":"269ea595db383189239e2582016583f7e2055d3b","author":{"email":"52add29bc15c0f3832a373982b132796d33ff6c3@redhat.com","name":"Anoop C S"},"message":"gfapi: Add API support for applying mandatory-locks\n\nThe current API for byte-range locks[glfs_posix_lock()]\ndoesn't allow applications to specify whether it is\nadvisory or mandatory type locks. This particular\nchange is to introduce an extended byte-range lock\nAPI with additional arguments for including the\nbyte-range lock mode to be one among advisory(default)\nor mandatory.\n\nChange-Id: Ia09042c755d891895d96da857321abc4ce03e20c\nBUG: 762184\nSigned-off-by: Anoop C S <anoopcs@redhat.com>","distinct":true,"url":"https://api.github.com/repos/anoopcs9/glusterfs/commits/269ea595db383189239e2582016583f7e2055d3b"}]}