Frederick Bruckman wrote:
> > Perhaps more problematic is that when the filesystem is remounted
> > ro, it's marked clean and no further data is synced - i.e. if I do
> > the remount (without syncing first), further sync doesn't actually
> > write the data to disk, only after I actually unmount the filesystem.
> 
> I'm sure you meant to say, "when the filesystem is remounted rw".

No, I really meant ro. If I do mount -o ro,update, the filesystem
is marked clean on-disk, but some meta data appear to not be flushed
in some cases.

> > If the system crashes at this point (say, I'm testing new kernel
> > feature), the filesystem ends up damanged, but marked clean.
> > 
> > Is this a bug or a feature?
> 
> What would be the use of such a feature?. To freeze the filesystem
> to operate on it with "fsdb"?

Primarily so that I could avoid long fsck if I'm e.g. testing something.

It just feels wrong - if the file system is ro, it should not have
any pending dirty buffers, right? Especially if the file system
has been marked as clean in the on-disk superblock.

> But then the changes would be
> overwritten on unmounting, so that doesn't make any sense. I think

Unmount of ro-mounted filesystem should not change any on-disk
data, should it?

> the intuitive thing would be to flush the buffer cache *after* the
> filesystem is marked "rw", if that's possible.

Yeah, the intuitive thing would be to flush the buffer cache
after filesystem is marked ro. Is there any reason we don't
do that? AFAICS ffs only flushes file system data on update to 'ro',
but not metadata.

Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>            http://www.NetBSD.cz/
-=- We can walk our road together if our goals are all the same;     -=-
-=- We can run alone and free if we pursue a different aim.          -=-