Re: [vserver] ext4 inode tagging

From: Michael S. Zick <mszick_at_morethan.org>
Date: Mon 16 Jan 2012 - 17:49:34 GMT
Message-Id: <201201161149.36080.mszick@morethan.org>

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.

Mike
> best regards
> Roberto Puzzanghera
>
> > Mike
>
>
>
Received on Mon Jan 16 17:50:01 2012

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