| |||||||||||||
ext4 and data consistencyext4 and data consistencyPosted May 14, 2010 12:54 UTC (Fri) by anton (guest, #25547)In reply to: ext4 and data consistency by rahulsundaram Parent article: The Next3 filesystem Am I? That's Ted T'so's position as reported on, e.g., LWN. But maybe you can show me where I was wrong in my statement of his position. And my impression is that if it was just up to him, he would not have made the rename fix.
(Log in to post comments)
ext4 and data consistency Posted May 14, 2010 14:00 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
You said there was only one fix. There were several and there are other Ext4 filesystem developers as well. What your state as his position is leaving out a lot of naunced arguments in a complex topic and making it sound very simplistic. If you can actually show a single case where Ext4 performs less robustly than Ext3, I would be interested.
ext4 and data consistency Posted May 21, 2010 15:08 UTC (Fri) by Duncan (guest, #6647) [Link]
What bothers me is how they reduced the guarantees and stability of the long mature ext3 filesystem in the aftermath of all this, by defaulting it to data=writeback, a change from the old default data=ordered.
Presumably you used tun2fs or simply fstab to ensure your ext3 mounts remain stable with data=ordered after the kernel in question (was it 2.6.30 or 2.6.31?), right?
What'd be interesting to see would be how the distributions have handled it, since. Did they go with the new ext3 data=writeback default, or have they either reverted either that commit or now default their userspace to specify data=ordered by default?
I know at least one guy who was complaining of ext3 instability after installing a new kernel due to that, that went away when he returned to data=ordered for his ext3 volumes. The context of that discussion was the pan (nntp client) user list, IIRC.
Me, I've been on reiserfs for years on both my main system and (more recently) my netbook, and have been extremely happy with it since data=ordered became its default (2.6.6 according to a google hit on another LWN comment of mine). My most recent experience with extX is on no-journal ext4 formatted USB flash-based thumbdrives, where journaling isn't a good idea. I've been following btrfs with interest, and expect I'll upgrade to it once a few more of the kinks get worked out. (I've seen hints that the current 2.6.35 cycle will reduce the strength of the warning for its kernel config item, but I don't follow the btrfs list or lkml, and any detail of even plans has been harder to come by on the broader community sites such as LWN, HO, LXer, etc, that I follow.)
Duncan
ext4 and data consistency Posted May 22, 2010 19:15 UTC (Sat) by anton (guest, #25547) [Link] What bothers me is how they reduced the guarantees and stability of the long mature ext3 filesystem in the aftermath of all this, by defaulting it to data=writeback, a change from the old default data=ordered.Yes, that's what was at the back of my mind when I wrote about "backporting the data loss feature from ext4 to ext3". Presumably you used tun2fs or simply fstab to ensure your ext3 mounts remain stable with data=ordered after the kernel in question (was it 2.6.30 or 2.6.31?), right?The youngest kernel we have is 2.6.30, and according to /proc/mounts it mounts our ext3 file systems with data=ordered. I guess we will go the fstab route once we get a kernel that defaults to data=writeback. I am a little worried, though, because of what happened after data=journal was no longer the default; I then read that using data=journal resulted in corrupt file systems; I read that for a significant amount of time, and never read that this bug has been fixed (but haven't seen such reports for some time). So if they made data=ordered non-default in 2.6.31 or some kernel, will they really care if it works? My confidence is limited. We should probably better stick with 2.6.30 until we migrate off extx file systems completely.
ext4 and data consistency Posted May 22, 2010 20:36 UTC (Sat) by nix (subscriber, #2304) [Link]
Sticking with 2.6.30 is foolish. Bugs are fixed in ext[34] all the time, sometimes data loss bugs: by sticking with 2.6.30, you're depriving yourself of all of those.
(btw, you can put mount options in the superblock, and avoid modifying /etc/fstab.)
ext4 and data consistency Posted May 23, 2010 11:44 UTC (Sun) by anton (guest, #25547) [Link] And new bugs are introduced, and if they are for a non-default option like (now) data=ordered, they won't get noticed in time, and they won't get fixed for quite some time; at least that's what the non-default data=journal episode teaches. So what's higher: the risk of data loss from a well-known kernel, or from a new kernel in a non-default setting? Choosing the latter seems foolish to me.Modifying fstab is not a big deal, why would I want to avoid it. The problem with doing it in the superblock is that I have to do it again when I transfer the system to another disk.
ext4 and data consistency Posted May 23, 2010 11:50 UTC (Sun) by cortana (subscriber, #24596) [Link]
How can I check whether my distribution has changed the default value of the option in its kernels?
ext4 and data consistency Posted May 23, 2010 13:29 UTC (Sun) by anton (guest, #25547) [Link] One way is to mount such a file system with the default value (without overriding the default with tune2fs or in fstab), and the checking the actual options in /proc/mounts. That is what I do.Another way would be to check CONFIG_EXT3_DEFAULTS_TO_ORDERED in the kernel config file.
ext4 and data consistency Posted May 23, 2010 13:55 UTC (Sun) by nix (subscriber, #2304) [Link]
Well, OK, you're quite within your rights to stick with an old kernel: but I hope you encounter no other security bugs, or stability bugs, or new hardware, or *anything* else that might require a new kernel!
|
|||||||||||||