forked from torvalds/linux
-
Notifications
You must be signed in to change notification settings - Fork 23
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
BTRFS/NFSD: provide more unique inode number for btrfs export
BTRFS does not provide unique inode numbers across a filesystem. It only provide unique inode numbers within a subvolume and uses synthetic device numbers for different subvolumes to ensure uniqueness for device+inode. nfsd cannot use these varying synthetic device numbers. If nfsd were to synthesise different stable filesystem ids to give to the client, that would cause subvolumes to appear in the mount table on the client, even though they don't appear in the mount table on the server. Also, NFSv3 doesn't support changing the filesystem id without a new explicit mount on the client (this is partially supported in practice, but violates the protocol specification and has problems in some edge cases). So currently, the roots of all subvolumes report the same inode number in the same filesystem to NFS clients and tools like 'find' notice that a directory has the same identity as an ancestor, and so refuse to enter that directory. This patch allows btrfs (or any filesystem) to provide a 64bit number that can be xored with the inode number to make the number more unique. Rather than the client being certain to see duplicates, with this patch it is possible but extremely rare. The number that btrfs provides is a swab64() version of the subvolume identifier. This has most entropy in the high bits (the low bits of the subvolume identifer), while the inode has most entropy in the low bits. The result will always be unique within a subvolume, and will almost always be unique across the filesystem. If an upgrade of the NFS server caused all inode numbers in an exportfs BTRFS filesystem to appear to the client to change, the client may not handle this well. The Linux client will cause any open files to become 'stale'. If the mount point changed inode number, the whole mount would become inaccessible. To avoid this, an unused byte in the filehandle (fh_auth) has been repurposed as "fh_options". (The use of #defines make fh_flags a problematic choice). The new behaviour of uniquifying inode number is only activated when this bit is set. NFSD will only set this bit in filehandles it reports if the filehandle of the parent (provided by the client) contains the bit, or if - the filehandle for the parent is not provided or is for a different export and - the filehandle refers to a BTRFS filesystem. Thus if you have a BTRFS filesystem originally mounted from a server without this patch, the flag will never be set and the current behaviour will continue. Only once you re-mount the filesystem (or the filesystem is re-auto-mounted) will the inode numbers change. When that happens, it is likely that the filesystem st_dev number seen on the client will change anyway. Signed-off-by: NeilBrown <neilb@suse.de>
- Loading branch information
1 parent
2734d6c
commit e99ff00
Showing
8 changed files
with
87 additions
and
12 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters