From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shaya Potter Subject: Re: which dentry a page belongs to Date: Sun, 25 Apr 2004 01:23:03 -0400 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <1082870582.12790.8.camel@zaphod> References: <20040423151458.GC6300@mail.shareable.org> <1082734938.1943.26.camel@zaphod> <20040423173738.A3812@infradead.org> <1082739174.1943.49.camel@zaphod> <20040423180130.A4255@infradead.org> <1082740707.1943.61.camel@zaphod> <20040423173719.GB7335@mail.shareable.org> <1082743539.1943.84.camel@zaphod> <20040423213747.GA8915@mail.shareable.org> <1082759212.1854.6.camel@zaphod> <20040423224947.GC8915@mail.shareable.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Christoph Hellwig , linux-fsdevel@vger.kernel.org Return-path: Received: from opus.cs.columbia.edu ([128.59.20.100]:4056 "EHLO opus.cs.columbia.edu") by vger.kernel.org with ESMTP id S262906AbUDYFXm (ORCPT ); Sun, 25 Apr 2004 01:23:42 -0400 To: Jamie Lokier In-Reply-To: <20040423224947.GC8915@mail.shareable.org> List-Id: linux-fsdevel.vger.kernel.org On Fri, 2004-04-23 at 23:49 +0100, Jamie Lokier wrote: > Shaya Potter wrote: > > OK, great example, now I see the problem which can't be easily solved. > > > > update-data > > ioctl > > update-data > > writepage() > > > > writepage can't differentiate b/w data b4 and data after, so only way to > > do it would be to force a sync b4 ioctl is called, which I would think > > (perhaps wrong) should write out all the data to disk. But unsure if > > prorgramatically able to really test to see if it worked or not. > > "sync" doesn't do anything to help. right. > In general, first "update-data" in your example doesn't count as a > "write" and it wouldn't be logical for a program to expect it to be > snapshotted. It counts as the program queuing up data which it does > not expect to be visible in the file until the next msync, munmap or > exit (although it is visible to other concurrent mmaps, and it _might_ > be visible in the file, of parts of it might). right. But as I just realized, for my purposes it doesn't matter much. The file system I'm working on is to go together with ZAP, which is our kernel based process checkpoint/restart/migration infrastructure. We wanted a versioning fs to go with it so we aren't stuck just doing checkpoint ; restart ; checkpoint ; restart, but could checkpoint many times in a row and restart many times from a single arbitrary checkpoint (not just the last one) One thing we have to do, even right now, is checkpoint all dirty pages associated with a process. Hence the right thing to do after a snapshot/version would be to version immediately in writepage() as the process checkpoint code will have taken care of saving the dirty pages (and the restart code will take care of restoring them and marking them dirty). though I'm guessing it be a slightly different story for write() if that uses the writepage() interface as the pages will be "anonymous" (i.e. not mapped inside a process)