Les Mikesell <lesmikesell@xxxxxxxxx> 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).
--
Bryan J. Smith | Sent from Yahoo Mail
mailto:b.j.smith@xxxxxxxx | (please excuse any
http://thebs413.blogspot.com/ | missing headers)
