linux-kernel - /dev/loop direction?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <1359683961.1571598.1330323943766.JavaMail.root@zimbra-prod-mbox-2.vmware.com>
Date:	Sun, 26 Feb 2012 22:25:43 -0800 (PST)
From:	Andrei Warkentin <awarkentin@...are.com>
To:	axboe@...nel.dk
Cc:	LKML <linux-kernel@...r.kernel.org>
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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/