On Tuesday, October 31, 2000 18:00:48 +0000 "Stephen C. Tweedie"
<[EMAIL PROTECTED]> wrote:
> On Tue, Oct 31, 2000 at 10:18:12AM -0500, Chris Mason wrote:
>>
>> Yes, I was less than clear ;-) I meant that a crash could result in a
>> fully consistent filesystem with file writes that are not reflected in
>> the intermezzo log.
>
> Not important for InterMezzo --- InterMezzo only propagates changes
> onn a whole file basis. If one node is modifying a file, then by
> definition it has a lock and is the only owner of the file. There is
> no state held by InterMezzo about which parts of the file may have
> changed --- as long as (a) the initial file creation gets logged, and
> (b) the inode timestamp is updated on any write, InterMezzo should be
> quite happy.
>
This goes against my intuition for how disconnected operation works.
Either way, Peter please clue us in ;-)
> Peter, let me know if I've got any of this wrong, but I think
> InterMezzo should still be safe in the presence of large, non-atomic
> writes to cached files.
>
>> This is not a huge issue, but it gets more interesting
>> when you turn off data logging (and the ext3 code that flushes new blocks
>> before transaction commit).
>
> That flush code actually improves performance by eliminating thrashing
> between the commit code and the VM, in measurements so far, so
> typically it's not going to hurt if you don't turn it off!
>
Interesting. More support for giving the FS more control over flushing.
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
