On Wed, 1 Aug 2001, Jay R. Ashworth wrote:
> Well, you know, here's the thing. Perhaps *I've* been missing
> something, but isn't the theory of a journalling filesystem "we can't
> guarantee that the drive channel won't fail while we're trying to write
> your data on the disk... so we'll *write it on the disk first*, just in
> case"?
>
> I've never quite gotten that, myself.
>
> If a drive fails in mid write, then there's *going* to be some data
> half-written, no?
Well, a journaling fs (as I understand it, 'natch), only guarantees a
consistent file system (not safe data). That just means no need for
exhaustive fsck.
A journaling fs does this by writing out what it's about to do to a log,
then doing whatever it said it was going to do (free blocks, create
directory, move files). Afterwards, I think it also goes back to the log
and says "OK" when it's done.
If something fails when the log is being written, on reboot the equivalent
of fsck looks at the log, sees it is inconsistent (but that I assume is a
trivial check) and says "oh, the fs is OK".
However, if the failure occurs during the write to the main filesystem,
then on reboot fsck says "oh, the log says that it was about to do
something, but there is no "OK", then the fs is inconsistent. But it has
a good idea of what blocks and data structures are involved, so putting it
back to consistency is pretty fast, too.
If the failure happens at the point of marking "OK", then fsck thinks the
fs is inconsistent. But again, it knows exactly what bits are involved.
When it tries to "fix" it, it should pretty easily realize that
everything is OK and just fix the log.
The difficult part is doing all this asynchronously. And quickly. This
may be where journaling doesn't live up to its promise because it can be
difficult to implement.
I suppose a power spike could subvert a journaling fs (even a "perfect"
one) if it causes the controller to return erroneous return values.
--Jeremy
Jeremy Impson
Sr. Associate Network Engineer
Advanced Technologies Department
Lockheed Martin Systems Integration
email: [EMAIL PROTECTED]
phone: 607-751-5618
fax: 607-751-6025
--
To unsubscribe from this list, send a message to [EMAIL PROTECTED]
with the command "unsubscribe linux-embedded" in the message body.
For more information, see <http://waste.org/mail/linux-embedded>.
