Wed, 9 Jun 2010 14:57:56 +0200 2010/6/8 Herbert Poetzl <herbert@13thfloor.at>: > On Tue, Jun 08, 2010 at 03:59:01PM +0200, Tor Rune Skoglund wrote: >> 2010/6/8, Herbert Poetzl <herbert@13thfloor.at>: >> > On Tue, Jun 08, 2010 at 11:04:07AM +0200, Tor Rune Skoglund wrote: >> >> 2010/6/7 Herbert Poetzl <herbert@13thfloor.at>: >> >> > On Mon, Jun 07, 2010 at 12:02:16PM +0200, Tor Rune Skoglund wrote: >> >> >> I've ran into a strange (possibly) inode problem within >> >> >> one vserver. Althought df -i on the host shows that the >> >> >> filesystem on which the vserser lives has IUse of only 1%, >> >> >> we get "cannot create" errors on new files. > >> >> > cannot create is not necessarily an indication to running >> >> > out of inodes ... could you please strace -fF one of those >> >> > and provide the trace via some pastebin? > >> >> >> Having seen that there is a configuration option >> >> >> for the maximum number of inodes dedicated to a vserver, >> >> >> I have the following questions: > >> >> >> - What is the default limit when this option is not set? > >> >> > when the dlimit is unset, the number of inodes is unlimited > >> >> >> - What mechanism is used when checking and enforcing vserver >> >> >> inode limits? > >> >> > the kernel takes care of that > >> >> >> - The total number of inodes on the filesystem on which the >> >> >> vserver lives is 324350 at the moment. >> >> >> Could someone comment if is so high that special actions >> >> >> need to be taken? > >> >> > nope, I have several millions of inode in use, and except >> >> > for a certain memory overhead (for the caches) there is no >> >> > problem to be expected .... > >> >> >> - Could any other limit be causing the error? E.g. number of >> >> >> files limit or whatever? > >> >> > could be, strace will probably shed some light on that > >> >> At the bottom, there an extract of the important parts of >> >> the strace result. > >> > please also provide the 'unimportant parts' :) > >> The whole output added as an attachement now.. :) > > hmm, strange ... the stat on the directory gives > the expected ENOENT, but the mkdir then returns > the same (which means that the directory above > is missing ... but the previous mkdir succeeded) > >> >> We have also done some more testing of the >> >> problem. I would like to add this to describe the setup: > >> >> * We have a vserver as a fileserver, running >> >> samba 3.4.6. The host and fileserver are both >> >> gentoo-based. > >> >> * The client, which in this case is a debian vserver on the >> >> same host, mounts the fileserver share. Unzip/move operations >> >> with large number of files fail as described. > >> >> * Another vserver client, but Gentoo based, on the same host >> >> experiences the same problems. > >> >> * The client, when mounting another share, on another >> >> computer, on which there is no vservers and special stuff, >> >> gets the same problem with that share. I.e., it seems to >> >> be related to the vserver client, and not the fileserver >> >> vserver. > >> >> * However, on another plain host, Debian based (without >> >> vserver patches) the unzip operation works fine with the >> >> fileserver share (!) > >> > so, you are unpacking from a (zip) file on the share >> > to a directory on the same share, as some user? > >> I'm not sure if the unpacked zip file is on the same share, but >> it is at least unpacked to the share. > >> The user has also tried to unpack in locally in the >> debian vserver (which works), and then tried to >> mv it to the share (which fails). > >> As explained above, the strange thing is that the same >> operations work when being done from debian (and ubuntu) >> "physical" linux machines. > >> - Tor Rune > >> >> >> Here are some server facts: >> >> >> * Gentoo vserver kernel, 2.6.32-vs2.3.0.36.28 >> >> >> * util-vserver 0.30.216 pre2883 >> >> >> * Filesystem ext3, default settings when formatting > > 2.6.32 is quite old, could you try with a more > recent kernel and patch? > (e.g. patch-2.6.32.15-vs2.3.0.36.29.4.diff) It's a productions server, so I'll have to wait until the weekend. In portage, there's a vserver-sources kernel with the name vserver-sources-2.3.0.36.30.4-r1 What's your feelings on this one? Or should I download a kernel.org kernel, and do the patching? Best regards, Tor Rune