From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Re: [PATCH 5/5] quota: handle IO errors in dquot_transfer() Date: Tue, 15 Dec 2009 12:49:14 +0100 Message-ID: <20091215114913.GA4916@quack.suse.cz> References: <1260793276-8511-1-git-send-email-dmonakhov@openvz.org> <1260793276-8511-2-git-send-email-dmonakhov@openvz.org> <1260793276-8511-3-git-send-email-dmonakhov@openvz.org> <1260793276-8511-4-git-send-email-dmonakhov@openvz.org> <1260793276-8511-5-git-send-email-dmonakhov@openvz.org> <20091214184127.GH4731@quack.suse.cz> <87skbdyy61.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]:56746 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754642AbZLOLtX (ORCPT ); Tue, 15 Dec 2009 06:49:23 -0500 Content-Disposition: inline In-Reply-To: <87skbdyy61.fsf@openvz.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue 15-12-09 01:43:18, Dmitry Monakhov wrote: > Jan Kara writes: > > > On Mon 14-12-09 15:21:16, Dmitry Monakhov wrote: > >> transfer_to[cnt] = dqget() may returns NULL due to IO error. > >> But NULL value in transfer_to[cnt] means a dquot transfer > >> optimization. So after operation succeed inode will have new > >> i_uid or i_gid but accounted to old dquot. This behaviour > >> is differ from dquot_initialize(). Let's handle IO error from > >> dqget() equally in all functions. > >> > >> In appliance to dquot_transfer() this means that we have to finish > >> operation regardless to IO errors from dqget(). > > In principle, the patch is fine (see just about a bug below). But even > > better would be if you converted dquot_transfer() to actually return real > > return codes (0, -EDQUOT, -EIO...) and make it return EIO in case of IO > Actually we have following set of errors (0, -EDQUOT, -EIO, -ENOMEM, -ENOSPC) > And ENOSPC is more realistic than EIO or ENOMEM. But from other point of view > quota is some sort of fs meta-data, so we can not let it just *silently* fail > because of some error as it done at the moment. Exactly. That's why I'd like to get this cleaned up in the long run... Honza -- Jan Kara SUSE Labs, CR