Re: [PATCH] 2.5.x write_super is not for syncing

[Andrew Morton <akpm@digeo.com>]

Bryan Henderson wrote:
> 
> >Well, I'd say that telling the fs about umount activity is "out
> >of scope" for this exercise ;)
> 
> Not sure what your point is here.  The filesystem driver already knows when
> the filesystem image is being destroyed (i.e. the struct super_block is
> going away), which is the only umount activity I'm talking about.  If
> destroying a filesystem image of a particular type means cached stuff has
> to get sync'ed, the filesystem driver knows to do it then; there's no need
> for a ->sync_fs call in addition to ->put_super.

In the context of the 2.4 kernel it is not practical to change every
filesystem to sync itself at unmount.

Nor in 2.5, by my hand...

> >It seems reasonable to have a super_op which says "sync everything
> >to disk".
> 
> Well, maybe, but the question is when should FS call that?  I say
> performing the sync() system call is the only time it should.  If it calls
> it for any other reason, it is making assumptions about how the particular
> filesystem type works.

Yes, it always has.  And Linux's tradition of forcing the filesystems
to comply with the VFS's and VM's requirements has always been a
strength.  Because we can make deep changes to the VM and VFS without
having to make deep changes to filesytems.

Yes, this makes porting filesystems from other OS'es harder.  That is
tough luck.  It's better this way.  Filesystems which do weird stuff
are a pain - they drag down core kernel development.

> Because "sync everything to disk" is ambiguous in the modern diverse world
> of filesystems (so is fsync() -- note that standards define these pretty
> vaguely in recognition of that), the only sensible way to define it is to
> say "it's what sync() does -- ask your filesystem type designer what sync()
> does on your filesystem."
> 
> If there's any other writing of cached data to disk that needs to be done,
> I say the filesystem driver knows when to do it; FS should not presume to
> know.

The move is more toward "if the fs needs to do special stuff then it
should have a hook to do that".  In concrete terms, this means rather
than "write your superblock now" we need to tell the fs what's happening
at a higher level, and if the fs isn't interested, perform the default
(ext2-style) operation.

I don't think anyone has a problem with that approach.  And as new
filesystems are added to Linux, each one brings in its own set
of new hooks.  And I think that's a fine approach - we should not
be speculatively adding hooks if they have no in-kernel consumers.
 
> Of course, in ext2 and its ilk, FS understands the inner workings and is
> deeply involved in caching and uses the traditional ->write_super, etc. to
> carry it out.  We're only talking about new, more general kinds of
> filesystems now.

->write_super() seems to be a bit of a crock.  It _should_ be "the VFS
superblock info has changed.  You should propagate that to pagecache
but not start IO against it".  It's not clear what it actually means
at present.

But for your fs, I suspect we'll need to see specific descriptions
of the problems which are being encountered, and patches.