Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

I'm going to be embedding Ubuntu on an embedded device. I'm using a combination of aufs and a read only root to ensure that my root fs doesn't get corrupt. However, I want to be able to store logs, so I'm making a special rw partition for /var/log. The device is going to undergo hundreds of power failure events.

In the event that the partition gets corrupted due to power failure, I want the system to work properly anyway. I'd like the partition to automatically get reformatted in case of corruption. Is there an easy way to configure this?

share|improve this question
add comment

2 Answers

up vote 4 down vote accepted

Run fsck with a set of options that specify no user interaction. Test its return value to see whether it could repair the filesystem: the return value will be 0 if there were no errors, 1 if there were correctable errors, and a larger value if something bad happened. For example, with ext[234], run e2fsck -p.

e2fsck -p /dev/disk/by-label/logs
if [ $? -ge 1 ]; then
  mke2fs -L logs /dev/disk/by-label/logs
fi

If your running environment permits it, consider logging through the network instead (you need IP connectivity). Even Busybox can do it:

syslogd -R logserver
klogd

On the log server, listen on UDP port 514. You can just dump everything that comes in to a file, or you can add origin and date stamps on each line, or you can run syslog locally.

share|improve this answer
    
Unfortunately I can't log over the network. We're on a byte-charged cellular connection. –  David Pfeffer May 5 '11 at 23:53
    
fstab lists options like errors=continue or errors=remount-ro. Is there any documentation for this anywhere? –  David Pfeffer May 6 '11 at 12:46
    
Finally got around to testing this. Unfortunately, the recreation of the fs dumps the label. You need to also relabel. –  David Pfeffer Nov 5 '11 at 1:30
    
One last issue; if the fs itself is corrupt, sometimes the label is killed too. Is there a way to write the label or uuid into the partition table instead of into the fs? –  David Pfeffer Nov 7 '11 at 18:23
    
@DavidPfeffer There's no room in the partition table. There's enough room for the label in the partition's boot sector, if the partition is not bootable (put the label where the bootloader would go). I'd need to look up the right offsets. I would not advise this, though: can't you make both the label and the partition id part of your build-time or deployment-time configuration, so that they're stored on a read-only filesystem? –  Gilles Nov 7 '11 at 18:28
show 1 more comment

Just use a filesystem that does not get corrupted from power failures, like ext3 or 4.

share|improve this answer
1  
That's not going to work. Any file system, including journalled ones, are still susceptible to eventual corruption from power failure. –  David Pfeffer May 5 '11 at 18:42
    
@David Pfeffer no, they aren't; that is kind of the whole point of the journal. –  psusi May 5 '11 at 18:49
1  
@psusi: I'm sorry but that's totally false. Journals do their best to protect the data integrity, but metadata can go bad or the journal itself can become corrupt. Parts of the physical disk can go bad as a result of sudden power down and journaling doesn't protect against that; you'd need to remap sectors. Power failures are a very bad thing for rw file systems, even journaled ones. –  David Pfeffer May 5 '11 at 19:13
    
In fact, Linus himself wrote a long post on why he disliked ext4 by default because of some of the assumptions it makes, which caused it to be less able to handle power failure than ext3. –  David Pfeffer May 5 '11 at 19:14
1  
@David Pfeffer: loss of power does not cause physical damage to the disk. It can leave an individual sector only partially written, which will cause it to error when you try to read it due to the bad ecc. Trying to write to it will work fine. Any metadata update where this happens will be rewritten when the journal is replayed, thus fixing the problem. Even if that were not the case, the damage would be limited and not result in the entire fs being damaged beyond all recognition and repair. Furthermore, ext4 is MORE able to handle power loss due to having barriers enabled by default. –  psusi May 5 '11 at 20:12
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.