On Wed 07-04-10 11:22:00, Dmitry Monakhov wrote: > Jan Kara <jack@xxxxxxx> writes: > > > On Mon 05-04-10 13:44:54, Dmitry Monakhov wrote: > >> Currently quota is able to return real error code to caller. > >> Now it is possible to fix long standing bug with silent quota > >> corruption in dquot_transfer. > > > >> From 5e529864261c7bffe32a8b3d45d7b51749b4512f Mon Sep 17 00:00:00 2001 > >> From: Dmitry Monakhov <dmonakhov@xxxxxxxxxx> > >> Date: Mon, 5 Apr 2010 13:02:18 +0400 > >> Subject: [PATCH] quota: handle io errors in dquot_transfer > >> > >> Currently if one of dquot structures absent due to some io errors > >> dquot_transfer will ignore corresponding quotatype. Which is very > >> bad because result in silent quota inconsistency. > > But because we were unable to read some quota structure, quota already > > *is* inconsistent. So it's not like this particular operation would > > introduce the inconsistency. > Ohh... This is another type of error which is not handled at all. > dquot_initialize() may fail to read dquot from a disk and live > corresponding inode's structures semi-initialized. Before Christoph's > cleanup it was almost impossible to solve this issue because init() > was called from semi_random places. I'm tried to make it one but > give up this idea due to lack of perspective. > The good things is what since fs itself is now responsible for dquot > init it is possible to solve this issue. Yes, it shouldn't be too hard to handle errors from dquot_init now. > >> Sane implementation must return corresponding error to caller. > > But sure I agree we should return the fact that we stumbled on quota > > inconsistency the same way we do it for dquot_alloc_space or > > dquot_free_space. > I'll combine init and transfer patches to one patchset. > The way i see it now: > 1) dquot_initialize() return eio to caller > 2) dquot_transfer() return eio to caller > 3-5) dquot_(alloc/free/claim/...) must check that corresponding > ->i_dquot[type] was initialized. > 5) fs: handle error from dquot_initialize (this one will be huge) Yes, this looks like a good plan. 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
