Re: which dentry a page belongs to

[Shaya Potter <spotter@cs.columbia.edu>]

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)