lkml.org 
[lkml]   [1999]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: New partition type?
Hi Andries.

On Sat, 8 May 1999 Andries.Brouwer@cwi.nl wrote:

>> I would start by proposing a partition type number for it, my
>> choice being 0xfc as 252 decimal doesn't appear to be in use.

>> Andries: Can you confirm this?

> Yes, I do not know of any system that uses type fc.

Do you also maintain fdisk and the like? If so, can you add this to
the table of partition types in the ones you maintain, and pass it on
for inclusion in any you don't that you know who does?

FC SysLogFS

> Concerning crash dumps and the like, this is a topic that comes
> up regularly. You may want to read linux-kernel archive.

I've been keeping copies of all mails in l-k since I first subscribed
to it, and am used to the frequency with which this topic comes up.
That's why I proposed it...

> Probably the main objection to

> 1. Write the oops to a dedicated oops partition.

> is that when the kernel crashes nothing can be trusted. In such
> a situation it may be very unwise to start writing to disk.

As I see it, there are certain restrictions on what one can do when an
oops occurs if one's still to be safe. As a result, I would see such a
file system being used as follows, for performance reasons:

1. Define a flag ThisIsAnOOPS which defaults to FALSE, and is only
set to TRUE by the code that detects that an OOPS has occurred,
but ensure that it is set before trying to log the OOPS.

2. At the beginning of the kernel syslog routine, insert code to
call the routine to write the message to the LogFS partition.
Have this code included only if the relevant kernel configuration
option is set. I would use CONFIG_LOGFS for this purpose, so this
would look something like the following:

#ifdef CONFIG_LOGFS
syslogfs( message );
#endif

3. In the LogFS routine (also only included if the above option is
set), check the ThisIsAnOOPS flag. If it's FALSE, use the normal
fseek/read/write/etc calls to append the message, but if it's
TRUE then use a routine that assumes that only direct writes
that do not require any interrupts, DMA or the like will work,
and that all buffering systems are hosed.

4. Note that the assumptions made in (3) probably also imply that the
relevant code will be specific to the HD interface type, so the
early versions will probably say EIDE only, no SCSI or the like,
as I only have EIDE disks to play with...

Can somebody offer a critique of the above analysis please?

Best wishes from Riley.

+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html


-
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:51    [W:0.049 / U:0.760 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site