Back to bug 1323042

Who When What Removed Added
Red Hat Bugzilla Rules Engine 2016-04-01 04:44:38 UTC Keywords ZStream
Nithya Balachandran 2016-04-05 09:23:15 UTC Status NEW POST
CC nbalacha
Assignee rhs-bugs rgowdapp
Alok 2016-04-07 11:07:22 UTC CC asrivast
Rahul Hinduja 2016-04-07 11:12:13 UTC CC rhinduja
QA Contact storage-qa-internal kramdoss
Satish Mohan 2016-04-12 09:17:42 UTC CC smohan
Blocks 1311387
Red Hat Bugzilla Rules Engine 2016-04-12 09:17:48 UTC Target Release --- RHGS 3.1.3
Milind Changire 2016-04-18 11:37:08 UTC CC mchangir
Blocks 1311817
Raghavendra G 2016-04-21 05:18:06 UTC Depends On 1329062
Raghavendra G 2016-04-26 08:46:27 UTC Status POST MODIFIED
errata-xmlrpc 2016-05-02 06:02:55 UTC Status MODIFIED ON_QA
Satish Mohan 2016-05-02 06:06:35 UTC Fixed In Version glusterfs-3.7.9-3
krishnaram Karthick 2016-05-19 15:15:49 UTC Status ON_QA VERIFIED
Raghavendra G 2016-05-20 07:43:05 UTC Doc Text Cause: The hashed subvolume of dht acts as an arbitrator for parallel dentry operations like mkdir. Hashed subvolume is derived from the layout of the parent directory. If the layout on bricks is changed due to some operation like add/remove-brick followed by a fix layout, all the clients need not be in sync with new layout. So, with different clients having different layouts, clients will have different hashed-subvols for same path. This results in more than one mkdir to be successful on same path. Since each mkdir carries a different gfid, we would end up with a directory having different gfids on different bricks. When different bricks have different gfids, operations on that directory will fail.

Consequence: Various operations on a directory fail because of inconsistent gfids across bricks

Fix: Make bricks to check for the hash range which client has passed as an argument in mkdir. If the hash ranges don't match fail the mkdir with appropriate errno. Clients on seeing this specific error will refresh their layouts and retry the operation with new parent layout.

Result: Directory inconsistencies because of stale layouts in clients is fixed.
Laura Bailey 2016-06-06 02:35:47 UTC CC rgowdapp
Doc Text Cause: The hashed subvolume of dht acts as an arbitrator for parallel dentry operations like mkdir. Hashed subvolume is derived from the layout of the parent directory. If the layout on bricks is changed due to some operation like add/remove-brick followed by a fix layout, all the clients need not be in sync with new layout. So, with different clients having different layouts, clients will have different hashed-subvols for same path. This results in more than one mkdir to be successful on same path. Since each mkdir carries a different gfid, we would end up with a directory having different gfids on different bricks. When different bricks have different gfids, operations on that directory will fail.

Consequence: Various operations on a directory fail because of inconsistent gfids across bricks

Fix: Make bricks to check for the hash range which client has passed as an argument in mkdir. If the hash ranges don't match fail the mkdir with appropriate errno. Clients on seeing this specific error will refresh their layouts and retry the operation with new parent layout.

Result: Directory inconsistencies because of stale layouts in clients is fixed.
The hashed subvolume of the Distributed Hash Table acts as an arbitrator for parallel directory entry operations like mkdir. This hashed subvolume is derived from the layout of the parent directory. If the directory layout on bricks changed, and fix layout ran before the layout was synced to clients, client and server layouts differed. This also meant that the client and server hashed subvolumes differed, affecting file and directory GFID consistency and causing various directory operations to fail. Clients are now prompted to refresh their layouts when their hash range does not match that of the server. This prevents issues with stale directory layout between server and client.
Flags needinfo?(rgowdapp)
Raghavendra G 2016-06-10 04:25:17 UTC Flags needinfo?(rgowdapp) needinfo+
errata-xmlrpc 2016-06-23 00:51:44 UTC Status VERIFIED RELEASE_PENDING
errata-xmlrpc 2016-06-23 05:15:12 UTC Status RELEASE_PENDING CLOSED
Resolution --- ERRATA
Last Closed 2016-06-23 01:15:12 UTC

Back to bug 1323042