Re: Re: Ext3fs and fsck
Alan Shutko wrote:
>Paolo Falcone <fallenlordx@edsamail.com.ph> writes:
>
>>>blaubaer:~# e2fsck /dev/hdb1
>>>e2fsck 1.25 (20-Sep-2001)
>>>/dev/hdb1 is mounted.
>>>WARNING!!! Running e2fsck on a mounted filesystem may cause
>>>SEVERE filesystem damage.
>>
>> This is default behavior. But you need to delete the journal
>> file first, else you wreck your ext3fs partition, before committing
>> to fsck.
>
>No, e2fsck works fine on ext3 partitions. It just doesn't want to
>work on mounted partitions. Remount root as read-only (mount / -o
>ro,remount) and try it again.
ok... I've done remounting root as read-only compared to deleting the
journal. It's much easier to delete the .journal file (since you
can have it reinstalled with the tune2fs command) but it's quite
safer (since whole data info is committed to the journal for a
transaction, the journal can be replayed to the last correct commit
to disk. By deleting the journal, you can have a fresh start, for
fsck to check the disk in the usual way (without checking the
journal. It is theoretically possible that a passive erroneous
transaction wherein the system viewed it as a correct commit can be
committed to disk. Replay the journal and you replay a potential
problem).
Note that you lose whatever means to replay the previous journal
transactions this way. Thus the warnings. (AFAIK, .journal is a
file to denote the additional journal inode)
You're right that it is very dangerous to have fsck run on a
mounted partition (but sometimes you don't have a choice, especially
when your hard drive goes flakey).
Anyway, I'm offering an alternative.
>> The second one is to tweak your ext3fs partition. issue:
>>
>> tune2fs -c0 -i0 /dev/hdb1
>
>Bad idea. From the tune2fs man page
>
> You should strongly consider the consequences of
> disabling mount-count-dependent checking entirely.
> Bad disk drives, cables, memory, and kernel bugs
> could all corrupt a filesystem without marking the
> filesystem dirty or in error. If you are using
> journaling on your filesystem, your filesystem will
> never be marked dirty, so it will not normally be
> checked. A filesystem error detected by the kernel
> will still force an fsck on the next reboot, but it
> may already be too late to prevent data loss at
> that point.
>
>and
>
> It is strongly recommended that either -c (mount-
> count-dependent) or -i (time-dependent) checking be
> enabled to force periodic full e2fsck(8) checking
> of the filesystem. Failure to do so may lead to
> filesystem corruption due to bad disks, cables,
> memory, or kernel bugs to go unnoticed until they
> cause data loss or corruption.
Well, I'm fully aware of that. That's why they issued warnings on
this (I've read this man page too before I posted) However, since
ext3 commits whole data info (and not just metadata) into the
journal, might as well take advantage of the journalling mechanism.
You can, however, force checks via the recommended method. Normally,
you won't have to be doing the maximum mount check (but as always, it
is your responsibility to do mount checking). I'm just offering a
fast solution to the problem, giving the advantage offered by the
journalling in ext3 (as implied by the manual entry you provided)
Generally, I'll agree that ommitting the fs checks is quite a bad
idea if you aren't using journalling (who'll want a maximum file
when you're using gigabytes of hard disk space? that's way too
slow and terse. When you have a better alternative of just replaying
the journal to the last correct commit to disk?) Better not use
journalling then if you'll use ext3fs like ext2. It will be more
convenient to do that mount count on system development time than
on quite an inopportune time during the day then start the long fsck.
Note that what I recommended is not an excuse for one not to do
the maximum file system check, to make it all clear. Just transferred
the responsibility of doing the task from the machine to the
system administrator (which is part of his job anyway)
I won't generate a flame on this issue, though (technical papers can
be thrown, but it won't help solve the problem presented), but
I do believe that you've got a point, too. And a good one.
>> You won't really need fsck unless you screw up big time (playing
>> around as root most of the time does that...).
>
>Untrue.
I'm referring to the frequent checking with the maximum mount counts.
The fsck program (aside from fixing file system errors) is the one
responsible for the boot time file system checks (at least that's
what the manual and the books on OS say). The journal quite
does the work it's designed for. No need to overdo fsck. But, as I've
said, doing the fast solution commits you to do another task in
your system administration.
That's why it's also not recommended to play around as root. You can
accidentally wreck your filesystem with one wrong, accidental move.
You better not mess up with fsck (that's what it all means) or you
might end up crying (like fsck'ing a mounted partition and waking up
after the long fsck that you're just fscked up. I know this as I've
done this quite often when I was still working on an environment
with frequent power fluctuations and no UPS available)
Hope I made my point clear, if it was misconstrued. Not that I'm
refuting anyone's point. As said, there's lots of solutions (BUT
NOT THE MICROSOFT SOLUTION).
Paolo Falcone
__________________________________
www.edsamail.com
Reply to: