Re: [PATCH/RFC] NFSD: handle BTRFS subvolumes better.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7/15/21 1:24 PM, Christoph Hellwig wrote:
On Thu, Jul 15, 2021 at 01:11:29PM -0400, Josef Bacik wrote:
Because there's no alternative.  We need a way to tell userspace they've
wandered into a different inode namespace.  There's no argument that what
we're doing is ugly, but there's never been a clear "do X instead".  Just a
lot of whinging that btrfs is broken.  This makes userspace happy and is
simple and straightforward.  I'm open to alternatives, but there have been 0
workable alternatives proposed in the last decade of complaining about it.

Make sure we cross a vfsmount when crossing the "st_dev" domain so
that it is properly reported.   Suggested many times and ignored all
the time beause it requires a bit of work.


You keep telling me this but forgetting that I did all this work when you originally suggested it. The problem I ran into was the automount stuff requires that we have a completely different superblock for every vfsmount. This is fine for things like nfs or samba where the automount literally points to a completely different mount, but doesn't work for btrfs where it's on the same file system. If you have 1000 subvolumes and run sync() you're going to write the superblock 1000 times for the same file system. You are going to reclaim inodes on the same file system 1000 times. You are going to reclaim dcache on the same filesytem 1000 times. You are also going to pin 1000 dentries/inodes into memory whenever you wander into these things because the super is going to hold them open.

This is not a workable solution. It's not a matter of simply tying into existing infrastructure, we'd have to completely rework how the VFS deals with this stuff in order to be reasonable. And when I brought this up to Al he told me I was insane and we absolutely had to have a different SB for every vfsmount, which means we can't use vfsmount for this, which means we don't have any other options. Thanks,

Josef



[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux