On Sun 2009-03-29 13:10:23, M?ns Rullg?rd wrote: > "Andreas T.Auer" <andreas.t.auer_lkml_73537@xxxxxxxxxxxx> writes: > > > On 29.03.2009 13:22 M?ns Rullg?rd wrote: > >> Consider this scenario: > >> > >> 1. Create/write/close newfile > >> 2. Rename newfile to oldfile > >> 3. Open/read oldfile. This must return the new contents. > >> 4. System crash and reboot before delayed allocation/flush complete > >> 5. Open/read oldfile. Old contents now returned. > >> > >> This rollback isn't obviously, to me at least, without problems of its > >> own. > >> > > Having the old data in 5) is far better than having no data in 5). > > Of course having old data is better than no data. However, fsync() > and similar approaches make a rollback to old data after new data has > been visible impossible or far less likely than the suggested one. Untrue. Unless you fsync after rename, you can get olddata. fsync() is easy. But some people _want_ to have either newdata _or_ olddata, but don't care which one, and would prefer to avoid fsync. That's where replace() should help... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
