April 15, 2026 at 6:16 PM, "Samuel Thibault" <[email protected] mailto:[email protected]?to=%22Samuel%20Thibault%22%20%3Csamuel.thibault%40gnu.org%3E > wrote:
> > Hello, > > Mikhail Karpov via Bug reports for the GNU Hurd, le mer. 01 avril 2026 > 00:12:10 +0700, a ecrit: > > > > > I wrote a partfs translator, and I think it works quite well, although > > perhaps > > I'm just not experienced enough to spot any errors, as I'm new to operating > > system development. :) > > I wrote this translator based on the code of storeio, unionfs, and xmlfs. > > The translator receives a disk image and displays the disk partitions as > > separate files in a directory. So, if you pass a disk image with three > > partitions, the translator directory will contain the files device0p1, > > device0p2, and device0p3. > > > Oh, that's nice :) > > Have you tried mounting the resulting nodes? > > I'm sorry it took me some time to give feedback, part of is it that I > wanted to let the idea float a bit before answer. > > One thing that would be really needed for efficiency is to implement > netfs_file_get_storage_info, so that libstore would be able to get the > underlying storage information, and directly get data from there rather > than partfs having to pass data with io_read/write. > > I'm then wondering how this would fit in the "grand scheme". Our current > approach, /dev/hd0s* being always there, is indeed not really good > because it doesn't easily tell the user which partitions are actually > there. We used to have to have this because partitions used to be > handled by the kernel, and then we have moved to > storerio+parted-supported partitions, which brings much more > flexibility. > > Perhaps we could use > > settrans -c /dev/hd0s /hurd/partfs /dev/hd0 > > and then we'd have /dev/hd0s/1, which is almost like before, but allows > the entries to be dynamic. Actually, we could even have some > > settrans -c /dev/hd /hurd/probedisk hd > > and then we'd have /dev/hd/0, and we could have /dev/hd/0s being partfs, > so we'd eventually have > > /dev/hd/0s/1 > > But I'm also thinking that perhaps it could be integrated more with > storeio, i.e. /dev/hd0 can as well also act as a directory with partfs > behavior, so you could have > > /dev/hd0/1 > > and with the probedisk translator, you could have > > /dev/hd/0/1 > > What do people think about it? As someone who is not super technical...so take this with a grain of salt. /dev/hd0/1 seems easier to remember. "mount /dev/hd0/1 /mnt/usb" seems like it will beeasier for me to remember. /dev/hd/0/1 seems long ...? But I really don't understand the merits of one approach over the other. If I understand Oliver's followup email... the latter approach /dev/hd/0/1 allows the node to expose both the raw hard drive and the partition itself. This makes me think of OpenBSD... In OpenBSD to mount my usb stick, I run something like "# mount /dev/sd2i /mnt/usb" But to write an *.img file to that usb stick, I have to use "dd if=bsd.img of=/dev/rsd2c" /dev/rsd2c means write directly to the disk, not to any particular partition. > > Samuel >
