Hi. There are so many points in this conversation where I could jump in and make the comment I want to provide (below). Sorry if I haven't picked the best one. On Thursday 06 July 2006 12:32, Bill Davidsen wrote: > No comment, I would have to see a state table to be sure I saw the races > or that there were none. With a single writer and a sinple dirty bit > there is no issue, it behaves like an elevator, more or less. With > multiple writers I bet changes are written in the order submitted rather > than the order done, but multiple writers without locks are a train > wreck waiting to happen anyway. One application I can see for this careful checking is checkpointing. IIRC, Linus recently said he'd like to see suspending to disk treated as a special case of checkpointing, and I can see good sense in that. But the support is just not there at the moment. An important part of implementing that would be having a filesystem where we could know exactly what the state of the filesystem was at the last checkpoint, and roll back to it if necessary. Of course this would need to be tied to tracking changes in memory and to writing the memory state to storage, but they're separate problems. Ext3 has a history of being the best filesystem to use in developing and testing suspend to disk. It would be great if ext4 was the basis for implementing serious checkpointing support. Regards, Nigel -- Nigel, Michelle and Alisdair Cunningham 5 Mitchell Street Cobden 3266 Victoria, Australia
Attachment:
pgp8dnRiQrayp.pgp
Description: PGP signature
- References:
- ext4 features
- From: Thomas Glanzmann <[email protected]>
- Re: ext4 features
- From: "J. Bruce Fields" <[email protected]>
- Re: ext4 features
- From: Bill Davidsen <[email protected]>
- ext4 features
- Prev by Date: Re: [Patch] Off by one in drivers/usb/input/yealink.c
- Next by Date: Re: 2.6.17-mm5 -- netconsole failed to send full trace
- Previous by thread: Re: ext4 features
- Next by thread: Re: ext4 features
- Index(es):
 |