Hide Forgot
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.
inode and gen numbers must not change. It'll break NFS.
(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.
(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.