On Wed 31-03-10 09:20:17, Dmitry Monakhov wrote:
> dmonakhov@xxxxxxxxxx writes:
>
> > Jan Kara <jack@xxxxxxx> writes:
> >
> >> On Tue 30-03-10 18:25:28, Dmitry Monakhov wrote:
> >>> We already has per-dquot sanity checks, but with per-inode checks
> >>> quota leakage investigation becomes much easier.
> >>>
> >>> Signed-off-by: Dmitry Monakhov <dmonakhov@xxxxxxxxxx>
> >>> ---
> >>> fs/quota/dquot.c | 4 ++++
> >>> 1 files changed, 4 insertions(+), 0 deletions(-)
> >>>
> >>> diff --git a/fs/quota/dquot.c b/fs/quota/dquot.c
> >>> index e0b870f..4db57b7 100644
> >>> --- a/fs/quota/dquot.c
> >>> +++ b/fs/quota/dquot.c
> >>> @@ -1428,6 +1428,8 @@ EXPORT_SYMBOL(inode_add_rsv_space);
> >>> void inode_claim_rsv_space(struct inode *inode, qsize_t number)
> >>> {
> >>> spin_lock(&inode->i_lock);
> >>> + if (*inode_reserved_space(inode) < number)
> >>> + WARN_ON_ONCE(1);
> >> Maybe just: WARN_ON_ONCE(*inode_reserved_space(inode) < number)
> Ohh. While writing testcase for automatic-quota consistency check.
> I've failed to reliably detect condition where quota goes inconsistent.
> And it appears to be not what easy. We have hided real problems too deeply.
> The only reliable way is to grep dmesg for hard-coded "fs/quota/dquot.c"
> string which produced by WARN_ON_ONCE.
>
> After some thoughts (sometimes it happens with me too)
> i'm think what it is reasonable rewrite all quota error messages logic.
> Make it similar to ext4
> quota_error(...) {
> printk("QUOTA error (dev:%s)", ...);
> handle_quota_error(sb) /* let sb to know what quota is corrupted */
> }
> quota_warn(...) {
> printk("QUOTA warn (dev:%s)", ...);
> }
> In fact it is very important to let filesystem to now that it's quota
> is corrupted(quota == fs-metadata). It may set fsck_needed flag on
> super block for later correction.
Yes, it looks like a good idea.
> So please ignore this patch for now. I'll prepare another one which
> redesign error conditions handling logic.
OK.
Honza
--
Jan Kara <jack@xxxxxxx>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
