Re: fdisk

[Neal H Walfield]

> > If using device_read and device_write is the Correct Way, how
> > does one cause the kernel to reinitialize the storeios (or is this
> > even necessary)?  
> 
> The kernel doesn't have anything to do with a "storeio", whatever it is you
> mean by that.  I don't think there is any way to get gnumach to reread the
> partition table without rebooting, but I only checked briefly.
> 
>                                                       At any rate, what you
> want to do is just get all relevant Hurd translators to close the device
> and reopen it (or restart the translators).  I think that in the case of
> storeio and the filesystems, you need to restart the translators because
> they provide no way to force them to close and reopen the store; the
> friendly way to do this is with fsysopts -g.

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?

You suggest telling the storeios to go away, however, how does one know
which storeios are attached to the device?  Normally, they are in the /dev
directory, however, this is not a rule.  Second, even if one tells the devices
to go away, they will automatically be restarted as soon as the translators
using them, e.g. the root filesystem, tries to access them.

> > If adding an rpc to libstore is the Right Way, where should this be
> > added?  Is there anything in particular it should look like?  What
> > should a device do that has no geometry?  How about when, e.g., hd0 is
> > modified and the changes need to be propagated to, e.g., hd0s1.
> 
> I don't understand what you mean by "adding an rpc to libstore".  RPCs are
> things in protocols.  libstore is a library of code.  I can't think of
> anything directly libstore should have to do with this, except perhaps make
> it easier to close and reopen a store so as to refresh anything that changed.

hd0 is a storeio translator.  It could provide get and set methods for
the partition table.  Others, such as hd0s1, would reply that they do
not know how to do this.

> 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.

Thanks.

-- 
Neal H Walfield
University of Massachusetts at Lowell
neal@walfield.org or neal@cs.uml.edu