Saving Your Data Bacon with Write Barriers and Journal Check Summing

Saving Your Data Bacon with Write Barriers and Journal Check Summing.

-- Tom

 

I'm very wary of generic suggestions for filesystems, because they can be extremely dangerous. The worst part is, the concepts of filesystem tuning and memory tuning are pretty much voodoo. Except huge companies like Google, IBM, RedHat and such, very few players have the resources to really test the effects of these changes on a large scale.

Another way of making sure your data is saved is by more frequent syncing. You can do that by adjusting the dirty ratio and associated tunables.

But then, there's pdflush to take into account. By default, the kernel has two processes active and runs new threads if needed to sync all the data, but maybe you want to start with 4 or 8? And what does this mean when you work with many small files and few large ones?

And so it goes: magic. Therefore, any unequivocal answers regarding filesystem tuning are most likely one-man wonders - and very, very dangerous for daily use, especially if you do not understand what's going on.

Editing /etc/fstab is dangerous, beyond the mere chance of screwing up the table. What about long-term effects, performance, etc?

Mrk

 

My recipe for saving data bacon: backups. Backups backups backups. Keep your personal data backed up somewhere. And to back up your whole filesystem you can do this:

Code:

$ su -
# cd /
# tar -czvpf backup.tar.gz --exclude=tmp/* --exclude=sys/* --exclude=proc/* --exclude=backup.tar.gz /

And put the resulting tarball on a CD. Next time you have to restore the filesystem, you boot from a live medium, untar (tar -xzvpf) the tarball onto your hard drive, chroot in, edit fstab for the new partition setup, reinstall GRUB... and you're done.

 

Man, you guys put way too much crap into this simple man's head. Don't stop.

 

Or you can just use BSD or Solaris and use ZFS which does all this OOTB. Or, you can wait for btrfs to finalize on Linux.