On 5/19/20 11:39 AM, Darrick J. Wong wrote: > On Mon, May 18, 2020 at 01:52:16PM -0500, Eric Sandeen wrote: >> The only grace period which can be set in the kernel today is for id 0, >> i.e. the default grace period for all users. However, setting an >> individual grace period is useful; for example: >> >> Alice has a soft quota of 100 inodes, and a hard quota of 200 inodes >> Alice uses 150 inodes, and enters a short grace period >> Alice really needs to use those 150 inodes past the grace period >> The administrator extends Alice's grace period until next Monday >> >> vfs quota users such as ext4 can do this today, with setquota -T > > Does setquota -T work on an XFS filesystem? With [PATCH] quota-tools: Set FS_DQ_TIMER_MASK for individual xfs grace times it does. > If so, does that mean that > xfs had a functionality gap where the admin could extend someone's grace > period on ext4 but trying the exact same command on xfs would do > nothing? Or would it at least error out? The former; no error. quota-tools didn't set the timer mask, so quotactl wasn't set up to change it. In addition, we ignored the change for id !=0. >> To enable this for XFS, we simply move the timelimit assignment out >> from under the (id == 0) test. Default setting remains under (id == 0). >> Note that this now is consistent with how we set warnings. >> >> (Userspace requires updates to enable this as well; xfs_quota needs to >> parse new options, and setquota needs to set appropriate field flags.) > > So ... xfs_quota simply never had the ability to do this, but what does > "setquota needs to set appropriate field flags" mean exactly? It means: [PATCH] quota-tools: Set FS_DQ_TIMER_MASK for individual xfs grace times + if (flags & COMMIT_TIMES) /* indiv grace period */ + xdqblk.d_fieldmask |= FS_DQ_TIMER_MASK; -Eric
