[Mostly resolved] Power outage, will Kubuntu be OK?

[Telengard]

What happened:
Our apartment building lost power for an hour today, and because I don't have a UPS my computer suddenly turned off without Kubuntu being shut down properly. Having been a Windows user for too many years, I'm trained to believe that file system corruption is very likely on such occasions.

What I did:

• Reboot from my Kubuntu install CD and open a Konsole
• fsck /dev/sdb3 (An EXT3 partition on my external USB hard drive)
• Reboot Kubuntu from my hard drive
• Console login
• sudo touch /forcefsck (the filesystem is EXT3)
• Reboot and observe the fsck progress bar
• cat /var/log/fsck/checkroot

$ cat /var/log/fsck/checkroot
Log of fsck -C -f -a -t ext3 /dev/sda3
Sat May 30 13:14:22 2009

fsck 1.40.8 (13-Mar-2008)
/dev/sda3: 169985/6111232 files (1.8% non-contiguous), 14627623/24414783 blocks

My questions:

• Given the sparse output from fsck above, may I safely assume my filesystem is intact and no data was lost?
• Is there a way to make fsck a little more informative about what it is fixing (if any)?
• The next time my computer looses power unexpectedly, what should I do to be better assured my file system remains intact without data loss?
• Is there a thread or article with in depth discussion of backup methods and options?

[toad]

Re: Power outage, will Kubuntu be OK?

Kubuntu will be OK unless you have an untuned ext4 partition where data loss may occur. But you are on ext3 so you are fine Of course, if you have you've just worked ten hours on your thesis and haven't automated saves in OOo or saved manually in between then the data is gone.

As for fsck - read the man file. Most commands have a -v or -V option for verbose output.

Preventing data loss - you could decrease journaling time but what kind of data loss are you fearing? Standard settings are tuned to cater for normal use.

Back up - backintime is a decent programme. If you want a thread I would suggest you search the forum

Also, this is from the ext3 wikipedia entry:

No checksumming in journal

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.[20][21]

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 unrecoverable crash 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. There is a test program available to trigger the problematic behavior. If checksums had been used, where the blocks of the "fake winner" transaction were tagged with a mutual checksum, the file system could have known better and not replayed the corrupt data onto the disk. Journal checksumming has been added to EXT4.[22]

The ext3 barrier option is not enabled by default on almost all popular Linux distributions[citation needed] except openSUSE, and thus most distributions are at risk. In addition, filesystems going through the device mapper interface (including software RAID and LVM implementations) may not support barriers, and will issue a warning if that mount option is used.[23][24] There are also some disks that do not properly implement the write cache flushing extension necessary for barriers to work, which causes a similar warning.[25] In these situations, where barriers are not supported or practical, reliable write ordering is possible by turning off the disk's write cache and using the data=journal mount option.[26]

HTH

[Telengard]

[Mostly resolved] Re: Power outage, will Kubuntu be OK?

Hi toad.

The simple answer to the question I posed in the original title of this thread is most likely, yes. Thanks to your response I was prompted to do additional research on my own.

For fsck, I found the article Running a filesystem check on an ext3 filesystem to be an adequate answer. There is a ton of enlightening information on that page for those who want to take good care of their Linux filesystems.

For backup, I ended up writing a shell script which archives my mission critical data in zip files. I then created a crontab entry which runs the script once per day at 8:05 pm.

$ crontab -e

and then

# m h dom mon dow  command
5  20 *  *  *  /home/ken/bin/autoback.sh

Anyone who wants to try this sort of thing should first read the documentation for crontab:

info crontab

or

man crontab

Thanks very much for your reply.