On Thu, 2005-07-14 at 19:01, Mike McCarty wrote:
> >>I still haven't seen an argument against having the default mode
> >>be do an extended check.
> >>
> >>
> >
> >Why use a journalled file system then? That is, why would you
> >want to write the journal if you aren't going to replay it
> >to recover?
> >
> >
> >
> >>Is there a way to change the default reboot mode?
> >>
> >>
> >
> >Use ext2 which has the slow fsck as the only way to recover.
> >
> >
> >
> It would be helpful if you actually read what has gone before
> instead of jumping into the middle of an on-going thread.
I saw it go by the first time. Repeating it doesn't make it
make any more sense. If replaying the journal succeeds, then
there is no reason to expect additional corruption to be found.
> The sequence of questions is:
>
> Q: Why does FC2 not do an extended fsck on reboot after
> power failure? It offers the opportunity to do one, but
> by default does only a "short" fsck.
> A: Because you used ext3. It doesn't need an extended
> fsck.
Yes, that's why it wrote the journal in the first place, just
in case the update didn't finish.
> Q: Then if the extended is not needed, why is it offered?
> A: (No satisfactory answer given.)
Disks get corrupted for other reasons than having their
writes interrupted. Fsck can recover from some of them.
> A: If you want to do an extended, then change to ext2.
> A: NO! Don't do that!
>
> Q: Why is ext3 preferable to ext2?
> A: It is journaled. That's why it doesn't need ext fsck.
>
> Q: Then why is extended fsck offered? Is there a way
> to change the default behavior?
> A: Use ext2.
>
>
> So, I ask again. If the extended fsck does no better than
> journal recovery for ext3 file systems, why is it offered?
Other things can go wrong. There is no more reason to expect
them after a power cycle than any other time, but it is a good
time to check if you don't care about how long the system is
down.
> Note: Even a journaled file system is subject to corruption.
Yes, everything breaks. The point of the journal is that
interrupting a write doesn't break the relationship between
used and unused space in the file system.
> Note: Having a write-through cache policy is independent
> of journaling. One can have a write-through or write-back
> without journaling. Both make sense. Journaling is an
> attempt to make a write-back policy more robust.
> Both make sense, though. One reason to have journaling
> when using write-through is that the journal presumably
> takes less time to write than the full transaction, so
> is less likely to get corrupted by power failure than
> the full write, so using journaling with write-through
> is still a reasonable policy.
Regardless of caching policy, allocating space on the disk
takes several operations which can't be done atomically but
have to be completed to ensure consistency between the free
space list and the space allocated to data. If this doesn't
complete, the journal is a quick way of backing out partial
changes. Walking though all the pointers to allocated data
is the slow way. Unless something else has gone wrong you
get the same result. And neither will get back the data that
wasn't written yet.
--
Les Mikesell
lesmikesell@xxxxxxxxx
