All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
	Christoph Hellwig <hch@lst.de>,
	linux-xfs@vger.kernel.org
Subject: Re: Quota warning woes (was: [PATCH 25/26] xfs: actually bump warning counts when we send warnings)
Date: Wed, 2 Mar 2022 16:38:08 -0800	[thread overview]
Message-ID: <20220303003808.GM117732@magnolia> (raw)
In-Reply-To: <199a3e85-9ee5-1354-e652-ff3d501bd395@sandeen.net>

On Wed, Mar 02, 2022 at 12:19:21PM -0600, Eric Sandeen wrote:
> On 3/1/22 1:31 PM, Eric Sandeen wrote:
> > On 7/14/20 8:53 PM, Darrick J. Wong wrote:
> >> From: Darrick J. Wong <darrick.wong@oracle.com>
> >>
> >> Currently, xfs quotas have the ability to send netlink warnings when a
> >> user exceeds the limits.  They also have all the support code necessary
> >> to convert softlimit warnings into failures if the number of warnings
> >> exceeds a limit set by the administrator.  Unfortunately, we never
> >> actually increase the warning counter, so this never actually happens.
> >> Make it so we actually do something useful with the warning counts.
> >>
> >> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> >> Reviewed-by: Christoph Hellwig <hch@lst.de>
> > 
> > Sooo I got a bug report that this essentially breaks the timer for
> > soft quota, because we now (and quite rapidly) hit the default
> > 5-warning limit well before we hit any reasonable timer that may
> > have been set, and disallow more space usage.
> > 
> > And those warnings rack up in somewhat unexpected (to me, anyway)
> > ways. With a default max warning count of 5, I go over soft quota
> > exactly once, touch/create 2 more empty inodes, and I'm done:
> 
> Looking at this some more, I think it was never clear when the warnings
> should get incremented. An old IRIX document[1] says:
> 
> "With soft limits, whenever a user logs in with a usage greater than his
> soft limit, he or she will be warned (via/bin/login(1))."
> 
> Which seems to indicate that perhaps the warning was intended to be
> once per login, not once per allocation attempt. Also ...
> 
> Ancient XFS code had a "xfs_qm_dqwarn()" function which incremented the
> warning count, but it never had any callers until the day it was removed
> in 2005, so it's not at all clear what the warning frequency was supposed
> to be or what should trigger it, from the code archives.
> 
> Hence, my modest proposal would be to just remove the warning limits
> infrastructure altogether. It's never worked, nobody has ever asked for it
> (?), and its intent is not clear. My only hesitation is that Darrick added
> the warning increment, so perhaps he knows of a current use case that
> matters?

None specifically, but it's a feature, albeit a poorly documented and
previously broken one.  VFS quotas don't seem to have any warning
limits, so I suppose there's not a lot of precedent to go on.

That said -- I don't how gutting a feature (especially since it's now
been *working* for a year and a half) is the solution here.  If you
think the default warning limit is too low, then perhaps we should
increase it.  If you don't like that a single user operation can bump
the warning counter multiple times, then propose adding a flag to the
dqtrx structure so that we only bump the warning counter *once* per
transaction.  "It's never worked" is not true -- this fix was added for
5.9, and it's now shipped in two LTS kernels.

On the other hand, if you think this feature is totally worthless and it
should go away, there's a deprecation process for that.

--D

> 
> thanks,
> -Eric
> 
> [1] https://irix7.com/techpubs/007-0603-100.pdf

  reply	other threads:[~2022-03-03  0:38 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-15  1:50 [PATCH v4 00/26] xfs: remove xfs_disk_quot from incore dquot Darrick J. Wong
2020-07-15  1:50 ` [PATCH 01/26] xfs: clear XFS_DQ_FREEING if we can't lock the dquot buffer to flush Darrick J. Wong
2020-07-15  1:50 ` [PATCH 02/26] xfs: fix inode quota reservation checks Darrick J. Wong
2020-07-15  1:50 ` [PATCH 03/26] xfs: validate ondisk/incore dquot flags Darrick J. Wong
2020-07-15 12:50   ` Chandan Babu R
2020-07-15  1:50 ` [PATCH 04/26] xfs: move the flags argument of xfs_qm_scall_trunc_qfiles to XFS_QMOPT_* Darrick J. Wong
2020-07-15 12:50   ` Chandan Babu R
2020-07-15  1:51 ` [PATCH 05/26] xfs: split the incore dquot type into a separate field Darrick J. Wong
2020-07-16  6:59   ` Chandan Babu R
2020-07-15  1:51 ` [PATCH 06/26] xfs: refactor quotacheck flags usage Darrick J. Wong
2020-07-16  6:59   ` Chandan Babu R
2020-07-15  1:51 ` [PATCH 07/26] xfs: rename dquot incore state flags Darrick J. Wong
2020-07-16  6:59   ` Chandan Babu R
2020-07-15  1:51 ` [PATCH 08/26] xfs: move the ondisk dquot flags to their own namespace Darrick J. Wong
2020-07-15  1:51 ` [PATCH 09/26] xfs: make XFS_DQUOT_CLUSTER_SIZE_FSB part of the ondisk format Darrick J. Wong
2020-07-20  5:37   ` Chandan Babu R
2020-07-15  1:51 ` [PATCH 10/26] xfs: stop using q_core.d_flags in the quota code Darrick J. Wong
2020-07-20  5:37   ` Chandan Babu R
2020-07-15  1:51 ` [PATCH 11/26] xfs: stop using q_core.d_id " Darrick J. Wong
2020-07-15  1:51 ` [PATCH 12/26] xfs: use a per-resource struct for incore dquot data Darrick J. Wong
2020-07-15  1:52 ` [PATCH 13/26] xfs: stop using q_core limits in the quota code Darrick J. Wong
2020-07-15  1:52 ` [PATCH 14/26] xfs: stop using q_core counters " Darrick J. Wong
2020-07-15  1:52 ` [PATCH 15/26] xfs: stop using q_core warning " Darrick J. Wong
2020-07-15  1:52 ` [PATCH 16/26] xfs: stop using q_core timers " Darrick J. Wong
2020-07-15  1:52 ` [PATCH 17/26] xfs: remove qcore from incore dquots Darrick J. Wong
2020-07-15  1:52 ` [PATCH 18/26] xfs: refactor default quota limits by resource Darrick J. Wong
2020-07-15  1:52 ` [PATCH 19/26] xfs: remove unnecessary arguments from quota adjust functions Darrick J. Wong
2020-07-15  1:52 ` [PATCH 20/26] xfs: refactor quota exceeded test Darrick J. Wong
2020-07-15  1:52 ` [PATCH 21/26] xfs: refactor xfs_qm_scall_setqlim Darrick J. Wong
2020-07-15  1:52 ` [PATCH 22/26] xfs: refactor xfs_trans_dqresv Darrick J. Wong
2020-07-15  1:53 ` [PATCH 23/26] xfs: refactor xfs_trans_apply_dquot_deltas Darrick J. Wong
2020-07-15  1:53 ` [PATCH 24/26] xfs: assume the default quota limits are always set in xfs_qm_adjust_dqlimits Darrick J. Wong
2020-07-20  5:38   ` Chandan Babu R
2020-07-15  1:53 ` [PATCH 25/26] xfs: actually bump warning counts when we send warnings Darrick J. Wong
2020-07-20  5:38   ` Chandan Babu R
2022-03-01 19:31   ` Quota warning woes (was: [PATCH 25/26] xfs: actually bump warning counts when we send warnings) Eric Sandeen
2022-03-02 18:19     ` Eric Sandeen
2022-03-03  0:38       ` Darrick J. Wong [this message]
2020-07-15  1:53 ` [PATCH 26/26] xfs: add more dquot tracepoints Darrick J. Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220303003808.GM117732@magnolia \
    --to=djwong@kernel.org \
    --cc=darrick.wong@oracle.com \
    --cc=hch@lst.de \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.