[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: e2fsck problem

From: Marcus Brinkmann
Subject: Re: e2fsck problem
Date: Sat, 9 Jun 2001 02:11:41 +0200
User-agent: Mutt/1.3.18i

On Sat, Jun 09, 2001 at 01:11:08AM +0200, Moritz Schulte wrote:
> Marcus Brinkmann <> writes:
> > What are the major and minor numbers to a monolithical kernel like
> > Linux or BSD, is the translator setting for the Hurd.
> I see...  So, should we modify the MAKEDEV script so that it creates
> the device files with corresponding major/minor values as parameter to
> storeio?

The question you should ask yourself is: What are the corresponding
major/minor numbers?  This is a concept that doesn't exist in the Hurd,
because it is so limited and doesn't really fit.

> I got e2fsck to work correctly, after adding a --rdev value to storeio
> on the device files.

Yes, but the fix should really be in e2fsck not to make use of these values
on the Hurd.

On Sat, Jun 09, 2001 at 01:13:10AM +0200, Moritz Schulte wrote:
> Marcus Brinkmann <> writes:
> > I should add that there is in principal no reliable way if you stumb
> > on blocks used by some other translator.
> Sorry, I don't understand what you mean here - "stumb on blocks"?

Remember that stores can be much more complex than simply a hard disk
partition or other device.  Stores a simply a collection of blocks from
various sources.  For example, you can create an image file on a Linux
partition and pass the block list of the image file as the root store
argument to the Hurds ext2fs.static root filesystem.  This is all
completely implemented in libstore, no magic required.

Now, how would e2fsck know about that if you had that particular Linux
partition in /etc/fstab?  I don't know if it would be safe to run e2fsck on
it.  It is unless it decides that a block should be moved.  Anyway, users of
libstore can implement their own storetypes, so you can always think up a
scenario where this approach of looking at the translator setting is
unreliable and doesn't provide a clue for e2fsck if it is safe to check or

Anyway, what probably comes closest to this is running "storeinfo" on the
node.  I think that returns detailed information about the backing store. 
This could be parsed, with the above caveats.  But I think it is simplest
for e2fsck just rely on the information in /etc/fstab (why is it unsafe
in Linux?  Because of devfsd?).


`Rhubarb is no Egyptian god.' Debian
Marcus Brinkmann              GNU

reply via email to

[Prev in Thread] Current Thread [Next in Thread]