Scary OOPS when playing with --bind, --move, and friends

Scary OOPS when playing with --bind, --move, and friends

[C Anthony Risinger]

hello,

i really need to stop recklessly doing this stuff to my laptop... i'm
finishing a new initramfs hook to support many features of btrfs; when
considering how i was going to mount the target subvol as / for the
booting system, i decided to play with --bind and --move.

in short, everything works fine until you --bind across a subvol via
the "special" folders created when one takes a snapshot, or --bind the
special folder itself.  the --bind succeeds, and everything initially
appears to work fine...

this is nearly the exact process i did; should reproduce :-(i'm scared
to do it again...):

-----------------------------------------------------
# mkdir -p sand/root sand/bind
# cd sand
# mount -o subvolid=0 /dev/sda root
# mount --bind root/<subvol of my current root>/home/anthony bind
# touch bind/TEST

<you can now see TEST at ~/TEST and bind/TEST>

# vim bind/TEST
  did it work?
:wq

<you can see the edited version ONLY in the one you edited... the
other is still 0 bytes>

# vim ~/anthony/TEST
1 wtf, why not?
:wq

<machine panics, X is instantly replaced by an oopsie screen; machine locked>
-----------------------------------------------------

i don't know why i decided to stupidly edit the bad version, even
though something was clearly wrong.  at any rate, this was about 15
minutes ago... the machine booted back up alright after a hard reboot,
hooray for that, but methinks there is probably some corruptions in
there now... meh.

i don't know what it means, but when the two versions desynced (it
could have been like this, but i didn't notice until after the
desync), `ls -l` reported a `0` right after the permissions:

....
-rw-r--r-- 0 anthony users 8 Dec 20 21:41 TEST
....

all other files report `1`.  since /dev and /proc etc. have different
numbers, this appears to have something to do with the mount or
device?

i panicked wen the kernel did, and i forgot to write down the message,
but the trace had `vfs_rename` and `tomoyo_???`... sorry for the bad
memory.  vim was attempting to move a temporary file over the top of
the misbehaving file, hence the rename.

i'm on 2.6.36.2

the `directory as a subvol` thing seems to be a little finicky :-) did
i do something incorrect?  should this kind of operation be supported?
 it seems to work fine so long as i stay on the same subvol.

thanks,

C Anthony

Re: Scary OOPS when playing with --bind, --move, and friends

[Fajar A. Nugraha]

On Tue, Dec 21, 2010 at 10:51 AM, C Anthony Risinger <anthony@extof.me> wrote:
> in short, everything works fine until you --bind across a subvol via
> the "special" folders created when one takes a snapshot,

> # mount --bind root/<subvol of my current root>/home/anthony bind
> # touch bind/TEST
>
> <you can now see TEST at ~/TEST and bind/TEST>

bind/ is a mounted snapshot, right? if yes, then when you "touch
bind/TEST", it should also appear in root/<subvol of my current
root>/home/anthony/TEST, and NOT in root/home/anthony/TEST or
/home/anthony/TEST

> i'm on 2.6.36.2

Try 2.6.35 or later. I tested something similar under ubuntu maverick
(2.6.35-24-generic) and it works just fine.

-- 
Fajar

Re: Scary OOPS when playing with --bind, --move, and friends

[cwillu]

On Mon, Dec 20, 2010 at 10:16 PM, Fajar A. Nugraha <list@fajar.net> wrote:
> On Tue, Dec 21, 2010 at 10:51 AM, C Anthony Risinger <anthony@extof.me> wrote:
>> in short, everything works fine until you --bind across a subvol via
>> the "special" folders created when one takes a snapshot,
>
>> # mount --bind root/<subvol of my current root>/home/anthony bind
>> # touch bind/TEST
>>
>> <you can now see TEST at ~/TEST and bind/TEST>
>
> bind/ is a mounted snapshot, right? if yes, then when you "touch
> bind/TEST", it should also appear in root/<subvol of my current
> root>/home/anthony/TEST, and NOT in root/home/anthony/TEST or
> /home/anthony/TEST
>
>> i'm on 2.6.36.2
>
> Try 2.6.35 or later. I tested something similar under ubuntu maverick
> (2.6.35-24-generic) and it works just fine.

Last I checked, 2.6.36 came after 2.6.35.  :)

Re: Scary OOPS when playing with --bind, --move, and friends

[Fajar A. Nugraha]

On Tue, Dec 21, 2010 at 11:16 AM, Fajar A. Nugraha <list@fajar.net> wrote:
> On Tue, Dec 21, 2010 at 10:51 AM, C Anthony Risinger <anthony@extof.me> wrote:
>> i'm on 2.6.36.2
>
> Try 2.6.35 or later. I tested something similar under ubuntu maverick
> (2.6.35-24-generic) and it works just fine.

Sorry, hit "send" to soon. I though you wrote "2.6.32" :P

Still curious about your test scenario though. Can you double check
it? A write on the snapshot should not appear on the parent
filesystem.

-- 
Fajar

Re: Scary OOPS when playing with --bind, --move, and friends

[C Anthony Risinger]

On Mon, Dec 20, 2010 at 10:19 PM, Fajar A. Nugraha <list@fajar.net> wrote:
> On Tue, Dec 21, 2010 at 11:16 AM, Fajar A. Nugraha <list@fajar.net> wrote:
>> On Tue, Dec 21, 2010 at 10:51 AM, C Anthony Risinger <anthony@extof.me> wrote:
>>> i'm on 2.6.36.2
>>
>> Try 2.6.35 or later. I tested something similar under ubuntu maverick
>> (2.6.35-24-generic) and it works just fine.
>
> Sorry, hit "send" to soon. I though you wrote "2.6.32" :P
>
> Still curious about your test scenario though. Can you double check
> it? A write on the snapshot should not appear on the parent
> filesystem.

sorry maybe i wasn't very clear; my current root is a subvol... the
directory i was --bind mounting corresponded to /home/anthony:

/

and

root/<subvol of my current root>

are the same; so it should show up in my /home/anthony directory.  if
mount the subvol by id, then --bind mount, it works as expected; only
when crossing the magic barrier doesn't things seem to freak out.

i actually reproduced it twice, but this time i didn't write to the files :-)

C Anthony

Re: Scary OOPS when playing with --bind, --move, and friends

[C Anthony Risinger]

On Mon, Dec 20, 2010 at 10:25 PM, C Anthony Risinger <anthony@extof.me>=
 wrote:
> On Mon, Dec 20, 2010 at 10:19 PM, Fajar A. Nugraha <list@fajar.net> w=
rote:
>>
>> Still curious about your test scenario though. Can you double check
>> it? A write on the snapshot should not appear on the parent
>> filesystem.
>
> sorry maybe i wasn't very clear; my current root is a subvol... the
> directory i was --bind mounting corresponded to /home/anthony:
>
> /
>
> and
>
> root/<subvol of my current root>
>
> are the same; so it should show up in my /home/anthony directory. =A0=
if
> mount the subvol by id, then --bind mount, it works as expected; only
> when crossing the magic barrier doesn't things seem to freak out.

s/doesn't/do/g

to be exact, it looks like this:

-----------------------------------------
(subvolid)
        <source>
        <mount>
        [options]

(262)
        /dev/sda
        /

(__0)
        /dev/sda
        /home/anthony/sand/root
        [subvolid=3D0]

(???)
        /home/anthony/sand/root/vols/262/home/anthony
        /home/anthony/sand/bind
        [--bind]
-----------------------------------------

all my subvolumes are kept in a "vols" directory in the btrfs root, so
my / and the --bind mount were suppose to be referencing the same
location.  additionally, TEST showed up in both locations... it was
the editing part that blew up.  NOTE however, that the subvol (id 262)
itself was _never_ actually mounted, it was accessed thru the btrfs
root mounted at `root`.  i think this is the crux of the problem;
--bind doesn't seem to know that the directory it was binding isn't
100% "within" the mount point it resides under.

C Anthony
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html