>>>>>>>>>> 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..
Thank you, best regards
Roberto Puzzanghera
Received on Sun Jan 15 22:04:13 2012