On Feb 26, 2016 at 21:30 Al Viro wrote:
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 s
On Mon, Feb 29, 2016 at 10:56 PM, Stanislav Brabec wrote:
> On Feb 26, 2016 at 23:00 valdis.kletni...@vt.edu wrote:
>>
>> On Fri, 26 Feb 2016 22:00:44 +0100, Stanislav Brabec said:
>>
>>> Well, it seems to be safe, even if the loop device was not allocated by
>>> mount(8) itself, as
>>> ioctl(fd,
On Feb 26, 2016 at 23:00 valdis.kletni...@vt.edu wrote:
On Fri, 26 Feb 2016 22:00:44 +0100, Stanislav Brabec said:
Well, it seems to be safe, even if the loop device was not allocated by
mount(8) itself, as
ioctl(fd, LOOP_CLR_FD)
never returns EBUSY:
The fact you don't get an EBUSY doesn't me
On 2016-02-26 16:45, Al Viro wrote:
On Fri, Feb 26, 2016 at 10:36:50PM +0100, Stanislav Brabec wrote:
It should definitely report error whenever trying -oloop on top of
anything else than a file. Or at least a warning.
Well, even losetup should report a warning.
Keep in mind that with crypto
On Fri, 26 Feb 2016 22:00:44 +0100, Stanislav Brabec said:
> Well, it seems to be safe, even if the loop device was not allocated by
> mount(8) itself, as
> ioctl(fd, LOOP_CLR_FD)
> never returns EBUSY:
The fact you don't get an EBUSY doesn't mean it's actually safe
pgpySWEpuLcwi.pgp
Descr
On Fri, Feb 26, 2016 at 10:36:50PM +0100, Stanislav Brabec wrote:
> It should definitely report error whenever trying -oloop on top of
> anything else than a file. Or at least a warning.
>
> Well, even losetup should report a warning.
Keep in mind that with crypto in the game it just might be us
On Feb 26, 2016 at 22:03 Al Viro wrote:
And I'm not sure how
to deal with -o loop in a sane way, TBH - automagical losetup is bloody
hard to get right.
See another reply in this thread for the idea:
Fri, 26 Feb 2016 22:00:44 +0100
Keep in mind that loop-over-loop is also possible...
Indeed!
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 "
On Feb 26, 2016 at 21:30 Al Viro wrote:
IMO on-demand losetup a-la -o loop is simply a bad idea...
So the correct behavior of -o loop should:
Check, whether another mount command already did losetup.
If not, allocate new loop device.
If yes, reuse existing loop device.
Well, it seems to be
On Feb 26, 2016 at 21:05 Austin S. Hemmelgarn wrote:
> 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 t
On 2016-02-26 15:30, Al Viro wrote:
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
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.
On 2016-02-26 14:12, Stanislav Brabec wrote:
Al Viro wrote:
On Fri, Feb 26, 2016 at 11:39:11AM -0500, Austin S. Hemmelgarn wrote:
That's just it though, from what I can tell based on what I've seen
and what you said above, mount(8) isn't doing things correctly in
this case. If we were to do t
On Feb 26, 2016 at 19:22 Austin S. Hemmelgarn wrote:
The first commit is just test cases, and the others are specific issues
that only affected BTRFS which have nothing to do with this thread at
all other than involving mount(8) and BTRFS.
Yes, it is a bit off topic. It just demonstrates, how c
Al Viro wrote:
> On Fri, Feb 26, 2016 at 11:39:11AM -0500, Austin S. Hemmelgarn wrote:
>
>> That's just it though, from what I can tell based on what I've seen
>> and what you said above, mount(8) isn't doing things correctly in
>> this case. If we were to do this with something like XFS or ext4,
On 2016-02-26 12:07, Stanislav Brabec wrote:
Austin S. Hemmelgarn wrote:
> On 2016-02-26 10:50, Stanislav Brabec wrote:
That's just it though, from what I can tell based on what I've seen and
what you said above, mount(8) isn't doing things correctly in this case.
If we were to do this with s
On Fri, Feb 26, 2016 at 11:39:11AM -0500, Austin S. Hemmelgarn wrote:
> That's just it though, from what I can tell based on what I've seen
> and what you said above, mount(8) isn't doing things correctly in
> this case. If we were to do this with something like XFS or ext4,
> the filesystem woul
Austin S. Hemmelgarn wrote:
> On 2016-02-26 10:50, Stanislav Brabec wrote:
That's just it though, from what I can tell based on what I've seen and
what you said above, mount(8) isn't doing things correctly in this case.
If we were to do this with something like XFS or ext4, the filesystem
would
On 2016-02-26 10:50, Stanislav Brabec wrote:
Austin S. Hemmelgarn wrote:
> Added linux-btrfs as this should be documented there as a known issue
> until it gets fixed (although I have no idea which side is the issue).
This is a very bad behavior, as it makes impossible to safely use btrfs
loop
Austin S. Hemmelgarn wrote:
> Added linux-btrfs as this should be documented there as a known issue
> until it gets fixed (although I have no idea which side is the issue).
This is a very bad behavior, as it makes impossible to safely use btrfs
loop bind mounts in fstab. (Well, it is possible to
Added linux-btrfs as this should be documented there as a known issue
until it gets fixed (although I have no idea which side is the issue).
On 2016-02-25 14:22, Stanislav Brabec wrote:
While writing a test suite for util-linux[1], I experienced a a strange
behavior of loop device:
When two loo
21 matches
Mail list logo
