On Thu 30-07-09 16:33:51, Theodore Tso wrote: > On Thu, Jul 30, 2009 at 08:30:53PM +0200, Jan Kara wrote: > > I have to say I'm a bit worried about modify-in-place tricks - it's > > not trivial to make sure buffer is not part of any transaction in the > > journal, since the buffer head could have been evicted from memory, but > > the transaction still is not fully checkpointed. Hence in memory, you > > don't have any evidence of the fact that if the machine crashes, your > > modify-in-place gets overwritten by journal-replay. > > Yeah, good point; tracking which blocks might get overwritten on a > journal replay is tough. What we *could* do that would make this easier > is to insert a revoke record for all extent tree blocks after the > blocks have been written to disk (since at that point there's no need > for that block to be replayed). Hmm, but will this help you? You'd have to wait for revoke records to commit before you can be sure that journal replay won't overwrite your in-place changes. Looking at the O_DIRECT semantics, I don't think nobody really requires the data being on disk after the write() returns and we crash - in particular if we extend the file, the write will be just an ordinary buffered write so in practice, it behaves like this already. Given the fact that only a bit special applications use O_DIRECT, I think we can afford to make a reservation that O_DIRECT writes even to a preallocated space do not have any special data-consistency guarantees. Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
