On Tue, Jul 19, 2005 at 02:46:42AM -0400, Ariel wrote:
> Package: e2fsprogs
> Version: 1.37-2
> Severity: important
>
> This was running on a system with a ro / fs changed via remount to rw.
> (So /etc/mtab was not real, since nothing rewrote it afterward.)
> I don't know if this is relevant - since I did the exact same thing in
> the same session to another fs, and that worked fine, created a .journal
> file.
This was the root cause. /etc/mtab has to be real, because tune2fs
needs to know whether or not the device is mounted. Actually, the
library will /proc/mounts first, so presuambly you didn't have /proc
mounted either. If you don't have /proc mounted, but you are mounting
disks and then trying to use tune2fs to add journals, you're just
asking for trouble.
It sounds like you were trying to add a journal very early in the
process, in single-user mode. Why were you doing this and having
/dev/md1 mounted in the first place? Usually users either (a) do
things early in the boot process, with the filesystem unmounted, or
(b) if they can't afford to bring the system into single user mode,
they will add the journal with the filesystem mounted and in
multi-user mode.
You were doing something very strange, which is trying to run with a
bogus /etc/mtab and without /proc mounted, but yet you insisted on
running tune2fs -j on a mounted filesystem --- I'm just trying to
understand why you you were trying to do this in the first place.
We can make this better under Linux 2.6, since with 2.6 there is a way
that we can detect that device is busy, and if /etc/mtab is bogus, we
can detect that the device is busy, and cause tune2fs to abort in that
case.
> a: why did tune2fs mess up
See above.
This is a little bit better in e2fsprogs 1.38 if you are running on a
Linux 2.6 kernel, under 2.6 we can directly detect whether or not the
filesystem is mounted,
> b: you'll notice I had to run fsck twice to get a correct fs
I can't replicate this. The first fsck, if it cleared .journal
because it was deleted (i_links_count == 0), it should complained much
earlier if the superblock had the journal inode set to the inode
number of .journal.
The only way I could have imagined this happened is if the filesystem
was mounted when you ran e2fsck on it. Was that the case? Normally
e2fsck will complain loudly, but you were running with a bogus
/etc/mtab file without /proc mounted.....
> c: the kernel should probably have reacted a little more sensibly to the
> error - i.e. don't send zillions of identical messages - kick out the
> fs, maybe return an error to the process trying to read, but not tons of
> useless messages that effectively froze the machine. (I checked and it was
> mounted errors=continue, since that's the default.)
Because of (a), tune2fs wrote directly to a mounted filesystem, and
that results in enough filesystem corruption that the kernel was going
to start complaining pretty loudly. We'd need to see what the
messages were, but in any case, that's not an e2fsprogs issue....
- Ted
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
