| View previous topic :: View next topic |
| Author |
Message |
Aniruddha
Veteran
Joined: 18 Feb 2006
Posts: 1770
Location: The Netherlands
|
 Posted: Sat May 17, 2008 5:23 pm Post subject: Are all ext3 users at risk? |
 |
|
According to Wikipedia ext3 needs the barrier=1 option to be set. I myself had a nasty experience with a severe ext3 crash. Is Wikipedia right? And if so wouldn't it be a good idea to add it to the Gentoo handbook?
| Quote: | Ext3 does not do checksumming when writing to the journal. If barrier=1 is not enabled as a mount option (in /etc/fstab), and if the hardware is doing out-of-order write caching, one runs the risk of severe filesystem corruption during a crash.[13][14] (This option is not enabled by default on almost all popular Linux distributions, and thus most distributions are at risk.)
Consider the following scenario: If hard disk writes are done out-of-order (due to modern hard disks caching writes in order to amortize write speeds), it is likely that one will write a commit block of a transaction before the other relevant blocks are written. If a power failure or kernel panic should occur before the other blocks get written, the system will have to be rebooted. Upon reboot, the file system will replay the log as normal, and replay the "winners" (transactions with a commit block, including the invalid transaction above which happened to be tagged with a valid commit block). The unfinished disk write above will thus proceed, but using corrupt journal data. The file system will thus mistakenly overwrite normal data with corrupt data while replaying the journal. If checksums had been used (if the blocks of the "fake winner" transaction were tagged with mutual checksum), the file system could have known better and not replayed the corrupt data onto the disk. |
Some more info:
| Quote: | ext3 is very good, but...
February 8, 2006 - 7:11pm
maverick
I find ext3 very reliable if not the best FS around. If you have trouble with it, it's probably because you have your disk cache setup in writeback mode. Almost all todays IDE/SATA disks come with write cache turned on by default. While ext3 goes to great length to keep your data safe and consistent it actually doesn't have direct control of your disk(s), so if disk is "lying" that block is safe on platter when it actually is not (but in its volatile memory, instead) ext3 (or any other filesystem) can't do much about it. And with todays larger and larger on disk caches (4, 8, 16MB) there's a lot of data to be lost when you suddenly lose power.
OK, enough theory. Do this: mount all of your filesystems with I/O barrier turned on. Something like this (example line from my /etc/fstab):
/dev/sda5 / ext3 defaults,barrier=1 1 1
What it means is that when ext3 really needs data to be on the platter (and not in the disk cache!) the disk will comply (if it's not too old, hopefully not). That is somewhat better than mounting partitions in so called sync mode where each and every write operation would be synchronous and everything would get much slower. Try it and you will be amazed how ext3 can be good when it comes to reliability in corner cases.
And BTW, that sync from cron idea wouldn't help at all. First of all, sync is asynchronous - it doesn't guarantee that data is on disk when it returns. And second thing: ext3 already takes care not to cache things in memory too long (or when it would not be appropriate) so don't bother with sync it will just slow things down with none increased reliability.
Hope this sheds some light on your problem.
-- |
http://kerneltrap.org/node/6173
_________________
Help Gentoo improve, do some bug wrangling! |
|
| Back to top |
|
 |
frostschutz
Veteran
Joined: 22 Feb 2005
Posts: 1913
Location: Germany
|
| Posted: Sat May 17, 2008 6:33 pm Post subject: |
|
|
Well what do you say if I tell you that you can't always use barriers even if you want to?
| Code: | | Disabling barriers, not supported by the underlying device |
with a power failure, or crash, there is always a risk of data loss. it's a problem, barriers or not. |
|
| Back to top |
|
|
yabbadabbadont
Veteran
Joined: 13 Mar 2003
Posts: 4739
|
| Posted: Sat May 17, 2008 6:43 pm Post subject: |
|
|
Between using the journal_data option, and a good UPS, I doubt that you would ever have a problem. (I certainly haven't, but that's hardly a valid statistical sample...  ) |
|
| Back to top |
|
|
manaka
Apprentice
Joined: 23 Jul 2007
Posts: 158
Location: Oviedo, Spain
|
| Posted: Sun May 18, 2008 11:08 am Post subject: |
|
|
Write barriers minimize data corruption risk, leaving it at a marginal level (no system can guarantee zero risk, even the most expensive one...!)
They are a new feature introduced in the 2.5/2.6 series... The idea is to separate requests in groups... The requests issued before the barrier are guaranteed to be committed to the physical media after the ones issued afterwards (see /usr/src/linux/Documentation/block/barrier.txt for a thorough explanation  ). They are implemented using either ordered writes or cache flushes (depending on the capabilities of the underlying devices)...
Without them, if you want to truly avoid data corruption risks, you have 2 possibilities:
- Disabling write cache on your hard discs.
- Using a battery-backed RAID controller.
_________________
Javier Miqueleiz
"Listen to your heart. It knows all things, because it came from the Soul of the World, and it will one day return there." |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Other Things Gentoo
