From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from userp1040.oracle.com ([156.151.31.81]:50388 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754209Ab2KZKbp (ORCPT ); Mon, 26 Nov 2012 05:31:45 -0500 Date: Mon, 26 Nov 2012 18:30:13 +0800 From: Liu Bo To: Itaru Kitayama Cc: linux-btrfs@vger.kernel.org Subject: Re: [PATCH 1/2 v4] Btrfs: snapshot-aware defrag Message-ID: <20121126103012.GA18538@liubo.jp.oracle.com> Reply-To: bo.li.liu@oracle.com References: <1351333721-3220-1-git-send-email-bo.li.liu@oracle.com> <50911FC0.4080104@oracle.com> <20121101112114.GA4328@liubo.cn.oracle.com> <50929CF4.9060206@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Sender: linux-btrfs-owner@vger.kernel.org List-ID: On Sun, Nov 25, 2012 at 12:48:33PM +0900, Itaru Kitayama wrote: > Hi Liubo: > > At the relinking stage, in some situations, looking up the extent tree with > the extent logical start objectid key from one of the old extents fails, > but the found previous item's objectid + offset is exactly the original > search objectid. As you say, usually old extents are retrieved from the > extent tree without a problem, but if the Delayed or some other mechanisms > change extents layout in the finish ordered IO function, we need to take > care of those rejected extents, not simply returning ENOENT. What do you > think? Hi Itaru san, Thanks for the suggestion. It's all right to ignore ENOENT. An extent stands for a range of space, which owns an item in extent tree. If old extents' item is not found in the extent tree, i.e. rejected extents, it means that this range of space is not shared by any snapshots(the extent refs is now 0), and so it's safe. So the worst case is that due to COW, a file and its snapshots share nothing after some time, the defrag on the file won't change its snapshots, but this can be solved when we always with autodefrag and snapshot-aware defrag. thanks, liubo