lkml.org 
[lkml]   [1999]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: scary ext2 filesystem question
   Date: 	Sat, 2 Jan 1999 13:51:33 -0500
From: Raul Miller <rdm@test.legislate.com>

I agree that it would be very nice for fsck to have some kind of logging
mechanism.

This is something I've been thinking about. In fact, in the latest
e2fsprogs, the problem reporting has been standardized and goes through
a single choke point, specifically to make logging easier. My current
thinking is to write out a binary log file, which can be interpreted
later using an appropriate program. Part of the reason for doing this
is so that the binary file can contain a lot of information about the
filesystem (possibly including a snapshot of the superblock and block
group descriptors), so that people who ask me for help can send me
a single file --- since obviously people don't bother to read the e2fsck
man page stating what sorts of information I need so that I can help
them. Another reason for using a binary log file format is for
compactness reasons, since one of the places where these log files might
be stored is on the root partition (for all but the root filesystem,
obviously).

The problem of where to store the log files is actually an interesting
one. The log file you most badly want to have is the one after the
catastrophic fsck run, but at that point you might not want to mount the
filesystem read/write. So, even if you a standard rc script which
stores the log file in RAM disk and then copies the log file from the
RAM disk to the disk after the filesystem is mounted read/write, that
might not necessarily be the right thing.

So I've been thinking that one of the options might be to store the
binary log file on a floppy disk, and that might be the approach that's
used when running e2fsck from a rescue disk.

Another design question is how many log files to save? A user might
reboot the system several times while trying to fix a mysterious system
problem, and so simply saving the last 2 or 3 log files isn't
necessarily the right answer either.

So this is actually an interesting problem, and getting the design right
so that it works for mere mortals, and not just kernel weanies has some
subtle points that have to be gotten right.

- Ted

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:2.026 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site