OK, you're getting confused by a couple of things here.
> During startup, my kernel emits the following lines:
>
> Kernel command line: auto BOOT_IMAGE=normal ro root=301 rootfstype=ext3 1
> <lines deleted>
> kjournald starting. Commit interval 5 seconds
> EXT3-fs: mounted filesystem with ordered data mode.
> VFS: Mounted root (ext3 filesystem) readonly.
The root filesystem is definitely getting mounted as ext3, with the
root device as /dev/hda1 (major 3, minor 1). This is a problem, you
apparently have /dev/discs/dist0/part1 listed your /etc/fstab file.
This is causing aliasing problems, but we'll talk about that in just a
moment.
> which seems to indicate that the fs is actually recognized as
> ext3. In my startup script, I later invoke e2fsck on the root fs
> before re-mounting it with r/w access. At this point, e2fsck tells
> me that the maximum mount count has been exceeded and checks the
> file system, which should not happen with journalling in effect.
Sorry, the maximum mount count checks still happen with
journalling/ext3. What ext3 protects you against needing to run fsck
in case of an unclean shutdown.
The reason why ext2/3 filesystems have the capability of specifying
either a time interval or number of read/write mounts before e2fsck
will do a full check is simply a way ensuring against data loss in
case of data corruption caused by hardware failure. Remember, PC
class hardware is sh*t. In any case, if you don't want this, you can
configure the filesystem via tune2fs to not do the periodic e2fsck
tests. To quote from the tune2fs man page:
-c max-mount-counts
Adjust the maximal mounts count between two filesystem checks.
If max-mount-counts is 0 then the number of times the filesystem
is mounted will be disregarded by e2fsck(8) and the kernel.
Staggering the mount-counts at which filesystems are forcibly
checked will avoid all filesystems being checked at one time
when using journaled filesystems.
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 filesys-
tem 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.
See also the -i option for time-dependent checking.
> The check does not detect any errors, and I remount the fs with
> r/w access, which produces the following lines:
>
> EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
> EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,1), internal journal
The reason why the kernel is reporting the maximal mount count even
after e2fsck is run because e2fsck is accessing the partition via the
LVM device, because your /etc/fstab file specified
/dev/discs/disc0/part1. However, the kernel is accessing the
filesystem via IDE device /dev/hda1. This is a really bad thing,
since it means that buffer cache can get out of sync.
> Then, after the system has been fully booted, I issue a 'mount'
command and
> get:
>
> ~ $ mount
> /dev/discs/disc0/part1 on / type ext2 (rw)
This is because of what you have in /etc/fstab. The "mount" command
gets its idea of what is mounted via the /etc/mtab file. But the root
filesystem is mounted during the kernel boot process, before the init
scripts are run. Also, the root filesystem is mounted read-only until
after e2fsck is run. So after the root filesystem is checked, and
then remounted read-write, the init scripts initializes the /etc/mtab
file using data from the /etc/fstab file. If the information in
/etc/fstab is not accurate (i.e., is not the same as the root
filesystem specified on the kernel command line when it was booted),
then the information in /etc/mtab isn't accurate, which means that
what the 'mount' command prints won't be accoruate.
> So, while all my non-root file systems are correctly recognized as
> ext3, the root fs appears to be mounte as ext2. The contents of
> /proc/mounts, however, look differently:
>
> ~ $ cat /proc/mounts
> rootfs / rootfs rw 0 0
> /dev/root / ext3 rw 0 0
Yeah, /proc/mounts doesn't get the root filesystem right. It prints
the silly line about rootfs, and since it doesn't know what the name
used for the device of the root filesystem (all it knows is the
major/minor number), it prints /dev/root on the second line.
> Is anybody able to explain those apparent inconsistencies? I
> am using both devfs and LVM.
The problems are two-fold. First of all, you should make sure the
/etc/fstab's idea of the root device matches what is used on the
kernel command line. Secondly, the periodic maximum mount checks are
normal. You can turn it off using tune2fs if you wish, if you're
willing to live with the potential consequences. (Note: these issues
are present regardless of what filesystem you use; it just that some
filesystems are designed assuming that disk drives are perfect,
whereas ext2/3, given that it was born on PC hardware, has some design
choices and defaults which are a bit more paranoid about trusting the
underlying hardware.)
- Ted