You are not logged in.
Hi there,
Another computer on my network running Windows connected to an external USB HD (formatted NTFS) just caused a major data loss. I switched the user over to Linux, and I am going to format the external drive with a Linux filesystem....
I would like to know which Linux filesystem is the most robust in terms of data preservation. Assuming the worst scenarios, such as power outage during heavy data transfer, or an ignorant user frequently yanking the USB cable on a drive that is writing data, which filesystem will lose the least amount of data? I don't care much about speed, but I do care about reliability and preferably automatic algorithms and automatic recovery or fsck routines to return the drive to a usable state after an abnormality.
Thanks for your opinions!
Offline
Use Ext3 with the journal=data mount option. You could also make it default with 'tune2fs -o data_journal /dev/your_partition'.
1000
Offline
Ah, thanks byte, I've never seen the different journal options for ext3. Very nice. Any other opinions?
Offline
I agree, ext3 with data=journal should be the best option. You probably also want to add the option barrier=1 to enable write barriers.
Offline
OK, good. So tune2fs would be the best way to set this, since it's a temporarily connected USB drive via HAL? Thank you all for your expertise.
Offline
Reading this manual it doesn't seem that you can set default barrier=1 with tune2fs. It seems it must be a mount time option (but I'm not really sure, maybe you could try something like "tune2fs -o barrier=1 /dev/XXX" and see if it works).
This is what the config option says about barriers, in case you wonder if you'll need them:
"This enables/disables the use of write barriers in the jbd code. barrier=0 disables, barrier=1 enables. This also requires an IO stack which can support barriers, and if jbd gets an error on a barrier write, it will disable again with a warning. Write barriers enforce proper on-disk ordering of journal commits, making volatile disk write caches safe to use, at some performance penalty. If your disks are battery-backed in one way or another, disabling barriers may safely improve performance."
Offline
Hello all, I'd like to revive this topic, now that EXT4 seems to be coming of age (Ubuntu now recommending it as default FS). What would you recommend now for the most error resistant filesystem for a worst-case most-ignorant user situation to reduce data loss? Thanks!
Offline
Hello all, I'd like to revive this topic, now that EXT4 seems to be coming of age (Ubuntu now recommending it as default FS). What would you recommend now for the most error resistant filesystem for a worst-case most-ignorant user situation to reduce data loss? Thanks!
Worst-case most-ignorant user = Person who just turns off the computer with the power button (or disconnects a usb drive before unmounting it).
So in this case I'd actually still recommend ext3 with data=journal, since ext4 is delaying its write operations a lot longer than ext3.
(If almost all unmounts are done properly then ext4 with data=journal is probably better.)
http://en.wikipedia.org/wiki/Ext3#Disadvantages
http://en.wikipedia.org/wiki/Ext4#Disadvantages
Btw, about barriers... according to man mount it seems to be an ext4 only option?
Edit : Perhaps ext4 with data=journal and nodelalloc? Or commit=1 or something?
Last edited by scorpyn (2009-10-15 21:47:48)
Offline
Thanks again for the helpful reply, scorpyn. I have read that about the delayed writes with EXT4, but there should be a way to change the delay time? Any real world success or disaster stories with EXT3/4 ?
Thanks!
Offline
ext4 mounted with commit=5 should save data as frequently as ext3 while probably still being "safer". I seem to be unable to find a way to modify that value with tune2fs though (on an ext3 partition), so you'd have to set it when mounting.
You may want to add journal_data to default mount options with tune2fs. Also, I'd consider changing the default error behavior from continue to remount-ro (depending on your level of paranoia etc).
Note that I haven't actually tried all of those options. I have tried some of them though (with ext3).
One interesting thing is that if you want data=journal on an encrypted root partition then you better set it with tune2fs (NOT in fstab) because mount will not be able to go from data=writeback (default) to data=journal with a remount.
So far I've had 0 "serious" issues with ext3, and that's after being forced to use the power/reset buttons quite a lot of times. Next time I'm reinstalling I'll most likely try ext4 though (with data=ordered mode).
Last edited by scorpyn (2009-10-16 23:50:57)
Offline
Very good, thanks scorpyn for your expertise, I'll be using this for my next backup drive format.
Offline
Very good, thanks scorpyn for your expertise, I'll be using this for my next backup drive format.
I wouldn't consider myself to be an expert
Anyway, good luck etc
Offline