I formatted the backup filesystem as ext3. This way, I can simply boot with a Fedora Live CD, mount the backup partition and backup my boot and root partitions to the backup. Of course, I'll need to roll that backup off to another storage media. But this strategy helps when I make major updates to my system because I can easily rollback to an earlier version that is stored locally.

Most importantly, restore works!

Detail
Here's what I did the other day to get 'er going.

First, I booted to my Fedora Live CD. It didn't have fsarchiver installed by default, so I did so. You need to become superuser to do this:[liveuser@localhost ~]$ su[root@localhost liveuser]# yum install fsarchiverLoaded plugins: presto, refresh-packagekitSetting up Install ProcessResolving Dependencies--> Running transaction check---> Package fsarchiver.i686 0:0.6.7-1.fc12 set to be updated--> Finished Dependency Resolution

Update:
When my RAID set was not being checked, an fsarchive of about 760GB took 3.5 hours. Not bad!
***end update***

Restore
Restore works in a similar way. Since fsarchiver allows you to backup multiple filesystems within one archive, you need to specify which filesystem is getting restored.

In the example below, the "id=0" specifies the index (starting at 0) of the filesystem that is in the archive. The filesystem to be restored cannot be mounted: fsarchiver restfs /mnt/backup/lv_root_backup.fsa id=0,dest=/dev/mapper/vg_ogre-lv_root

If you had multiple file systems stored in the archive "lv_root_backup.fsa", then the id number would increment; eg, "id=1" for the second filesystem stored in the archive.

"dest" is the destination filesystem which is getting restored, in this case "/dev/mapper/vg_ogre-lv_root"

Password Protection for Archives
You can also specify a password to password protect your archive. On backup and restore, the password switch looks the same:sudo fsarchiver restfs backup_vg_ogre-lv_root.fsa id=0,dest=/dev/sdb1 -c [password]

RPM Fusion Yo!
Note that you'll need both the free and non-free repositories from RPM Fusion enabled in yum. Don't use the ATrpms repos if you're going to compile from source. I've had strange system problems when I've used them in combination with the Fusion repos.

I was benchmarking the write performance of my RAID set when it seemed to stall out. The process I was running was writing a bunch of zeros to a 20 gigabyte file. I believe the stall was due to the fact that my RAID controller card's battery was disconnected; hence, write-cacheing was disabled.

I let the process try to finish for four hours. I figured it should have finished writing that 20GB file by that time. However, the fact that the system was still slow to non-responsive indicated that activity was still taking place. But, being an impetuous fool, I was anxious to get working on some video and also thought it might be an interesting test of the resilience of the ext4 filesystem if I just shut the system down. So I as a soft reboot did not do the trick, I hard powered the box off.

Sleeping the Sleep of the Dead

In retrospect, I should have let the box finish whatever it was doing, because as you may have guessed it, the box didn't come back up. Here was the first indication from the kernel messages:

Boot has failed..sleeping forever

And in the dmesg output:

can't mount root filesystem

can't access tty job control turned off

Woops. Dracut did find my volume group:

dracut: 2 logical voumes in "vg_ogre" now active

Something was wrong with the root filesystem mount:

mount: you must specify the filesystem type

Just in case, I rebooted with the following kernel parameters in grub to see more debugging and to drop me to an emergency shell to see if I could debug the problem:

kernel .. debug rdshell

What Up, ext4?

Oh boy. So, ext4 is not as resilient as I believed. I thought the best course of action would be to load up Fedora Live, and look at the disk stats. Since fdisk does not work with GPT partitions, I used parted and thought that I'd use e2fsck to fix any bad blocks. After booting the Live CD, here's what I found:

At least the partition is there. But it looks like parted does not have support for checking ext4 filesystems yet:[root@localhost liveuser]# parted /dev/sdaGNU Parted 1.9.0Using /dev/sdaWelcome to GNU Parted! Type 'help' to view a list of commands.(parted) check 1 No Implementation: Support for opening ext4 file systems is not implemented yet.(parted) check 2Error: Could not detect file system. (parted) quit

e2fsck bound!

Let me run e2fsck (which does have support for ext4 filesystems) and see if I can fix the problem:

Emergency help:-p Automatic repair (no questions)-n Make no changes to the filesystem-y Assume "yes" to all questions-c Check for bad blocks and add them to the badblock list-f Force checking even if filesystem is marked clean-v Be verbose-b superblock Use alternative superblock-B blocksize Force blocksize when looking for superblock-j external_journal Set location of the external journal-l bad_blocks_file Add to badblocks list-L bad_blocks_file Set badblocks list

My skills at e2fsck are pretty basic. I use the -n option to make no changes while I review what e2fsck finds out about the array:

I had thought that ext4 gave us the safety of a journalled filesystem (like ext3) with increased performance. You would have thought it could have recovered from being shutdown while writing a bunch of zeros to a 20 gigabyte file.

Ah..that would be a "no." Time to reinstall F12. Ugh. Lesson learned. But I need to know why I couldn't recover a journal. Maybe I did not look in the right place. I need to understand journalling better.

Thursday, February 04, 2010

Time average is a neat effect. It takes a number of frames of video to average or accumulate.

:averagingIn the below video, I show averaging. Averaging lots of frames gives a very ghost-like effect. Average very few frames shows trails of whatever movement is happening. Medium settings are like you've had too much to drink.

:accumulateA second option called Accumulation is just that..stacking one frame on top of the other. If the scene in the frame is well lit, the frame will blowout..make it so bright that all detail will be lost. The detail gets lost quickly too, when just a few frames are being accumulated. Accumulate is more useful for extremely dark scenes, like making very distant stars become more visible, as in the example below. In the example, I show the original and the time averaged result:

There is another time averaging parameter called "Inclusion Or" that I have not used. It is explained in the link to the manual below as are the two options "Reprocess Frame Again" and "Disable Subtraction."

Why Mule?

"Mules are not really stubborn. They can seem lazy because they will not put themselves in danger. A horse can be worked until it drops, but not so with a mule. The "stubborn" streak is just the mule's way of telling humans that things are not right. Mules are very intelligent and it is not a good idea to abuse a mule. They will do their best for their owner, with the utmost patience."About Mules