Re: [Vserver] [PATCH 00/10] Honour per-vfsmount mount options
Sam Vilain wrote:
This patchset allows per-VFS mount options, such as noatime,
nodiratime, and in partitular, read-only.
ie, `mount -o ro --bind` can work with this patch.
This is the invention of Herbert Pötzl.
So, here's what's new;
1. more parts
Even more fine grained :-)
2. longer descriptions
Following the TPP document to the letter, and I hope my descriptive
re-expressions of concept improve chances of acceptance and do not
seem too long.
3. patch 8 is a new piece, though I see now from http://xrl.us/j8dk that
this was not an accidental omission.
Still outstanding changes before next LKML submission;
1. add file_readonly() helper - Christopher Hellwig
http://xrl.us/j8ck
2. audit uses of permission() - Trond Myklebust
(second audit requirement now not relevant)
http://xrl.us/j8ck
a simple
find . \( -name \*.h -o -name \*.c \) -print |
xargs grep 'permission *(' |
grep -w permission | grep NULL
happens to catch all of these. They happen in:
fs/hpfs/namei.c
fs/nfsd/vfs.c (twice)
fs/nfsd/nfsfh.c
fs/namei.c
fs/xattr.c
ipc/mqueue.c
3. split out "am I allowed to write to FS" from permission() -
Christopher Hellwig
http://xrl.us/j8cu
This seems to be similar to what Trond is getting at, that nameidata
is optional to permission, and so therefore it seems like the wrong
place to put it.
This might be seen to apply to all of the changes in part 7 of this
series.
Anyway, I'm putting this one down for a few days so as not to step on
your toes - I hope this helps your efforts, Herbert. If you want to
download them, you can get them from:
http://vserver.utsl.gen.nz/patches/utsl/2.6.16-rc4-BME/
(.tar.gz one level up)
Having said that, it's very easy for me to apply small changes and
regenerate the set, so let me know if you want me to help in this way.
In any case, this effort has been thoroughly enlightening for me as to
how the submission process works, and I hope it will help me as I now
focus my work on features in the main patch.
Sam.
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Invalid Release file, no entry for main/binary-amd64/Packages
On Mon, Feb 27, 2006 at 05:12:23PM +0100, Eugen Leitl wrote: > On Mon, Feb 27, 2006 at 09:50:01AM -0600, Corey Wright wrote: > > > vserver test101 build -m debootstrap --hostname t101.foo.org --context 101 > > --interface hansi=dummy0:192.168.0.101/16 -- -d sarge -m > > http://bach.hpc2n.umu.se/debian-amd64/debian > > > > if that doesn't work, i'd attribute the problem to the util-vserver version > > (as 0.30.209 works for me). > > vserver v16 build --force -n v16 --hostname v16.ativel.com --context 101 > --interface eth0:192.168.0.16/24 -m debootstrap -- -d sarge -m > http://amd64.debian.net/debian-amd64/ > > did work for me, thanks Corey. > > What does --context 101 do, actually? set a proper static context id (101) for that guest all guests must have one, and it should better be unique on a host (range 2-49151 for now) ... HTH, Herbert > > > I'm still not sure whether I should stick with an unsupported AMD64 Sarge > > > or go with a vanilla i386 Sarge (the machine only has 4 GBytes) -- i.e. > > > will it hurt performance badly? 2 GByte/process limit won't bite, will > > > absence of twice as many registers in AMD64 mode? But gcc-3.3/gcc-3.4 > > > doesn't support AMD64 all that well anyway, right? > > > > i don't personally have benchmark numbers (have yet to install a i386 > > guest), but the performance reported by others (due to the extra registers) > > is the entire reason i purchased amd64 hardware, waiting until debian had a > > Subjectively, it is a pretty speedy machine -- even though it's only a 2.0 GHz > single-core Opteron 146. One of my old Athlon machines died in the rack, so > if it's > the motherboard I'm considering fixing it up with an Athlon 64 board. > > > stable/"sarge" amd64 release. you might be able to get a comparable > > speed-up on amd64 with a 32-bit kernel and/or user-land by recompiling all > > packages with a more specific -mtune (ie 32-bit instruction set but > > including scheduling, MMX, SSE, SSE2 support) than debian's i386 packages > > (ie -mtune=i486), but i'll leave that trouble to gentoo users. ;-) > > I am considering recompiling a few packages, once gcc-4.x.x is available > for Sarge. But for time being, I'd be glad just having a stable running > system. > > -- > Eugen* Leitl http://leitl.org";>leitl http://leitl.org > __ > ICBM: 48.07100, 11.36820http://www.ativel.com > 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE > ___ > Vserver mailing list > Vserver@list.linux-vserver.org > http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] /etc/init.d/vservers-default does not work
So that sorts it then :) Guenther Fuchs wrote: Hi there, on Monday, February 27, 2006 at 1:45:57 PM there was posted: YLB> shouldn't your /etc/vservers//apps/init/mark file YLB> only contain "default" ? It should. -- Cordialement, Youri LACAN-BARTLEY PCAM Espace HERVANN 641 Chemin des terriers 06600 ANTIBES Tel: 04.93.33.26.25 Fax: 04.93.33.73.45 ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Invalid Release file, no entry for main/binary-amd64/Packages
On Mon, Feb 27, 2006 at 09:50:01AM -0600, Corey Wright wrote: > vserver test101 build -m debootstrap --hostname t101.foo.org --context 101 > --interface hansi=dummy0:192.168.0.101/16 -- -d sarge -m > http://bach.hpc2n.umu.se/debian-amd64/debian > > if that doesn't work, i'd attribute the problem to the util-vserver version > (as 0.30.209 works for me). vserver v16 build --force -n v16 --hostname v16.ativel.com --context 101 --interface eth0:192.168.0.16/24 -m debootstrap -- -d sarge -m http://amd64.debian.net/debian-amd64/ did work for me, thanks Corey. What does --context 101 do, actually? > > I'm still not sure whether I should stick with an unsupported AMD64 Sarge > > or go with a vanilla i386 Sarge (the machine only has 4 GBytes) -- i.e. > > will it hurt performance badly? 2 GByte/process limit won't bite, will > > absence of twice as many registers in AMD64 mode? But gcc-3.3/gcc-3.4 > > doesn't support AMD64 all that well anyway, right? > > i don't personally have benchmark numbers (have yet to install a i386 > guest), but the performance reported by others (due to the extra registers) > is the entire reason i purchased amd64 hardware, waiting until debian had a Subjectively, it is a pretty speedy machine -- even though it's only a 2.0 GHz single-core Opteron 146. One of my old Athlon machines died in the rack, so if it's the motherboard I'm considering fixing it up with an Athlon 64 board. > stable/"sarge" amd64 release. you might be able to get a comparable > speed-up on amd64 with a 32-bit kernel and/or user-land by recompiling all > packages with a more specific -mtune (ie 32-bit instruction set but > including scheduling, MMX, SSE, SSE2 support) than debian's i386 packages > (ie -mtune=i486), but i'll leave that trouble to gentoo users. ;-) I am considering recompiling a few packages, once gcc-4.x.x is available for Sarge. But for time being, I'd be glad just having a stable running system. -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Invalid Release file, no entry for main/binary-amd64/Packages
On Mon, 27 Feb 2006 12:29:11 +0100 Eugen Leitl <[EMAIL PROTECTED]> wrote: > I've been able to build util-vserver-0.30.210.tar.bz2 as usual > via ./configure etc., by manually resolving missing dependencies until no > more warnings occured during ./configure. i'm using util-vserver 0.30.209 backported from unstable (some weeks ago, so it's probably -1 instead of the newer -2). > However, when trying to build a vserver I'm running into the bug > described at > http://savannah.nongnu.org/bugs/?func=detailitem&item_id=13844 i don't encounter that problem on my amd64 sarge vserver host. > I presume it's an apt sources problem, since > debootstrap --arch amd64 sarge /pure64/ > http://amd64.debian.net/debian-amd64/ completes fine. What should I stick > where to make it work? here's the "vserver build" template that i use: vserver build -m debootstrap --context --hostname --interface =:/24 -- -d sarge -m http://apt-proxy:/debian-sarge-amd64 the backends for that apt-proxy url are (ie "http://apt-proxy:/debian-sarge-amd64"; is the same as...): - http://mirror.espri.arizona.edu/debian-amd64/debian - http://debian.csail.mit.edu/debian-amd64/debian (apt-proxy is worth looking into if you are running/providing/supporting multiple debian hosts, real or virtual. i can provide an example apt-proxy-v2.conf and a sources.list that references the apt-proxy server.) to merge my template with your usage (or rather herbert's example in the bug report): vserver test101 build -m debootstrap --hostname t101.foo.org --context 101 --interface hansi=dummy0:192.168.0.101/16 -- -d sarge -m http://bach.hpc2n.umu.se/debian-amd64/debian if that doesn't work, i'd attribute the problem to the util-vserver version (as 0.30.209 works for me). > I'm still not sure whether I should stick with an unsupported AMD64 Sarge > or go with a vanilla i386 Sarge (the machine only has 4 GBytes) -- i.e. > will it hurt performance badly? 2 GByte/process limit won't bite, will > absence of twice as many registers in AMD64 mode? But gcc-3.3/gcc-3.4 > doesn't support AMD64 all that well anyway, right? i don't personally have benchmark numbers (have yet to install a i386 guest), but the performance reported by others (due to the extra registers) is the entire reason i purchased amd64 hardware, waiting until debian had a stable/"sarge" amd64 release. you might be able to get a comparable speed-up on amd64 with a 32-bit kernel and/or user-land by recompiling all packages with a more specific -mtune (ie 32-bit instruction set but including scheduling, MMX, SSE, SSE2 support) than debian's i386 packages (ie -mtune=i486), but i'll leave that trouble to gentoo users. ;-) corey -- [EMAIL PROTECTED] ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Invalid Release file, no entry for main/binary-amd64/Packages
Eugen Leitl schrieb: However, when trying to build a vserver I'm running into the bug described at http://savannah.nongnu.org/bugs/?func=detailitem&item_id=13844 I presume it's an apt sources problem, since debootstrap --arch amd64 sarge /pure64/ http://amd64.debian.net/debian-amd64/ completes fine. What should I stick where to make it work? I'm using a modified (but undocumented) version of the original script: http://helpdesk.std-service.de/newvserver.txt next setup your /etc/vservers/newvserver-vars to meet your needs: example: 8<--- # Configuration file for newvserver # See man newvserver for the variables that you can set here. # Default VROOTDIR VROOTDIR="/etc/vservers/.defaults/vdirbase" INTERFACE="br0" MIRROR="http://ftp.de.debian.org/debian-amd64/debian"; . . . 8<--- hth Markus ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] /etc/init.d/vservers-default does not work
Hi there, on Monday, February 27, 2006 at 1:45:57 PM there was posted: YLB> shouldn't your /etc/vservers//apps/init/mark file YLB> only contain "default" ? It should. -- regards 'n greez, Guenther Fuchs (aka "muh" and "powerfox") ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] /etc/init.d/vservers-default does not work
hi there, shouldn't your /etc/vservers//apps/init/mark file only contain "default" ? Gerhard Hofmann wrote: Hi all, I have multiple vservers on a Debian box, they all work well when started manually with vserver vservername start I have problems to get them automatically running whenever the host is booted. I have activated vservers-default init script to do the job but this does not work. I have a file /etc/vservers//apps/init/mark with MARK=default for each vserver. TIA Gerhard ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver -- Cordialement, Youri LACAN-BARTLEY PCAM Espace HERVANN 641 Chemin des terriers 06600 ANTIBES Tel: 04.93.33.26.25 Fax: 04.93.33.73.45 ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] /etc/init.d/vservers-default does not work
Hi all, I have multiple vservers on a Debian box, they all work well when started manually with vserver vservername start I have problems to get them automatically running whenever the host is booted. I have activated vservers-default init script to do the job but this does not work. I have a file /etc/vservers//apps/init/mark with MARK=default for each vserver. TIA Gerhard ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Invalid Release file, no entry for main/binary-amd64/Packages
I've been able to install Markus Neubauer's kernel from http://helpdesk.std-service.de/kernel-image-2.6.14-amd64-smp-vs_0.84_amd64.deb (thanks, Markus!) which boots without any problems on the Sun Fire X2100. I've been able to build util-vserver-0.30.210.tar.bz2 as usual via ./configure etc., by manually resolving missing dependencies until no more warnings occured during ./configure. However, when trying to build a vserver I'm running into the bug described at http://savannah.nongnu.org/bugs/?func=detailitem&item_id=13844 I presume it's an apt sources problem, since debootstrap --arch amd64 sarge /pure64/ http://amd64.debian.net/debian-amd64/ completes fine. What should I stick where to make it work? I'm still not sure whether I should stick with an unsupported AMD64 Sarge or go with a vanilla i386 Sarge (the machine only has 4 GBytes) -- i.e. will it hurt performance badly? 2 GByte/process limit won't bite, will absence of twice as many registers in AMD64 mode? But gcc-3.3/gcc-3.4 doesn't support AMD64 all that well anyway, right? -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
