> Booting a subhurd from a file system that resides on a sparse file
> currently fails like this: ``ext2fs: pseudo-root: panic:
> get_hypermetadata: disk size (115085312 bytes) too small; superblock says
> we need 419430400''.
This comes from the size of the store reported by libstore. Try storeinfo
and such on the same file and see how it behaves. A sparse file cannot be
used in the normal way that a file's storage is used via
file_get_storage_info and libstore's device backend. Some of its body
corresponds to no device blocks, and you have to use file io to get the
containing filesystem to do the allocation when you write that part of the
file.
I bet this works:
settrans /dev/foobie /hurd/storeio --enforced -Tfile sparse-fs.img
settrans /mnt /hurd/ext2fs /dev/foobie
It seems likely that libstore is not representing this properly. The
file_get_storage_info format doesn't have a way to describe it. The sparse
file's storage should be described as if it were a layered store with some
regions from device and some from "hole". Perhaps STORAGE_ZERO is good
enough to represent "hole", with the understanding that a STORAGE_ZERO
portion of something that's supposed to be writable is a chunk whose
storage changes if you write there. Then a user like libstore would know
that to write those portions it has to use file io. It's probably not safe
to use device io for any part of the file when also using file io, so in
this case it might need to stick to the file backend.
> I can see in the source code (`ext2fs/hyper.c') where this is stemming
> from, but I wonder why, as `ext2fs' itself is perfectly fine with
> handling sparse files, when setting a translator using such a file as its
> backend, for example.
I can't tell whether you are talking about the underlying node on which an
ext2fs filesystem translator is mounted, or about an ext2fs filesystem
containing its own sparse files. Neither case has anything to do with a
filesystem's store.
Thanks,
Roland
_______________________________________________
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
