On Sun, May 09, 2004 at 11:38:17PM -0500, Randy Kelsoe wrote:
> Luciano Miguel Ferreira Rocha wrote:
>
> >>Can you prove that the system uses fsck to check the filesystem's dirty
> >>flag? I can't. I see where it gets called if the filesystem is dirty,
> >>but not before that.
> >>
> >>
> >
> >The last field in /etc/fstab says if a filesystem is to be checked and in
> >what order.
> >
> >When booting, /etc/rc.d/rc.sysinit calls fsck -A, that parses the
> >/etc/fstab field and calls for each filesystem to be checked
> >/sbin/fsck.filesystem_type.
> >
> >
> Yes, I see that fsck gets called if there is a /forcefsck file, or an
> /.autofsck file, or an /fsckoptions file, but not anywhere else.
No, you see where fsck options are *defined* on such cases. Later, they're
actually used.
My fedora system is down and away, but here's from RH 7.3 rc.sysinit:
STRING=$"Checking root filesystem"
echo $STRING
initlog -c "fsck -T -a $fsckoptions /"
rc=$?
STRING=$"Checking filesystems"
echo $STRING
initlog -c "fsck -T -R -A -a $fsckoptions"
rc=$?
As I already said, the -A option tells fsck to parse /etc/fstab and check
all files that are specified to be checked.
>
> >That fsck.filesystem_type is the one that checks the dirty bit on the
> >filesystem (for fsck.* that do something usefull, like fsck.ext2/3, vfat
> >and minix). For fsck.ext3, a check is made for a journal to replay, and
> >if the replay is successful the filesystem is considered clean.
> >
> >
> Where do you see anything that says fsck checks the dirty bit?
There's no such thing as a official "dirty bit". Filesystems do have
features so that the driver and checker can see when the filesystem is
"dirty" and should be checked. It's the fsck.fs that checks that
information, and only it can.
> And as
> for fsck.ext3, don't you think it's odd that it's the exact same size
> as fsck.ext2?
stat /sbin/fsck.ext3:
Links: 3
They're exactly the same file (as is /sbin/e2fsck). Not odd, as it's
really the same filesystem, only with a journal in ext3's case.
> Another thing that makes me still think that fsck does not
> check the dirty bit, is the exit codes from the fsck man page:
>
> The exit code returned by fsck is the sum of the following
> conditions:
> 0 - No errors
> 1 - File system errors corrected
> 2 - System should be rebooted
> 4 - File system errors left uncorrected
> 8 - Operational error
> 16 - Usage or syntax error
> 32 - Fsck canceled by user request
> 128 - Shared library error
> The exit code returned when multiple file systems are checked
> is the
> bit-wise OR of the exit codes for each file system that is checked.
>
> I don't see anything that says "The file system is dirty/not clean ". My
> guess is that the dirty bit is checked by the kernel or the disk driver
> before the rc.sysinit script gets run.
You don't see it because when the filesystem really is dirty, a *check*
has to be made, and the result of that check is the exit code.
> From 'man boot':
>
> Kernel Startup
> When the kernel is loaded, it initializes the devices (via
> their
> drivers), starts the swapper (it is a "kernel process", called
> kswapd
> in modern Linux kernels), and mounts the root file system (/).
The mounting is before any check is made on the filesystem. Obvious, as
fsck.* aren't available prior to mounting /.
*But*, on journaling filesystems (reiserfs, ext3, xfs, jfs), the *driver*
sees that the journal has data, and commits it, then ending with a clean
filesystem (hopefully, but not always. In that case, the fsck will check
the filesystem).
Don't forget that the root filesystem is mounted only read-only, and only
after being checked by fsck is it mounted read-write.
> >A reason you don't see where fsck gets called if the system isn't dirty,
> >could be that you're not noticing the message saying it's clean. :)
> >
> I am not talking about when I boot my machine. I was saying that I did
> not see fsck being called in the /etc/rc.sysinit script, unless the
> filesystem was dirty, or there was a /forcefsck, /.autofsck, or
> /fsckoptions file.
Search harder :)
Regards,
Luciano Rocha
