2000-10-31 19:39:47

by Horst H. von Brand

[permalink] [raw]
Subject: Re: 2.2.X patch query (with initial PATCH against 2.2.17)

Dominik Kubla <[email protected]> said:
> On Tue, Oct 31, 2000 at 01:38:56PM +0000, Riley Williams wrote:
> ...
> > Also, part of my plan was to check that the disk is already in this
> > non-standard format, and refuse to dump if not. This would ensure that
> > doing so didn't overwrite somebody's master boot disk by accident, as
> > such disks will not normally be in this non-standard format.

> Just write a magic number somewhere to the disk and mark these blocks
> bad in the fat. Then just check if the blocks are marked as bad and
> contain the magic number. No need for a special disk format per se...

Why any filesystem at all? Just dump the whole on the diskette in the
drive. If root doesn't know what they are doing fiddling with SysRq, they
deserve it in any case. No FAT, MS-DOS, VFAT or whatever. Just a plain
formated diskette. Remember, this has to be absolutely as simple and robust
as possible, and have minimal impact on the rest of the kernel (no "must
now pull in RW-floppy-format + fat + msdos modules to do SysRq-D", no
"<foo> must be built into the kernel for SysRq-D to work" (at most "floppy
in kernel", more can be hard to swallow in limited environments where this
will be most needed as the only/principal way of looking at logs)).
--
Dr. Horst H. von Brand mailto:[email protected]
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513


2000-10-31 20:23:53

by Andreas Dilger

[permalink] [raw]
Subject: Re: 2.2.X patch query (with initial PATCH against 2.2.17)

Dr. Horst H. von Brand writes:
> Dominik Kubla <[email protected]> said:
> > On Tue, Oct 31, 2000 at 01:38:56PM +0000, Riley Williams wrote:
> > ...
> > > Also, part of my plan was to check that the disk is already in this
> > > non-standard format, and refuse to dump if not. This would ensure that
> > > doing so didn't overwrite somebody's master boot disk by accident, as
> > > such disks will not normally be in this non-standard format.
>
> > Just write a magic number somewhere to the disk and mark these blocks
> > bad in the fat. Then just check if the blocks are marked as bad and
> > contain the magic number. No need for a special disk format per se...
>
> Why any filesystem at all? Just dump the whole on the diskette in the
> drive. If root doesn't know what they are doing fiddling with SysRq, they
> deserve it in any case. No FAT, MS-DOS, VFAT or whatever. Just a plain
> formated diskette. Remember, this has to be absolutely as simple and robust
> as possible, and have minimal impact on the rest of the kernel (no "must
> now pull in RW-floppy-format + fat + msdos modules to do SysRq-D", no
> "<foo> must be built into the kernel for SysRq-D to work" (at most "floppy
> in kernel", more can be hard to swallow in limited environments where this
> will be most needed as the only/principal way of looking at logs)).

Actually, as I had previously sent to Riley (privately), the kmsgdump
patch does exactly what I would want it to do:

1) can dump to a raw floppy disk (cat or dd to retrieve later)
2) can check for a labelled FAT floppy (via MS-DOS DISKLABEL)
- will only dump to FAT floppy if magic label is correct (avoid overwrite)
- will dump in "MS-DOS" FAT format (see below)
3) can be set up to automatically dump and reboot
- writes a simple boot loader at start of FAT floppy which causes BIOS
to continue booting, so we do not hang computer at boot after dump
4) FAT format is "normal" in that mcopy or msdos modules can read it
- does not need fat/msdos modules installed because it is not a fully
formatted floppy, just enough to store 1 dump file in root directory
5) has console mode to view syslogs (with scrolling, etc) after
crash/SysRQ-D in case no floppy is on machine
- can also print logs to printer

http://www-miaif.lip6.fr/willy/pub/linux-patches/kmsgdump/

It has a 2.2 and 2.3 version (nothing recently, probably because of 2.4
freeze). It would probably be a prime candidate for the "loadable SysRq
modules" patch that has been posted to l-k the last couple of weeks.

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

2000-11-21 23:28:57

by Riley Williams

[permalink] [raw]
Subject: Re: 2.2.X patch query (with initial PATCH against 2.2.17)

Hi Horst.

>>> Also, part of my plan was to check that the disk is
>>> already in this non-standard format, and refuse to
>>> dump if not. This would ensure that doing so didn't
>>> overwrite somebody's master boot disk by accident, as
>>> such disks will not normally be in this non-standard
>>> format.

>> Just write a magic number somewhere to the disk and
>> mark these blocks bad in the fat. Then just check if
>> the blocks are marked as bad and contain the magic
>> number. No need for a special disk format per se...

There's much better reasons for using a special format than
that. Horst has hit the main one - code simplicity.

> Why any filesystem at all? Just dump the whole on the
> diskette in the drive. If root doesn't know what they
> are doing fiddling with SysRq, they deserve it in any
> case. No FAT, MS-DOS, VFAT or whatever. Just a plain
> formated diskette.

That argument's a non-starter in my book - the difference
between writing a raw floppy and one with an MS-DOS type
filesystem on it comes down to prepending a fixed header to
the data, nothing more.

The MS-DOS type of filesystem is one of the simplest one can
get, but the standard version thereof used with floppies is
just a PITA to work with. What I've done is to remain
compatible with it, but tweak the parameters to produce a
much simpler version thereof.

> Remember, this has to be absolutely as simple and
> robust as possible, and have minimal impact on the
> rest of the kernel...

That's precicely why I'm using the modified filesystem I
referred to in a previous post. Can I suggest that, before
you complain any more about it, you actually try it out? I
wrote and released the formatter that produces the said
filesystem many months ago now, and can easily send you a
copy to play with. It's also its own source code, as the
said formatter is written entirely as a BASH shell script,
and the fact that it's done that way should speak for itself
as to the simplicity of the format used.

Basically, from a programming point of view, it comes down
to writing a raw disk, but prepending a fixed header (size
4k on a 1440k floppy) to the log being written, and gaining
a LOT of advantages with virtually no disadvantages.

For reference, here's a few of the features of the said
format:

1. Disks in this format can be read from and written
to by MS-DOS 2.11, 3.10, 5.00 and 6.22 and by Windows
95, 98 and NT (all tested).

2. Disks formatted in this format do NOT use any extra
tracks or sectors per track over those formatted in
the standard format.

3. From a programmer's viewpoint, the resulting format
is MUCH simpler to handle than the standard one.

4. The data area available on the disk is maximised for
any particular physical layout.

The first two features mean that the resulting disks can be
used on ANY standard floppy drive. The third means that the
so-called bloat just will not exist.

The fourth is the one that people seem to have concentrated
on, but is irrelevant for this application. That particular
feature is only really relevant for backup disks.

> ...(no "must now pull in RW-floppy-format + fat +
> msdos modules to do SysRq-D", no "<foo> must be built
> into the kernel for SysRq-D to work" (at most "floppy
> in kernel", more can be hard to swallow in limited
> environments where this will be most needed as the
> only/principal way of looking at logs)).

None of that is required to use this format - it is designed
to (a) be fully compatible with the requirements of MS-DOS
2.00 and later (including WIndows 9x and NT, and (b) be as
simple as possible for the programmer to code.

Best wishes from Riley.