[linux-lvm] snapshot of Reiserfs
Andreas Dilger
adilger at turbolinux.com
Wed Feb 21 23:23:51 UTC 2001
Chris Mason writes:
> Hmmm, fsync_dev_lockfs should look like this:
>
> +int fsync_dev_lockfs(kdev_t dev)
> +{
> + sync_buffers(dev, 0);
> +
> + lock_kernel();
> + sync_supers(dev);
> ^^^^^^^^^^^^^^^^^^
>
> + /* note, the FS might need to start transactions to
> + ** sync the inodes, or the quota, no locking until
> + ** after these are done
> + */
> + sync_inodes(dev);
> + DQUOT_SYNC(dev);
> + /* if inodes or quotas could be dirtied during the
> + ** sync_supers_lockfs call, the FS is responsible for getting
> + ** them on disk, without deadlocking against the lock
> + */
> + sync_supers_lockfs(dev) ;
> + unlock_kernel();
> +
> + return sync_buffers(dev, 1) ;
> +}
Some overhead in calling sync_supers() and sync_supers_lockfs() because
they do both do the same list traversal. Granted, on most systems the
total number of superblocks is small... Last time I had a look at this,
I suggested that the sync_supers_lockfs() call be changed, namely that
it is illegal to call it with a zero "dev" parameter, otherwise you
will lock all filesystems and that may be a bad thing. This simplifies
the code a bit. If we also have it call write_super() if write_super_lockfs()
is missing, it is better yet.
> It is amost exactly a cut n' paste of fsync_dev, with an extra call to
> sync_supers_lockfs. It should do what fsync_dev does, even when there are
> no sync_super_lockfs methods are provided. The only reason I didn't just
> call fsync_dev from fsync_dev_lockfs is because I wanted the sync_buffers
> call to happen after the lockfs call ;-)
And the reason for this is? The first call to sync_buffers doesn't wait
on completion (unlike the second sync_buffers call), so there is no
guarantee that they are all written out.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
More information about the linux-lvm
mailing list