Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263246AbUC2XF6 (ORCPT ); Mon, 29 Mar 2004 18:05:58 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263240AbUC2XF6 (ORCPT ); Mon, 29 Mar 2004 18:05:58 -0500 Received: from mail.shareable.org ([81.29.64.88]:45459 "EHLO mail.shareable.org") by vger.kernel.org with ESMTP id S263246AbUC2XFn (ORCPT ); Mon, 29 Mar 2004 18:05:43 -0500 Date: Tue, 30 Mar 2004 00:05:37 +0100 From: Jamie Lokier To: "Eric W. Biederman" Cc: =?iso-8859-1?Q?J=F6rn?= Engel , Davide Libenzi , "Patrick J. LoPresti" , Linux Kernel Mailing List Subject: Re: [PATCH] cowlinks v2 Message-ID: <20040329230537.GA8568@mail.shareable.org> References: <20040327214238.GA23893@mail.shareable.org> <20040328122242.GB32296@mail.shareable.org> <20040328235528.GA2693@mail.shareable.org> <20040329123658.GA4984@mail.shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1633 Lines: 35 Eric W. Biederman wrote: > So I see a problem with Scenario C. Perhaps you can refute it. Ick. You're right. I cannot refute it. Fwiw, I would have broken the directory cows on the first write, not the open. Thus, snapshots using lazy directory copies requires either that there are no hard links of the type you described (e.g. when snapshotting the root of the filesystem), or rather complex metadata to track the hard links, not dissimilar to the metadata needed to preserve hard links _within_ the snapshot. They both seem far too complex to be worth it. Hard links just don't play well with lazy cowlinked directories. They are fine with non-lazy directory cowlinking, where the whole directory tree is duplicated and only files are cow'd. Note that this doesn't apply to the original implementation which used hard links with a special flag: maintaining hard links in conjunction with cowlinks requires the inode duplication we've been talking about. Btw, if we have cowlinks implemented using inode duplication, then it isn't necessary for both inodes to have the same metadata such as mtime, ctime, mode etc. Only the data is shared. That means the sendfile() system call could conceivably be overloaded, meaning to copy the data, and let "cp --cow" decide whether it wants to copy the metadata (same as as "cp -rp" or "cp -rpd"), or not (same as "cp -r"). -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/