aboutsummaryrefslogtreecommitdiffstats
path: root/fs/xfs/xfs_alloc.h
diff options
context:
space:
mode:
authorDavid Chinner <dgc@sgi.com>2008-04-29 12:53:32 +1000
committerLachlan McIlroy <lachlan@redback.melbourne.sgi.com>2008-04-29 15:58:56 +1000
commit359346a9655c8800408ed3ca44517ac7ea95c197 (patch)
tree4a97c2956dc5204fd28c26008bbf1f27c1e684bf /fs/xfs/xfs_alloc.h
parent86c4d62305649848164ae311a0959fc569b0d964 (diff)
downloadkernel_samsung_aries-359346a9655c8800408ed3ca44517ac7ea95c197.zip
kernel_samsung_aries-359346a9655c8800408ed3ca44517ac7ea95c197.tar.gz
kernel_samsung_aries-359346a9655c8800408ed3ca44517ac7ea95c197.tar.bz2
[XFS] Don't initialise new inode generation numbers to zero
When we allocation new inode chunks, we initialise the generation numbers to zero. This works fine until we delete a chunk and then reallocate it, resulting in the same inode numbers but with a reset generation count. This can result in inode/generation pairs of different inodes occurring relatively close together. Given that the inode/gen pair makes up the "unique" portion of an NFS filehandle on XFS, this can result in file handles cached on clients being seen on the wire from the server but refer to a different file. This causes .... issues for NFS clients. Hence we need a unique generation number initialisation for each inode to prevent reuse of a small portion of the generation number space. Use a random number to initialise the generation number so we don't need to keep any new state on disk whilst making the new number difficult to guess from previous allocations. SGI-PV: 979416 SGI-Modid: xfs-linux-melb:xfs-kern:31001a Signed-off-by: David Chinner <dgc@sgi.com> Signed-off-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
Diffstat (limited to 'fs/xfs/xfs_alloc.h')
0 files changed, 0 insertions, 0 deletions