Discussion:
[Ext2-devel] e2fsck exit code
Andrew Morton
2001-06-16 07:15:44 UTC
Permalink
Ted,

It seems that if e2fsck deletes an orphaned inode, and the check otherwise
comes up clean, it prints "***** FILE SYSTEM WAS MODIFIED *****" and
yields a non-zero exit code.

This is confusing my recovery testing scripts - they think something
went wrong.

Intentional?
Andreas Dilger
2001-06-18 17:00:22 UTC
Permalink
Andrew writes:
> It seems that if e2fsck deletes an orphaned inode, and the check otherwise
> comes up clean, it prints "***** FILE SYSTEM WAS MODIFIED *****" and
> yields a non-zero exit code.

I hadn't ever noticed this. Is this for orphan recovery without journal
recovery? I normally have 2 orphans on my root fs because of pcmcia, but
I never have problems during recovery. Maybe it is a Mandrakeism that
it aborts on an exit code 1 (my rc.sysinit is OK with an fsck return code
of 0 or 1).

Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
Stephen C. Tweedie
2001-06-19 09:29:52 UTC
Permalink
Hi,

On Mon, Jun 18, 2001 at 11:00:22AM -0600, Andreas Dilger wrote:

> I hadn't ever noticed this. Is this for orphan recovery without journal
> recovery? I normally have 2 orphans on my root fs because of pcmcia, but
> I never have problems during recovery.

I just had a thorught --- what happens if you take a crash during
e2fsck orphan recovery?

The kernel gets this right --- journal replay happens first, then
journaling is enabled, then the orphan recovery is done under the
protection of the normal journaling mechanisms. A crash during orphan
recovery can be dealt with by replaying the log and continuing with
the new orphan list.

e2fsck cannot deal with this in the same way --- at least, not without
implementing the ext3 journaling mechanism internally! However, it
can at least try to protect against the situation by setting the
filesystem to be marked unclean while orphan recovery is in progress.

Ted, is this already done or do we need to fix this?

Cheers,
Stephen
Theodore Tso
2001-06-19 01:29:25 UTC
Permalink
On Sat, Jun 16, 2001 at 05:15:44PM +1000, Andrew Morton wrote:
>
> It seems that if e2fsck deletes an orphaned inode, and the check otherwise
> comes up clean, it prints "***** FILE SYSTEM WAS MODIFIED *****" and
> yields a non-zero exit code.
>
> This is confusing my recovery testing scripts - they think something
> went wrong.

Hmm.... The man page for fsck documents exit code 1 as "filesystem
errors corrected", and so the question is whether or not cleaning up
after orphaned inodes is "an error" or not. One could easily argue
that it's not a "filesystem error".

I suspect that for most things it doesn't matter, since most boot
scripts treat exit codes 0 and 1 identifically. I can see how for
your testing framework it would be useful to distinguish between these
two cases.

Patching e2fsck to do this is relatively easy, although the simple way
of doing things would require us to write out the inode and block
bitmaps after doing the orphan cleanup. That's a bit of wasted disk
activity, but the problem is that tracking of when filesystems are
modified is done at a very low level, and e2fsck had made the
fundamental assumption that changes to filesystems only happened when
fixing filesystem problems. On the other hand, I may want to fix this
the hard way, since the directory hashing changes will also require
e2fsck to make changes without those changes implying filesystem
errors.

- Ted
Andrew Morton
2001-06-19 04:43:17 UTC
Permalink
Theodore Tso wrote:
>
> On Sat, Jun 16, 2001 at 05:15:44PM +1000, Andrew Morton wrote:
> >
> > It seems that if e2fsck deletes an orphaned inode, and the check otherwise
> > comes up clean, it prints "***** FILE SYSTEM WAS MODIFIED *****" and
> > yields a non-zero exit code.
> >
> > This is confusing my recovery testing scripts - they think something
> > went wrong.
>
> Hmm.... The man page for fsck documents exit code 1 as "filesystem
> errors corrected", and so the question is whether or not cleaning up
> after orphaned inodes is "an error" or not. One could easily argue
> that it's not a "filesystem error".

OK, thanks. I'll just teach the script to not complain
about minor errors. The Mandrake initscripts get it right,
BTW:

# A return of 2 or higher means there were serious problems.
if [ $rc -gt 1 ]; then
failure "$STRING"
aurora_direct
echo
echo
echo "*** An error occurred during the file system check."
t***@mit.edu
2001-06-19 21:28:30 UTC
Permalink
On Tue, Jun 19, 2001 at 02:43:17PM +1000, Andrew Morton wrote:
>
> OK, thanks. I'll just teach the script to not complain
> about minor errors. The Mandrake initscripts get it right,
> BTW:

I'm pretty sure everyone gets this right.... otherwise they'd force
the user to stop whenever there are many minor problems which e2fsck
fixes as part of "preening" the filesystem, and that gets users
grumpy. :-)

- Ted
Continue reading on narkive:
Loading...