On Mon, Dec 20, 2010 at 10:25 PM, C Anthony Risinger <anthony@xxxxxxxx> wrote:
> On Mon, Dec 20, 2010 at 10:19 PM, Fajar A. Nugraha <list@xxxxxxxxx> wrote:
>>
>> 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.
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=0]
(???)
/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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
