On Wed, 30 Oct 2013, Edward Ned Harvey (lopser) wrote:
From: [email protected] [mailto:[email protected]]
On Behalf Of matthewhall
May I enquire as to the nature of the filesystems on these VMs?
It surprises me that a sudden inability to write to the block device
beneath is causing such hassle at the FS layer, ext3 upward (as is
standard under RH) has a pretty robust journal system.
This is what I was going to say, thank you Matthew.
I hear other people here instructing how to automatically fsck on startup. I
don't see why that would be necessary, unless you're running EXT2 on a very old
version of redhat.
Ext3, Ext4, Btrfs, and anything else that I can imagine using, should boot up
just fine.
The whole point of journaling is that the filesystem effectively does "fsck" on
the fly, every time it accesses an inode, it checks the consistency. That way, the work
of fsck is spread out during normal operation, rather than requiring manual intervention,
or a really long wait time for system to reboot after crash.
this is one of those theory vs practice things (in theory, theory and practice
are the same, in practice they are not)
in theory a journaled filesystem never needs to be checked.
in practice it's not always true. It's almost always true that the filesystem
will be usable after an unexpected shutdown, but usable != clean. a check is a
good indea if you can afford the time and I/O
the bigger problem is going to be recovering applications, especially
applications that don't implement proper data safety with f*sync() calls. And
given that ext3 had pathalogically bad behavior with f*sync(), most app
developers aren't going to use them.
David Lang
_______________________________________________
Tech mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
