On Sun, Jan 15, 2012 at 09:44:44PM +0100, Roberto Puzzanghera wrote:
> On 01/15/2012 12:29 AM, Roberto Puzzanghera wrote:
>> On 01/14/2012 11:14 AM, Herbert Poetzl wrote:
>>> On Sat, Jan 14, 2012 at 09:47:19AM +0100, Roberto Puzzanghera wrote:
>>>> On 01/14/2012 12:48 AM, Herbert Poetzl wrote:
>>>>> On Fri, Jan 13, 2012 at 07:26:13PM +0100, Roberto Puzzanghera wrote:
>>>>>> On 01/13/2012 06:02 PM, Herbert Poetzl wrote:
>>>>>>> On Fri, Jan 13, 2012 at 05:10:46PM +0100, 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 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
HTC,
Herbert
> Of course I'm always available for further tests :)
> best regards
> Roberto Puzzanghera
Received on Sun Jan 15 21:34:45 2012