Hi all, Long-time UUG lurker here. I've pretty much solved my problem already, but I wanted to post this for posterity and I do have one big question still.
I set up a box with Debian Squeeze: a nice RAID 10 setup with 8 drives. I discovered that during heavy I/O writes the system would become very unresponsive, for example, freezing for up to a minute when saving a small file. I was able to reproduce this with cp, dd, or even scp. In iotop I noticed that kjournald and flush-8:0 were at 99.99%. Then I reinstalled with ext4 instead of ext3, but the problem still occurred just with jbd2 instead of kjournald. Sadly, running the background copy operation with an idle I/O priority (using ionice) didn't help. So I created a partition with JFS and it worked great! Then I set up one with XFS and that worked well too! But I was still curious to find out why ext3/ext4 behaved so badly. In the back of my mind I was thinking about the infamous ext3 fsync issue that plagued especially Firefox users, so I read this article, http://lwn.net/Articles/328363/ and decided to try adding the mount option data=writeback. That fixed it! (I know data=writeback is not as safe as data=ordered, but I think it will be enough for me especially if I do regular backups of important stuff.) Has anyone else run into this and did you resolve it by switching to data=writeback or by using a different filesystem like JFS or XFS? Now for my most important question. I know that the default for ext3 was changed to data=writeback, except that Debian (and other distros) override that by setting the CONFIG_EXT3_DEFAULTS_TO_ORDERED. (See https://ext4.wiki.kernel.org/index.php/Ext3_Data%3DOrdered_vs_Data%3DWriteback_mode). But what about ext4? If I read the code correctly, it defaults to ordered, but why? To me that says that the kernel devs believe that ext4 does not have the same problem as ext3, but for me it does! Phillip -- Phillip Hellewell <sshock AT sshock.net> -------------------- BYU Unix Users Group http://uug.byu.edu/ The opinions expressed in this message are the responsibility of their author. They are not endorsed by BYU, the BYU CS Department or BYU-UUG. ___________________________________________________________________ List Info (unsubscribe here): http://uug.byu.edu/mailman/listinfo/uug-list
