From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cn.fujitsu.com ([222.73.24.84]:26685 "EHLO song.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1752664AbaAVIpb (ORCPT ); Wed, 22 Jan 2014 03:45:31 -0500 Message-ID: <52DF84DE.6080904@cn.fujitsu.com> Date: Wed, 22 Jan 2014 16:44:14 +0800 From: Wang Shilong MIME-Version: 1.0 To: dsterba@suse.cz, Miao Xie , linux-btrfs@vger.kernel.org Subject: Re: [PATCH v2 2/4] Btrfs: fix protection between send and root deletion References: <1389086721-19624-1-git-send-email-wangsl.fnst@cn.fujitsu.com> <1389086721-19624-2-git-send-email-wangsl.fnst@cn.fujitsu.com> <20140113182745.GS6498@twin.jikos.cz> <52D49F80.6020604@cn.fujitsu.com> <20140115164038.GD6498@twin.jikos.cz> <52D744C6.7040006@cn.fujitsu.com> <20140121181626.GC6498@twin.jikos.cz> In-Reply-To: <20140121181626.GC6498@twin.jikos.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: linux-btrfs-owner@vger.kernel.org List-ID: Hi David, On 01/22/2014 02:16 AM, David Sterba wrote: > On Thu, Jan 16, 2014 at 10:32:38AM +0800, Miao Xie wrote: >>> Your fix makes sure that the deleted root will not get cleaned and stays >>> during the send. Only after it finishes it will be cleaned. Now, what if >>> send fails or is interrupted? There's no way to redo it. Yes the user >>> can be blamed for the mistake, or the tools will prevent him to do it. >> I don't think so. The users should be responsible for their behavior if they >> destroy the subvolume. > Right now it's not possible to determine if a subvolume is involved in a > send (other than the user knows by himself that he started send). Send > or subvolume cleaning can be performed on the background. Although the > user is responsible for his actions, the consequence here is not > obvious, silent and irreversible. > >>> I see the latter as more user-friendly. Doing a 'send and forget' where >>> I don't care if the data will be sent properly does not fit the primary >>> purpose of send/receive with backups. >>> >>> My idea to fix that: >>> - add an internal root_item flag to denote a dead root >>> - set this flag in btrfs_add_dead_root() >>> - check the flag in send similar to the btrfs_root_readonly checks, for >>> all involved roots >>> - in 'destroy subvolume, check if the send_in_progress is set and refuse >>> to delete >> It is similar to our approach. But I think our idea is better because >> - we needn't add a new flag > Adding the flag is cheap. > >> - The subvolumes are special directory, the most operations of them should >> be similar to the common directory. Since we can remove a directory while >> someone is accessing it, it is better that we can destroy a subvolume >> while we are using it as a send parent. > Yes they're similar, but subvolumes have additional features that need > to be handled appropriately. One cannot send a directory. > > So we disagree, I see a reason for the deletion protection and will do > the patch myself. Let's see if we can get more user feedback then. > > I'm NAKing this patch in current state, if it helps anything. Both ways are ok for me actually, don't be annoyed anyway, You and Miao are really doing a good job to Btrfs, just go ahead, i am ok with dropping this patch.^_^ Thanks, Wang > > > david > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >