-
Notifications
You must be signed in to change notification settings - Fork 257
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add flag to only disable pathFsOpts.ClientInodes (but keep caches) #435
Comments
This is actually a bug in gocryptfs. The device number in those subvolumes is different, right? gocryptfs should not get confused by inodes on different devices. |
Yes: each btrfs or zfs subvolume has its own unique device id. (...something which gocryptfs should probably also expose in the fuse mount) |
Generates unique inode numbers for files on different devices. #435
Should be fixed now. Inodes from different devices are now mapped to the number range above 10000000000000000000 . If you have to opportunity to test again this would be very much appreciated! |
Thanks a lot for looking into this! I can confirm that the issue i was seeing is fixed in the current HEAD. Simple verification test:
with gocryptfs at HEAD:
Version without bb6155a:
|
gocryptfs currently doesn't play well with btrfs subvolumes due to pathfs's inode mapping:
Steps to reproduce
Assume the following setup:
/foo
<-- btrfs filesystem and cipherdir/foo/M6LB0sjNfK2HT2c0UbAaMw
<--- subvolume (btrfs subvol create .....)/foo/cULkSfhPk6LTWKsPPYO2Sw
<--- another subvolumeM6LB0sjNfK2HT2c0UbAaMw
andcULkSfhPk6LTWKsPPYO2Sw
are the encrypted names of two directories in the root of the encrypted filesystem. Let's call themdir1
anddir2
in cleartext.Mounting such a setup with
gocryptfs /foo /bar
will serve a filesystem at/bar
with 2 subfolders, just as expected:However: The issue with such a setup is that
M6LB0sjNfK2HT2c0UbAaMw
andcULkSfhPk6LTWKsPPYO2Sw
are considered to be separated devices by BTRFS / VFS and therefore may use the same inodes (this is not exclusive to btrfs subvolumes: ZFS or a mount within the cipherdir would have the same eissue).When this happens (inode collision in the 2 folders), gocryptfs logs
2019/11/04 21:24:22 Found linked inode, but Nlink == 1, ino=8191, fullPath="...
and the client sees various fun errors (usually '..not a directory..').Looking at the go-fuse code shows that the error comes from here:
https://github.com/hanwen/go-fuse/blob/master/fuse/pathfs/pathfs.go#L570
..after it detected that something is fishy with its clientInodeMap - which is not surprising as the code only tracks the inode but omits the device id - therefore making it easy to have 'bogus' data in the cache.
My current workaround is to use the
--sharedstorage
flag which disables pathFSOpts.ClientInodes - but also disables all caching, which isn't really needed in this situation.It would therefore be great to have a flag/option to only disable
pathFSOpts.ClientInodes
while still keeping the caching functionality.(Also: it may make sense to disable ClientInodes on BTRFS and ZFS by default? .. not sure :-) )
Oh: and thanks a lot for writing gocryptfs!
The text was updated successfully, but these errors were encountered: