[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sat, 11 Nov 2000 21:13:11 -0500 (EST)
> If one repartitions a drive, the partitions may have been resized or new
> partitions may have been created. How does this information propagate to
> the kernel devices associated with the partitions and how are devices
> for new partitions created?
Like I said, the kernel doesn't give you a way to do this anew after boot.
Either one needs to be added, or else we need to just do it at the Hurd
> You suggest telling the storeios to go away, however, how does one know
> which storeios are attached to the device?
One doesn't. Once some user of a storeio node (i.e. /dev/hd0s1 or
whatever) has done file_get_storage_info and instantiated his own store
using the underlying storage (this is what libstore will do), there is
nothing linking that user back to the storeio node. Perhaps what we want
to do is add some feature to file_get_storage_info like a port that dies
when the underlying storage info is changing. Alternatively, we could just
keep track via the open file ports that someone is using the underlying
storage info and give EBUSY for attempts to reconfigure the store until
they are all gone.
> hd0 is a storeio translator.
Please be precise; we have proven our ability to confuse each other with
vague terminology. storeio is a program that acts as a translator. hd0 is
the name of a Mach device; /dev/hd0 might be the name of a node on which
you have an instance of the storeio translator.
> It could provide get and set methods for the partition table.
That doesn't make a lot of sense. hd0 as a device or store is the whole
disk, in which the first sector just happens to contain some data that can
be interpreted as a partition table.
> > In the longer term, the proper thing is to have partition handling done
> > altogether at the Hurd level rather than the kernel level, and then
> > naturally it would be handled through libstore. But rather than libstore
> > knowing anything about partitions, it makes more sense to have a translator
> > similar to storeio that understands partition table formats and uses the
> > existing remap store type to implement partitioning of an underlying store.
> Could you go into a bit more detail on this proposal.
It ought to be pretty self-explanatory. The simple approach is to have a
variant of storeio that takes a switch telling it what partition to select
within the device. Then you would do
settrans /dev/hd0s1 /hurd/storeio --partition=s1 hd0
or somesuch. It would then open a device store on hd0 and from that create
a remap store for the subrange of the device that constitutes the
partition. This differs from how we do things now only in moving the
partition handling from the kernel to the Hurd level, and is otherwise the
same. Then we can consider at the Hurd level how we want to deal with
The higher-class approach would be to have a filesystem that provides a
virtual directory of partitions.
- fdisk, Neal H Walfield, 2000/11/10
- Re: fdisk, Roland McGrath, 2000/11/10
- Re: fdisk, Neal H Walfield, 2000/11/11
- Re: fdisk,
Roland McGrath <=