--On 10/04/00 02:23:30 +0200 Daniel Phillips <[EMAIL PROTECTED]> wrote:
> Chris Mason wrote:
>>
>> --On 10/03/00 21:13:04 +0200 Daniel Phillips
>> <[EMAIL PROTECTED]> wrote:
>>
>> > Chris Mason wrote:
>> >> Heinz Mauelshagen and I have come up with an API for LVM to use
>> >> for creating consistent snapshots. The idea is to block FS
>> >> modifications while the snapshot is being created, and to give the FS
>> >> the chance to flush everything (including all pending transactions)
>> >> to disk before LVM starts doing copy on write.
>> > [...]
>> >
>> >
>> > What is the thinking behind having a sync_super sandwich? I've always
>> > wondered about that.
>> >
>>
>> For filesystems that don't have a write_super_lockfs call back, I wanted
>> to make fsync_dev_lockfs == fsync_dev.
>
> I was actually asking why there are two calls to sync_supers, one at the
> beginning and one at the end. That sounds like one too many to me.
>
The first one is a call to sync_supers, which will skip the call to the FS
write_super method if the super is not dirty. The second is a call to
sync_supers_lockfs, which will always call the FS write_super_lockfs
method.
The reiserfs write_super_lockfs call blocks new transactions from starting,
waits for the current transaction to finish, flushes all pending commits
and metadata blocks to disk, and blocks new calls to
writepage/prepare_write/commit_write. Since the journal already knew how
to do almost all of this, it was only about 10 lines of new code ;-)
It could have been done to avoid the first call to sync_supers, but this is
not a speed sensitive function, and I wanted to make it really clear this
was fsync_dev + something extra (if the FS provided it).
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
