On 7/15/21 12:45 PM, Christoph Hellwig wrote:
On Thu, Jul 15, 2021 at 10:09:37AM -0400, Josef Bacik wrote:
I'm going to restate what I think the problem is you're having just so I'm
sure we're on the same page.
1. We export a btrfs volume via nfsd that has multiple subvolumes.
2. We run find, and when we stat a file, nfsd doesn't send along our bogus
st_dev, it sends it's own thing (I assume?). This confuses du/find because
you get the same inode number with different parents.
Is this correct? If that's the case then it' be relatively straightforward
to add another callback into export_operations to grab this fsid right?
Hell we could simply return the objectid of the root since that's unique
across the entire file system. We already do our magic FH encoding to make
sure we keep all this straight for NFS, another callback to give that info
isn't going to kill us. Thanks,
Hell no. btrfs is broken plain and simple, and we've been arguing about
this for years without progress. btrfs needs to stop claiming different
st_dev inside the same mount, otherwise hell is going to break lose left
right and center, and this is just one of the many cases where it does.
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. Thanks,
Josef
