On 01/16/2012 04:19 PM, Michael S. Zick wrote:
> On Sun January 15 2012, Roberto Puzzanghera wrote:
>>>>>>>>>>>> no, I don't think that will be necessary, but
>>>>>>>>>>>> could you run the following script on your system
>>>>>>>>>>>> and provide upload the output somewhere/
>>>
>>>>>>>>>>>> # mkdir /test
>>>>>>>>>>>> # testfs.sh -vvv -x -F ext4 -M /test -D<device>
>>>
>>>>>>>>>>>> note that<device> should be a partition, disk or
>>>>>>>>>>>> loopback device you do not mind to be reformatted
>>>>>>>>>>>> with ext4 (all data will be destroyed)
>>>
>>>>>>>>>>>> you can simply create one with:
>>>>>>>>>>>> # dd if=/dev/zero of=/path/to/somewhere bs=1M count=1024
>>>>>>>>>>>> # losetup /dev/loop0 /path/to/somewhere
>>>
>>>>>>>>>>>> also, no problem to use /mnt or /media/test instead
>>>>>>>>>>>> of just /test (i.e. it doesn't matter as long as
>>>>>>>>>>>> you specify the path in -M<path>)
>>>
>>>>>>>>>>>> the test script can be found here:
>>>>>>>>>>>> http://vserver.13thfloor.at/Stuff/SCRIPT/testfs.sh
>>>
>>>>>>>>> # dd if=/dev/zero of=/mnt/testfs bs=1M count=1024
>>>>>>>>> # losetup /dev/loop0 /mnt/testfs
>>>>>>>>> # mount -t ext4 /dev/loop0 /mnt/tmp/
>>>>>>>>> # testfs.sh -vvv -x -F ext4 -M /mnt/tmp/ -D /dev/loop0
>>>
>>>>>>>> do not mount any filesystem on /mnt/tmp and do not
>>>>>>>> mount or busy /dev/loop0 in any way, filesystem
>>>>>>>> creation and mounting will be done by testfs.sh
>>>
>>>>>>> The output follows
>>>
>>>>>>> best regards
>>>>>>> Roberto Puzzanghera
>>>
>>>
>>>>>>> # dd if=/dev/zero of=/usr/local/testfs bs=1M count=1024
>>>>>>> # losetup /dev/loop0 /usr/local/testfs
>>>>>>> # ./testfs.sh -vvv -x -F ext4 -M /mnt -D /dev/loop0
>>>>>>> Linux-VServer FS Test [V0.23] Copyright (C) 2005-2009 H.Poetzl
>>>>>>> Linux 3.1.4-vs2.3.2.1-smp x86_64/0.30.216
>>>>>>> VCI: 0002:0308 236 13000f11 (ID24)
>>>>>>> ---
>>>>>>> testing ext4 filesystem ...
>>>>>>> mke2fs 1.41.14 (22-Dec-2010)
>>>>>>> Filesystem label=
>>>>>>> OS type: Linux
>>>>>>> Block size=4096 (log=2)
>>>>>>> Fragment size=4096 (log=2)
>>>>>>> Stride=0 blocks, Stripe width=0 blocks
>>>>>>> 65536 inodes, 262144 blocks
>>>>>>> 13107 blocks (5.00%) reserved for the super user
>>>>>>> First data block=0
>>>>>>> Maximum filesystem blocks=268435456
>>>>>>> 8 block groups
>>>>>>> 32768 blocks per group, 32768 fragments per group
>>>>>>> 8192 inodes per group
>>>>>>> Superblock backups stored on blocks:
>>>>>>> 32768, 98304, 163840, 229376
>>>
>>>>>>> Writing inode tables: done
>>>>>>> Creating journal (8192 blocks): done
>>>>>>> Writing superblocks and filesystem accounting information: done
>>>
>>>>>>> This filesystem will be automatically checked every 24 mounts or
>>>>>>> 180 days, whichever comes first. Use tune2fs -c or -i to override.
>>>>>>> [000]# succeeded.
>>>>>>> mount -t ext4 -o rw /dev/loop0 /mnt 3>&2
>>>>>>> [001]# succeeded.
>>>>>>> mount -o remount,rw,tag /mnt 3>&2
>>>>>>> mount: /mnt not mounted already, or bad option
>>>>>>> [002]# succeeded.
>>>>>>> tag related tests ...
>>>>>>> mount -t ext4 -o rw,tag /dev/loop0 /mnt 3>&2
>>>>>>> [011]# succeeded.
>>>>>>> do_tag_touch /mnt 0 1 255 256 666
>>>>>>> touch /mnt/file_1: 0
>>>>>>> vtag --migrate --tag 0 -- touch /mnt/file_1
>>>>>>> touch /mnt/file_2: 1
>>>>>>> vtag --migrate --tag 1 -- touch /mnt/file_2
>>>>>>> touch /mnt/file_3: 255
>>>>>>> vtag --migrate --tag 255 -- touch /mnt/file_3
>>>>>>> touch /mnt/file_4: 256
>>>>>>> vtag --migrate --tag 256 -- touch /mnt/file_4
>>>>>>> touch /mnt/file_5: 666
>>>>>>> vtag --migrate --tag 666 -- touch /mnt/file_5
>>>>>>> [012]# succeeded.
>>>>>>> do_tag_verify /mnt 0 1 255 256 666
>>>>>>> verify /mnt/file_1: 0 = 0
>>>>>>> verify /mnt/file_2: 1 = 1
>>>>>>> verify /mnt/file_3: 255 = 255
>>>>>>> verify /mnt/file_4: 256 = 256
>>>>>>> verify /mnt/file_5: 666 = 666
>>>>>>> [014]# succeeded.
>>>
>>>>>> this shows that tagging on ext4 works perfectly fine,
>>>>>> please verify (with 'cat /proc/mounts' on the host)
>>>>>> that your filesystem is indeed mounted with the 'tag'
>>>>>> option when you try to do tagging related operations
>>>
>>>>>> note: it was observed that, for yet unknown reasons,
>>>>>> sometimes the 'tag' option isn't used/recognized
>>>>>> despite the fact that it is present in host/guest
>>>>>> fstab ...
>>>
>>>>> I don't what I have missed before, but after rebooting the machine
>>>>> everything works perfectly: tagging, disk limits.
>>>
>>>> Unfortunately, while apparently inode tagging and disk limits
>>>> were working fine, I observed that when I bind mount a host
>>>> directory inside a running guest I lose all read priviledges
>>>> related to *newly* created files (I mean files created *after*
>>>> the inode tagging).
>>>
>>> hmm? not sure what you are trying to tell us here ...
>>
>> I am mounting a host's directory inside the guest as follows inside fstab
>>
>> /vservers/test2/usr/local/shared_dir /shared none bind 0 0
>>
>> When I create a new file inside /vservers/test2/usr/local/shared_dir I
>> don't have the read priviledges inside the guest.
>>
>>
>>>> I solved simply rebooting without the tag mount flag. And the
>>>> shared files, created with the tag flag on, now have strange
>>>> owners:
>>>
>>>> -rw-r--r-- 1 50333648 3892314192 6 Jan 15 16:41 test.html
>>>
>>> which is the expected result with your tagging (ID24)
>>> i.e. the upper uid/gid bits have been used for storing
>>> the xid, for example, 50333648 = 30007D0(hex) which
>>> is 0x03 (xid part) and 0x7D0 (uid part), similar for
>>> the gid ...
>>>
>>> the best way to 'fix' this is to turn tagging back on
>>> and the remove the xid from all affected files. after
>>> that you can turn it off and all uid/gid will be fine
>>
>> Thanks, but I have already solved manually.
>>
>> Anyway, it's not clear to me if is there a chance to have both tags and
>> bind mount working..
>>
>
> I am not one of the developers here, but that question
> seems strange to me.
>
> After a bind mount, that part of the tree is available from
> both its original position and its 'bound' position(s).
>
> And if each context to which it is bound uses (or expects)
> a different xid, uid, and/or gid - how can that be with
> only one field to store them into?
>
> It sounds to me that maybe you want to use ACLs, not tags.
> That way a file could have (at least) one entry that
> 'makes sense' in each context the shared tree is bound into.
Mike, thanks for your hints.
Unfortunately I don't know how to do it. I was following the directives
of the wiki page which concerns only tags.
best regards
Roberto Puzzanghera
> Mike
Received on Mon Jan 16 17:17:48 2012