Sascha, Am Mittwoch, 23. Januar 2019, 10:43:05 CET schrieb Sascha Hauer: > On Wed, Jan 23, 2019 at 12:07:12AM +0100, Richard Weinberger wrote: > > On Thu, Jan 10, 2019 at 12:45 PM Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> wrote: > > > > > > Hi all, > > > > > > I'm currently working on resurrecting the UBIFS quota patches posted back in > > > 2015 by Dongsheng Yang, last posted here: > > > > > > http://lists.infradead.org/pipermail/linux-mtd/2015-September/061812.html > > > > > > First of all I think work stopped there, there is no newer UBIFS quota > > > support I am missing, right? > > > > > > One problem with this series was that the quotactl systemcall expects a > > > path to a block device. UBIFS doesn't work on a block device but on a > > > character device instead. > > > The solution in this series was to pass the path to the cdev in > > > quotactl. A struct cdev * member was added to struct super_block which > > > was used to identify the superblock for a given cdev. This approach was > > > rejected by Christoph ("I don't think the cdev has any business in core > > > VFS code."). Apart from that UBIFS can not only be mounted with a path > > > to the character device (mount -t ubifs /dev/ubix_y /mnt) but also in > > > the form ubix:volname (mount -t ubifs ubix:volname /mnt) in which case > > > userspace doesn't have any valid path it could pass in quotactl. > > > > > > An idea out of this would be to allow to pass the mountpoint instead of > > > the path to the block device in quotactl which would work with nfs or > > > even tmpfs aswell. Would that be acceptable? Any other ideas? > > > > *kind ping* > > > > Jan, another thing Sascha and I are not sure about, what are the consistency > > constraints of the quota file? > > If I read the code correctly, quota just writes to the quota file and > > assumes that > > the file system makes sure about consistency. Either by fsckfixing the quota > > file or having a data journal for the quota file. > > In case of UBIFS where we have a data journal this should be doable. > > Is it okay when the quota file has S_SYNC set? > > S_SYNC won't help us. We need to make sure that a change of an inode and > the corresponding update to the quota file is done atomically. Otherwise > it may happen that we only change the size of an inode, but miss the > corresponding quota updates, or depending on the implementation, maybe > the other way round. This is why I said yesterday you need to touch the UBIFS journal replay code too. So, S_SYNC is not to keep the quota file consistent with UBIFS' state, it is to make sure we don't lose quota updates. Skipping S_SYNC is also possible, but then you need to fix up even more stuff in the replay code. Thanks, //richard
