[Samba] Fw: Btrfs Samba and Quotas

[Gregory Sloop]

HFvs> Hello,

 >>> In my impression: Yes. Also, this problem seems to affect also zfs 
HFvs> and

 >> I'm mostly interested in the claim that ZFS is affected.
 >> I haven't followed this thread carefully, but what exactly is the problem we're
 >> talking about, and how do we know it impacts ZFS?
 >> [Something more than a single one-liner in that bug report?]

HFvs> Indeed, I only find that one line. I can try to find out.

 >> Is the extent of the issue that quotas won't work, while enforced from Samba
 >> against a ZFS volume?

 >> Can someone perhaps enlighten me? :)

HFvs> The explaination is:


I'll quote the whole thing, because it's useful.
 ---
  @JA
  
  That's because the concept of a btrfs "subvolume" completely
  breaks the POSIX idioms that smbd depends on.


  We absolutely identify a file by a dev/ino pair, and
  expect the dev to remain consistent under an exported
  share path.

  If you sub-mount this also breaks smbd dfree/quotas, and
  that's a lot more common.

  This identity is baked into Samba in order to implement
  leases/oplocks and it's not going to change.
---

Not to be unduly glib - but that explanation really means nothing to me.

I'm sure this takes the thread way OT, so I'm fine with the OP quashing this branch - but let me see if I get this.

I'll assume a "dev/ino pair" means device+inode pair. Meaning we can identify the files by their dev+inode - and enforce quota etc.
Is that a correct assumption?

Since I only vaguely know what a btrfs subvolume is - I will again assume we're talking about essentially an independent mount point. Most importantly, this gives the files in the subvolume a new set of dev+inode identifiers. So, if we use dev+inode to control quota, we have a problem because we now have two sets of dev+inodes that point to the same data/files. And managing quotas would be pretty difficult. [Essentially not possible given the methods currently used by Samba.]

So, do I have that mostly right? ['cause I'm doing a lot of guessing here.]

HFvs> And wouldn't that also be applicable to zfs?

I know some about ZFS from a conceptual POV, but not sure if this applies or not.

But, my larger general question was: This only applies to btrfs [or perhaps ZFS] when you're trying to enforce a quota _in Samba_ on a set of directories/files where there is a subvolume. Is that correct?

And the result is that quota management will essentially be undefined. It doesn't crash things, or corrupt them, but you can't rely on the quota enforcement being accurate/consistent. Is that also correct?

So, in btrfs [and perhaps ZFS] if you're _*not* using subvolumes_ and you _are enforcing quotas in Samba_, this isn't going to cause an issues.
Or you could be using subvolumes, but not enforcing quotas. And this will work fine.
The only problem set is where you're both enforcing quota in samba, and are using a sub-volume.
Again, do I have that right? [Probably I'm missing something, somewhere.]

-Greg