linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Dmitry Monakhov <dmonakhov@openvz.org>
Cc: Jan Kara <jack@suse.cz>, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 1/3] RFC quota: add generic quota error handlers.
Date: Tue, 6 Apr 2010 19:35:14 +0200	[thread overview]
Message-ID: <20100406173514.GC4420@quack.suse.cz> (raw)
In-Reply-To: <8739zaxi32.fsf@openvz.org>

> >> diff --git a/fs/quota/quota.c b/fs/quota/quota.c
> >> index 95388f9..ebdce30 100644
> >> --- a/fs/quota/quota.c
> >> +++ b/fs/quota/quota.c
> >> @@ -19,6 +19,41 @@
> >>  #include <linux/types.h>
> >>  #include <linux/writeback.h>
> >>  
> >> +static void quota_handle_error(struct super_block *sb)
> >> +{
> >> +
> >> +	set_bit(_DQUOT_ERROR, &sb_dqopt(sb)->flags);
> >> +	/* XXX: Currently it is no impossible to signall fs about error */
> >> +}
> >   I guess we can make all quota allocation and freeing functions to return
> > an error (EIO) if they spot some problem. That should be enough for a
> > filesystem to find out something is wrong...
> This result significant paradigm changes, because almost all fs-related
> syscalls result int quota alloc/free which return -EIO (i.e in almost
> unusable filesystem). Users with incorrect system-scripts will hate us
> for this.
  You're right, it's not so simple. But your notification function is IMHO
an overengineering. So I'd stick to passing the fact that quota is
probably corrupted via a function return value. We might use some less
"fatal" error code than EIO or even return a positive return value (because
usually quota operation itself happened just fine, we only spotted some quota
inconsistency). Then we have to update every filesystem using quotas to
count with the fact that quota functions can return such return value.
Probably have a simple wrapper for each filesystem for those 4 quota function
it calls which will filter-out the special return value and do whatever
else it wishes to do...
  Maybe if there are several filesystems that want to just ignore quota
corruption, we can create generic wrappers just filtering out the special
return value.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

      reply	other threads:[~2010-04-06 17:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-31  9:00 [PATCH 1/3] RFC quota: add generic quota error handlers Dmitry Monakhov
2010-03-31  9:00 ` [PATCH 2/3] ext4: check quota error state on quota_off Dmitry Monakhov
2010-03-31  9:00   ` [PATCH 3/3] ext3: " Dmitry Monakhov
2010-03-31 14:54 ` [PATCH 1/3] RFC quota: add generic quota error handlers Jan Kara
2010-04-05 11:19   ` Dmitry Monakhov
2010-04-06 17:35     ` Jan Kara [this message]

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=20100406173514.GC4420@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=dmonakhov@openvz.org \
    --cc=linux-fsdevel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).