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