diff options
author | David Chinner <dgc@sgi.com> | 2008-04-29 12:53:32 +1000 |
---|---|---|
committer | Lachlan McIlroy <lachlan@redback.melbourne.sgi.com> | 2008-04-29 15:58:56 +1000 |
commit | 359346a9655c8800408ed3ca44517ac7ea95c197 (patch) | |
tree | 4a97c2956dc5204fd28c26008bbf1f27c1e684bf /fs/xfs/xfs_bmap.c | |
parent | 86c4d62305649848164ae311a0959fc569b0d964 (diff) | |
download | kernel_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_bmap.c')
0 files changed, 0 insertions, 0 deletions