>>>>>>>>>> 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