[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160226210302.GE17997@ZenIV.linux.org.uk>
Date: Fri, 26 Feb 2016 21:03:02 +0000
From: Al Viro <viro@...IV.linux.org.uk>
To: Stanislav Brabec <sbrabec@...e.cz>
Cc: "Austin S. Hemmelgarn" <ahferroin7@...il.com>,
linux-kernel@...r.kernel.org, Jens Axboe <axboe@...nel.dk>,
Btrfs BTRFS <linux-btrfs@...r.kernel.org>,
David Sterba <dsterba@...e.cz>
Subject: Re: loop subsystem corrupted after mounting multiple btrfs
sub-volumes
On Fri, Feb 26, 2016 at 09:37:22PM +0100, Stanislav Brabec wrote:
> Do I understand, that you are saying:
>
> Yes, mounting multiple loop devices associated with one file is a
> legitimate use, but mount(8) should never do it, because it has other
> ugly side effects?
It's on the same level as "hey, let's have an nbd daemon run in qemu
guest, exporting a host file over nbd, import it to host as /dev/nbd69,
set a loopback device over the underlying file as /dev/loop42 and
ask e.g. xfs to recognize that it's dealing with the same underlying array
of bytes in both cases - wouldn't it be neat if it could do that?"
There's no magic. Really. Unexpected sharing of backing store between
apparently unrelated devices can cause trouble. And I'm not sure how
to deal with -o loop in a sane way, TBH - automagical losetup is bloody
hard to get right. Keep in mind that loop-over-loop is also possible...
Powered by blists - more mailing lists