From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Re: [PATCH] quota: handle io errors in dquot_transfer Date: Wed, 7 Apr 2010 11:55:30 +0200 Message-ID: <20100407095530.GA3375@quack.suse.cz> References: <877homxmg9.fsf@openvz.org> <20100406174111.GD4420@quack.suse.cz> <876343wwvb.fsf@openvz.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jan Kara , linux-fsdevel@vger.kernel.org To: Dmitry Monakhov Return-path: Received: from cantor2.suse.de ([195.135.220.15]:51417 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751371Ab0DGJzU (ORCPT ); Wed, 7 Apr 2010 05:55:20 -0400 Content-Disposition: inline In-Reply-To: <876343wwvb.fsf@openvz.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed 07-04-10 11:22:00, Dmitry Monakhov wrote: > Jan Kara 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 > >> 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 SUSE Labs, CR