Messages in this thread | | | Date | Sun, 26 Feb 2012 22:25:43 -0800 (PST) | From | Andrei Warkentin <> | Subject | /dev/loop direction? |
| |
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
| |