Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263535AbUCYSHc (ORCPT ); Thu, 25 Mar 2004 13:07:32 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263509AbUCYSHc (ORCPT ); Thu, 25 Mar 2004 13:07:32 -0500 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:51340 "EHLO ebiederm.dsl.xmission.com") by vger.kernel.org with ESMTP id S263535AbUCYSHa (ORCPT ); Thu, 25 Mar 2004 13:07:30 -0500 To: Jamie Lokier Cc: =?iso-8859-1?q?J=F6rn?= Engel , Davide Libenzi , "Patrick J. LoPresti" , Linux Kernel Mailing List Subject: Re: [PATCH] cowlinks v2 References: <20040321125730.GB21844@wohnheim.fh-wedel.de> <20040321181430.GB29440@wohnheim.fh-wedel.de> <20040325174942.GC11236@mail.shareable.org> From: ebiederm@xmission.com (Eric W. Biederman) Date: 25 Mar 2004 11:06:49 -0700 In-Reply-To: <20040325174942.GC11236@mail.shareable.org> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1462 Lines: 29 Jamie Lokier writes: > Eric W. Biederman wrote: > > Actually there is... You don't do the copy until an actual write occurs. > > Some files are opened read/write when there is simply the chance they might > > be written to so delaying the copy is generally a win. > > Programs depend on the inode number returned by fstat() not changing, > and maybe in some other circumstances, even if they subsequently write > to the file. > > (It's ok for open() to change the inode number, because that's > equivalent to another program changing the filesystem in parallel). > > How do you handle that if COW occurs later than open()? > You could also force COW when fstat() is called, I suppose. One of the rougher patches, in that we don't have persistent inode numbers. Basically the two files never have the same inode number. To the user they are always presented as two separate files. Currently I believe the strategy is to assign an inode when the file is read into the icache/dcache. I think it is just a sequential counter. This was all implemented as a stackable filesystem. Something that gets down to the real filesystem could likely just reuse the inode number of the cow link. Eric - 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/