From: Al Viro <viro@ZenIV.linux.org.uk>
To: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
Cc: Stanislav Brabec <sbrabec@suse.cz>,
linux-kernel@vger.kernel.org, Jens Axboe <axboe@kernel.dk>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>,
David Sterba <dsterba@suse.cz>
Subject: Re: loop subsystem corrupted after mounting multiple btrfs sub-volumes
Date: Fri, 26 Feb 2016 20:30:10 +0000 [thread overview]
Message-ID: <20160226203010.GD17997@ZenIV.linux.org.uk> (raw)
In-Reply-To: <56D0B007.2050106@gmail.com>
On Fri, Feb 26, 2016 at 03:05:27PM -0500, Austin S. Hemmelgarn wrote:
> >Where is /mnt/2?
> It's kind of interesting, but I can't reproduce _any_ of this
> behavior with either ext4 or BTRFS when I manually set up the loop
> devices and point mount(8) at those instead of using -o loop on a
> file. That really seems to indicate that this is caused by something
> mount(8) is doing when it's calling losetup. I'm running a mostly
> unmodified version of 4.4.2 (the only modification that would come
> even remotely close to this is that I changed the default mount
> options for everything from relatime to noatime), and util-linux
> 2.27.1 from Gentoo.
Sigh... sys_mount() (mount_bdev(), actually) has no way to tell if two
loop devices refer to the same underlying object. As far as it's
concerned, you are asking to mount a completely unrelated block device.
Which just happens to see the data (living in separate pagecache, even)
modified behind its back (with some delay) after it gets written to another
device. Filesystem drivers generally don't like when something is screwing
the underlying data, to put it mildly...
When you ask to mount the _same_ device, mount_bdev(), as well as btrfs
counterpart, makes sure that you get a reference to the same struct
super_block, which avoids all coherency problems - all mounted instances
refer to the same in-core objects (dentries, inodes, page cache, etc.).
They get separate struct vfsmount instances, but that only matters for
mountpoint crossing.
As soon as you've set the second /dev/loop alias for the same underlying
file, you are asking for all kinds of trouble. If you use the same one
consistently, you are OK. BTW, even
losetup /dev/loop0 /dev/sda1
mount -t ext2 /dev/sda1 /mnt/1
mount -t ext2 /dev/loop0 /mnt/2
is enough for trouble - you get (as far as ext2 knows) unrelated devices
screwing each other, with no good way to predict that. And you need to
check propagation through more than one layer - loop over loop over block
is also possible.
IMO on-demand losetup a-la -o loop is simply a bad idea...
next prev parent reply other threads:[~2016-02-26 20:30 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <56CF5490.7040102@suse.cz>
2016-02-26 12:33 ` loop subsystem corrupted after mounting multiple btrfs sub-volumes Austin S. Hemmelgarn
2016-02-26 15:50 ` Stanislav Brabec
2016-02-26 16:39 ` Austin S. Hemmelgarn
2016-02-26 17:07 ` Stanislav Brabec
2016-02-26 18:22 ` Austin S. Hemmelgarn
2016-02-26 19:31 ` Stanislav Brabec
2016-02-26 17:53 ` Al Viro
2016-02-26 19:12 ` Stanislav Brabec
2016-02-26 20:05 ` Austin S. Hemmelgarn
2016-02-26 20:30 ` Al Viro [this message]
2016-02-26 20:36 ` Austin S. Hemmelgarn
2016-02-26 21:00 ` Stanislav Brabec
2016-02-26 22:00 ` Valdis.Kletnieks
2016-02-29 14:56 ` Stanislav Brabec
2016-03-01 13:44 ` Ming Lei
2016-04-12 18:38 ` Stanislav Brabec
2016-02-26 20:37 ` Stanislav Brabec
2016-02-26 21:03 ` Al Viro
2016-02-26 21:36 ` Stanislav Brabec
2016-02-26 21:45 ` Al Viro
2016-02-29 13:11 ` Austin S. Hemmelgarn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160226203010.GD17997@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=ahferroin7@gmail.com \
--cc=axboe@kernel.dk \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sbrabec@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).