From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shaya Potter Subject: Re: which dentry a page belongs to Date: Fri, 23 Apr 2004 12:52:54 -0400 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <1082739174.1943.49.camel@zaphod> References: <1082732223.1943.11.camel@zaphod> <20040423151458.GC6300@mail.shareable.org> <1082734938.1943.26.camel@zaphod> <20040423173738.A3812@infradead.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Jamie Lokier , linux-fsdevel@vger.kernel.org Return-path: Received: from opus.cs.columbia.edu ([128.59.20.100]:51354 "EHLO opus.cs.columbia.edu") by vger.kernel.org with ESMTP id S264875AbUDWQxX (ORCPT ); Fri, 23 Apr 2004 12:53:23 -0400 To: Christoph Hellwig In-Reply-To: <20040423173738.A3812@infradead.org> List-Id: linux-fsdevel.vger.kernel.org On Fri, 2004-04-23 at 17:37 +0100, Christoph Hellwig wrote: > On Fri, Apr 23, 2004 at 11:42:19AM -0400, Shaya Potter wrote: > > > i_mmap and i_mmap_shared are lists. They can both be empty, or both > > > non-empty. A page can be mapped shared *and* non-shared at the same > > > time. A page might not be mapped at all. > > > > yes, they can be empty for "generic" pages, but I'm looking at a > > specific case of file system pages, so they shouldn't be empty. i.e. > > otherwise my fs's writepage() shouldn't be called, I would think. > > in 2.4 writepage is always the result of data dirtied by mmap. In 2.6 it's > also for use for data dirtied by write. Even in 2.4 there's no gurantee > the mapping that dirtied the page still exists when the page is written out > by the VM. so the mapping off the page struct will be null? > > > It is possible to find multiple dentries which are currently being > > > used to map a page. > > > > a single page can have multiple dentries? but it has only one inode? > > Yes. > > > (i.e. host) So I can imagine if the single inode is linked in multiple > > places (for my purposes I don't care about that directly) but can it > > really have multiple inodes? > > It can't have multiple inodes. so is that a yes to my understanding of "multiple dentries" i.e. a single inode linked into multiple places in the fs. > > > > It's also possible to find no dentries at all. > > > > even if in my fs's writepage() function? > > Yes. so the vm_file part of vm_area_struct will be null? > > > Your question is extremely ill-formed. What do you mean by "the > > > dentry corresponding to a page"? What do you want the value for? > > > > When my writepage() is called, I want to be able to possibly do dentry > > based operations (rename, d_path....) to be told what files are actually > > getting written to via writepage() (as opposed to the file system's > > write() functionality). > > You can't do that. Yes, I know it's evil to do and would never be accepted into the kernel proper, the question I'm trying to figure out if it it's possible (with a stackable fs) to version files on write. via the write() interface it's easy (rename underlying dentry to new name, create new dentry w/ old name, copy data from new name to old name, with an underlying fs that supports a cow semantic can be pretty quick, stacked fs also manages upper->lower name mappings) , via writepage() interface is what I'm trying to solve, without forcing a open/close (as then could version on open, very easily), so that one could essentialy ioctl() the fs, and all future initial writes cause a version. Without a stackale fs, but with a fs that supports versioning this is easy, as just chain everything off the inode, trying to figure out how to do this with a stackable fs.