@Volodymyr, If you or someone else is going to run a statistical analysis, it's better to wait until after the patches queued for 2.6.30 make it into an Ubuntu kernel. Also, you should when you did your test, did you check to see about file lossagem, or just that the filesystem was self- consistent?
Also, I can guarantee you that for certain classes of files, and for certain workloads, you will lose data with ext3 if you put the system under enough memory pressure. Heck, with ext3 (since barriers are disabled), if you are running with a very heavy workload that puts the system under continuous memory pressure, the filesystem can be corrupted badly enough on an unclean powerdown that it requires fsck to fix it. Chris Mason proved that a few months ago. The fact that you didn't detect that just meant that you didn't rig your test that you happened to catch that combination. I can tell you what you will find with 2.6.30, which is that as long as the newly written file is replacing an existing file using O_TRUNC or file rename, the newly written file will be forced to disk before the transaction commit is allowed to proceed. However, for files that are newly written and not yet fsync'ed, the data might not be saved until 45-120 seconds after it was written, and for files that are extended via O_APPEND, or via an open(O_RDWR), lseek(), write(), newly allocated blocks again may not be allocated until 45-120 seconds have gone by; however these files are generally either log files, or database files, and databases are usually competently written by people who understand the value of using fdatasync() or fsync(). For both ext3 (and for files replacing other files in ext4) if the transaction commit has not taken place, the new file contents will obviously not be there, or be present with the "file.new" filename. So even for ext3, if your editor doesn't use auto-save files, and you are doing a multi-hour long editing session without saving the file at intermediate points, and then you save the file, and the editor doesn't do an fsync(), and then before the five second transaction commit happens, you fire up Google Earth or some other 3D application, *and* you are using a crappy proprietary driver that causes a crash --- you could lose hours of work. Ultimately, there's only so much incompetence and bad practices that a file system can protect you against without completely sacrificing performance.... -- Ext4 data loss https://bugs.launchpad.net/bugs/317781 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
