Re: [vserver] ext4 inode tagging

From: Michael S. Zick <mszick_at_morethan.org>
Date: Mon 16 Jan 2012 - 15:19:22 GMT
Message-Id: <201201160919.24530.mszick@morethan.org>

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
> Thank you, best regards
> Roberto Puzzanghera
>
>
Received on Mon Jan 16 15:19:56 2012

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