Les Mikesell lesmikesell@gmail.com wrote:
Do you have some reason to think it is better to run a full fsck than to replay the journal?
Actually, unless you're doing full data journaling (especially with a NVRAM board), it's almost always _safer_ to run a full fsck instead of just doing a journal replay.
I thought that was the point of using a journalled filesystem.
The point of using a meta-data journaling filesystem is to [near] guarantee the filesystem into a consistent state without having to run a time-consuming fsck. Journaling doesn't guarantee anything as far as reliability (and can actually be worse -- don't get me started on NTFS ;-).
Full data journaling filesystems are better (and worse in some ways) than meta-data journaling filesystem. But full data journaling filesystems using a NVRAM for the journal is near-perfect because you have a commit to near-instaneous, battery-backed DRAM -- which is the journal (not disk) -- before any flush to disk.
(Tangent Warning=ON)
Tying in a recent thread, NetApp's Data OnTap OS is designed to buffer to NVRAM as the journal for the WAFL filesystem. That's why it recovers so quickly and near perfectly -- the OS/filesystem is designed around that advanced hardware capability (which all NetApp filers have).
VALinux used to sell filers with a similar (albeit more conventional) option using a PCI NVRAM board, Ext3 in full-data journaling and NFS in sync mode (instead of async). It wasn't any faster than NFS async, but it was much, much safer (basically async for free).