On Thu, Jul 02, 2020 at 02:15:04PM +0200, Diego Zuccato wrote: > Il 02/07/20 13:34, Brian Foster ha scritto: > > > I missed how this went from a question around interaction between user > > and project quotas to reporting of a problem associated with enablement > > of group+project quotas and an old fs. > Detected the problem and reported it as an "aside", suggesting a > possible improvement. > > > The above shows a v4 superblock > > (crc=0), which means project and group quotas share an inode and thus > > are mutually exclusive. It sounds to me that the problem is simply that > > you're specifying a set of incompatible mount options on a v4 fs, but > > you haven't really stated the problem clearly. I.e.: > > # mount /dev/test/scratch /mnt/ -o gquota,pquota > > mount: /mnt: wrong fs type, bad option, bad superblock on /dev/mapper/test-scratch, missing codepage or helper program, or other error. > > # dmesg | tail > > [ 247.554345] XFS (dm-3): Super block does not support project and group quota together > Seems you pinned it anyway. > > > We have to fail in this scenario (as opposed to randomly picking one) > > because either one can work for any mount (presumably wiping out the old > > quotas when changing from one mode to the other across a mount). > So that's not possible because introducing such a change would create > problems in existingsystems. I understand, more or less: if they still > boot, they're using just one option and from down my ignorance it seemed > a good idea to just discard deterministically one of the options > allowing the system to boot anyway. The usual "it's easy if you don't > have to do it" :) > Pretty much. ;) I think it's reasonable in theory to say something like "pick one or the other for older fs," but then we have to get into issues like being subtly affected by code changes that might reorder mount options without any notion of that affecting behavior (i.e. very brittle) and/or choosing one option of the other based on the current status of the [pg]quota inode, which is more implementation and doesn't rule out having to fail the mount in all cases anyways. Suffice it to say I don't think it's worth going further down that path simply to support passing a combination of mount options that has no runtime effect and was never a supported combination for the associated version of the fs in the first place. Brian > Tks a lot for the clear explanation. Today I learnt something new. > > -- > Diego Zuccato > DIFA - Dip. di Fisica e Astronomia > Servizi Informatici > Alma Mater Studiorum - Università di Bologna > V.le Berti-Pichat 6/2 - 40127 Bologna - Italy > tel.: +39 051 20 95786 >
