On 20/05/2019 19:47, Hendrik Friedel wrote:> Hello, > >>>> You posted this: >>>> I am using Openmediavault (debian based NAS distribution), which is >>>> not actively supporting btrfs >>>> It is this that I was referring to. >>> Ah, yes. >>> OMV intended to move to btrfs as the only choice with the next >>> version. In order to pave the way, I intended to be an early >>> adopter. The problem I report here, that there is good reason to. >> For you perhaps, but if OMV will not help, well...... > What do you mean? [there was a 'shows' missing. It shoult have read > 'shows that there is good reas on to'] >What I was trying to say was (and failing, it would seem), this is a two way street and if OMV cannot/will not help you, then it is hard to fix, especially now that Jeremy has pointed out that it cannot be fixed as is. Now this doesn't mean it can never be fixed, throw enough money and man hours at it and a workaround can probably be found, but this would undoubtedly entail OMV getting involved .>> That sort of says a lot, if it was that big a problem and multiple >> users were complaining, then it probably would get fixed, but there >> are only so many developers and they have only so much time available >> to fix things and add new features, so the most important things get >> fixed first. We do, however, accept patches to fix things, so perhaps >> you can get together with OMV and fix it from your end ;-) > I fear, that's beyond my skills. > > Well, I did my best.At least I hope you can understand why some bug reports seem to take forever to get fixed, it is all down to priorities, the highest priority ones get fixed first, unless one annoys a user enough that they put their hand in their pocket and they pay someone to get it fixed. Rowland
Hello, >> In my impression: Yes. Also, this problem seems to affect also zfs 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?] 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? :) The explaination is: > That's because the concept of a btrfs "subvolume" completely > breaks the POSIX idioms that smbd depends on. And wouldn't that also be applicable to zfs?> At least I hope you can understand why some bug reports seem to take forever to get fixed, it is all down to priorities, the highest priority ones get fixed first,Yes, I understand that. > What I was trying to say was (and failing, it would seem), this is a two way street > and if OMV cannot/will not help you, then it is hard to fix, What is OMV specific here? Isn't the problem fully included already in linux (=kernel) and samba? > especially now that Jeremy has pointed out that it cannot be fixed as is. Now this > doesn't mean it can never be fixed, throw enough money and man hours at it > and a workaround can probably be found Here, I could imagine that linking with linux-btrfs would be worthwhile. > but this would undoubtedly entail OMV getting involved Why? OMV merely writes the smb.conf... Greetings, Hendrik
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
On 21/05/2019 21:00, Hendrik Friedel wrote:> > > > > > > What I was trying to say was (and failing, it would seem), this is a > two way street > > and if OMV cannot/will not help you, then it is hard to fix, > > What is OMV specific here? Isn't the problem fully included already in > linux (=kernel) and samba? > > > especially now that Jeremy has pointed out that it cannot be fixed > as is. Now this > > doesn't mean it can never be fixed, throw enough money and man hours > at it > > and a workaround can probably be found > > Here, I could imagine that linking with linux-btrfs would be worthwhile. > > > but this would undoubtedly entail OMV getting involved > > Why? OMV merely writes the smb.conf... >You raised the OMV distro, not me and also said that they were moving to only use btrfs with their next major release. You also said that they wouldn't/couldn't help you. You stand more chance of getting a workaround with help from a distro. This is because your problem isn't really a Samba problem, quotas work on Samba, just not with btrfs. Rowland