* /dev/loop direction?
[not found] <1876351746.1571382.1330323287053.JavaMail.root@zimbra-prod-mbox-2.vmware.com>
@ 2012-02-27 6:25 ` Andrei Warkentin
0 siblings, 0 replies; only message in thread
From: Andrei Warkentin @ 2012-02-27 6:25 UTC (permalink / raw)
To: axboe; +Cc: LKML
Hi Jens,
I am unsure if you are the right person to approach. I have been
on and off working on sparse file support for the loop device
(think mounting QCOW, VHD, VMDK images, if you are interested
the current patches, which are stale by about three months, are at
https://github.com/andreiw/andreiw-wip/tree/master/linux/3.2/block/loop).
As I look at rebasing my current work on top of the latest linux-next,
I ask myself if this is even the right direction to look at. Loop
device has a lot of existing stuff that I've ended up refactoring
and reshuffling, and while I think I've haven't introduced regressions,
the sheer number of odd scenarios with loop means I probably did and
will again. The existing changes already would be a sisyphean task
to split into manageable patches and merge, and the existing loop
design (rigid IOCTL iface that I can't break and no support for
multiple outstanding I/Os) makes me wonder if I should just make
my work as a device-mapper target. Turns out RedHat as done work
on a dm-loop target that (at least at some point) existed and
looks like a good place to start (it can bypass file I/O where it
makes sense, bmap()ing, which was one direction I wanted to take
loop into with future work).
What are your thoughts? Is extending loop to support sparse images
(and by that direction, also COW/differencing images) appropriate?
Or should I just not worry about /dev/loop and fork off or base
on device-mapper?
A
^ permalink raw reply [flat|nested] only message in thread