> From: Boyd Stephen Smith Jr. [mailto:b...@iguanasuicide.net] > Sent: Thursday, April 29, 2010 7:20 AM > > Both XFS and Ext3/4 recover through journal replay, and it is usually > enough. Rarely, a manual filesystem check will be required, and xfs_check > is usually much faster than fsck.ext3 or even fsck.ext4.
They only journal filesystem metadata, not the file data iself. If changes to a file haven't been flushed to disk before the power goes out, you'll end up with a perfectly consistent filesystem (thanks to the journal), but with a file or two (or more) with garbage in it. This is why at the beginning of this thread I recommended a filesystem that uses copy-on-write and preferably checksums your data. However, I don't follow my own advice, probably because I've been using XFS for so long (since 2.4 kernel when you had to download the patches from SGI). I personally haven't had a problem with data loss from power outage as a result of XFS corrupting my files. I believe this is because if a regular file (not a database) is in the process of being written when the power goes out, even if every write is synced to disk, unless whatever was writing to it has finished writing, then the contents of the file are invalid anyway, and no filesystem will protect you from that. For example, if my MythTV backend is recording a TV show and the power goes out in the middle of the recording, I will delete it and let MythTV re-record at a later date. It makes no difference if every byte in that file is correct or not up to the point of the power failure. The window of failure is when the process doing the writing closes the file, and if the power now goes out before everything is synced to disk, then you will have a corrupted file that otherwise wouldn't have been. BTW, regarding UPS's. The number of times my computer was improperly shut down as a result of a power outage is far less than the number of times other problems have caused improper shutdowns: e.g. hardware failures such as a power supply going bad, system overheating, kernel crashes, or other system lockups that require you to hit the reset button. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/007201cae7cd$3af7a2e0$b0e6e8...@net
