On Thu, May 27, 2010 at 6:28 AM, <Valdis.Kletnieks@xxxxxx> wrote: > On Thu, 27 May 2010 00:31:44 +0900, Minchan Kim said: >> On Wed, May 26, 2010 at 07:21:57AM -0300, Cesar Eduardo Barros wrote: >> > far as I can see, does nothing against the disk simply failing to >> > write and later returning stale data, since the stale checksum would >> > match the stale data. >> >> Sorry. I can't understand your point. >> Who makes stale data? If any layer makes data as stale, integrity is up to >> the layer. Maybe I am missing your point. >> Could you explain more detail? > > I'm pretty sure that what Cesar meant was that the following could happen: > > 1) Write block 11983 on the disk, checksum 34FE9B72. > (... time passes.. maybe weeks) > 2) Attempt to write block 11983 on disk with checksum AE9F3581. The write fails > due to a power failure or something. > (... more time passes...) > 3) Read block 11983, get back data with checksum 34FE9B72. Checksum matches, > and there's no indication that the write in (2) ever failed. The program > proceeds thinking it's just read back the most recently written data, when in > fact it's just read an older version of that block. Problems can ensue if the > data just read is now out of sync with *other* blocks of data - instant data > corruption. Oh, doesn't normal disk support atomicity of sector write? I have been thought disk must support atomicity of sector write at least. AFAIK, other device(ex, nand device by FTL) supports atomicity of sector write. -- Kind regards, Minchan Kim -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>