Bug 762883 (GLUSTER-1151)

Summary:	change in hash range should change generation number of directory
Product:	[Community] GlusterFS	Reporter:	Krishna Srinivas <krishna>
Component:	core	Assignee:	Anand Avati <aavati>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	high	Docs Contact:
Priority:	urgent
Version:	mainline	CC:	chrisw, gluster-bugs, shehjart
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Krishna Srinivas 2010-07-16 00:25:04 UTC

Consider a situation where one client is running defrag script, it will change the directory layout. This means other clients which do a revalidate on lookup on a directory will not see the changed layout. Hence whenever we change the hash range, the posix translator can look out for trusted.glusterfs.dht xattr and put a new generation number on the directory.

Comment 1 Shehjar Tikoo 2010-07-16 05:39:21 UTC

inode and gen numbers must not change. It'll break NFS.

Comment 2 Anand Avati 2010-07-16 06:46:41 UTC

(In reply to comment #0)
> Consider a situation where one client is running defrag script, it will change
> the directory layout. This means other clients which do a revalidate on lookup
> on a directory will not see the changed layout.

The premise itself of this (speculative) bug is wrong. Clients do detect change of layout during a revalidate.

> Hence whenever we change the
> hash range, the posix translator can look out for trusted.glusterfs.dht xattr
> and put a new generation number on the directory.

"trusted.glusterfs.dht" is exclusively under the scope of DHT translator. posix translator should not look into namespace of other translators.

Comment 3 Krishna Srinivas 2010-07-16 17:53:29 UTC

(In reply to comment #2)
> (In reply to comment #0)
> > Consider a situation where one client is running defrag script, it will change
> > the directory layout. This means other clients which do a revalidate on lookup
> > on a directory will not see the changed layout.
> 
> The premise itself of this (speculative) bug is wrong. Clients do detect change
> of layout during a revalidate.
> 

I assumed that the revalidation to one subvol in case of directory can cause this bug, oops.