Nope, at least I don't think so. The virtual block device has
these characteristics:
1: host file must be contiguous
2: host file might not be a file at all, just a block range
3: host filesystem code is not used to get the blocks
4: vbd acts like a partition in every way, including speed
5: blocks are calculated as n+vbd, where vbd is the vbd start
You could do this, with the loop device, but you'd have to write some
support programs. What you'd do is given a host file, make sure it's
contiguous, and find its start block, using the appropriate ioctl's.
(See how LILO determines the blocks used for the kernel image file for
an example.) Then open the device (/dev/hda1, or whatever), and set up
the loop device to use that device, with the specified starting offset
for the vbd start.
In other words:
It is possible to create the vbd with the host filesystem mounted,
It is possible to unmount the host filesystem while the vbd runs.
It is not possible to mount the host filesystem while the vbd runs.
It is possible to create the vbd without a host filesystem,
using just the block offset and number. This method _only_ works
for blocks that are not part of a mounted filesystem.
The loop device can satisfy all of the above requirements. The key
point is that the loop device can either create a virtual block device
based on a device OR a file. As you point out, a possible application
of basing a vbd on top of a device is to handle wierd partitions in user
mode. Just read in the BSD disklabel, and then set up the loop device
with the correct starting offset.
In order to completely use the loop device for this applicaiton, we
would need to have a method of manually setting the size of the
partition of the virtual device. Right now, the size is set to the size
of the parent device or file minus the starting offset. We need to
create a new ioctl to restrict the size down to the size specified in
the non-native partition table. This wouldn't be at all difficult,
though.
The loop device is neat technology. But then again, I'm biased. :-)
Thanks to Andries Brouwer for putting in the work to actually get it
into the kernel!!
- Ted