Re: [vserver] ext4 inode tagging

From: Roberto Puzzanghera <admin_at_sagredo.eu>
Date: Mon 16 Jan 2012 - 18:08:30 GMT
Message-ID: <4F14679E.3060505@sagredo.eu>

On 01/16/2012 06:49 PM, Michael S. Zick wrote:
> On Mon January 16 2012, Roberto Puzzanghera wrote:
>> 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.
>>
>
> It was just a random thought, and may not be workable.
> I have just been checking the man pages and it is not clear
> to me if they 'mask out' the xid part of the field when
> they are tested.
>
> You might still have to run the shared (by 'bind') file tree(s)
> without any xid tags.
>
> Given the shared tree is bound into three vserver contexts:
> vs1, vs2, vs3
> Given that all user and group IDS are unique among all
> of the vserver contexts:
> Mike (1000) only defined in vs1 context
> Jane (2000) only defined in vs2 context
> Bert (666) only defined in vs3 context
>
> Then:
> It should be possible to grant (on the original instance)
> r/w/x permissions for each UID/GID - which by our usage
> above implies "by context" since the UID/GID is unique
> among (across) all of the contexts.
>
> Or, at least that was the thought that came to mind,
> I don't have a clue if this will handle your use case.
>

First of all, I have 'bind mount' working fine if I switch off the inode
tag.

My case is simpler. I have to share the users' web space (vs1 context)
to the apache vserver (vs2 context). So the shared tree is owned by
userID:apacheID and the apacheID=80 is common between vs1 and vs2; so
there's non need to grant 777 permissions.

best regards
Roberto Puzzanghera

> Mike
Received on Mon Jan 16 18:10:22 2012

[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Mon 16 Jan 2012 - 18:10:22 GMT by hypermail 2.1.8