On Tue, Jun 08, 2010 at 11:04:07AM +0200, Tor Rune Skoglund wrote: > Thanks Herbert, I really appreciate your support. > It reminds me that there is time to support the > project financially. > I really hope we can fix this, and make the "management" > happy - as they seem to be starting pulling rank to get debian > and vmware instead. > 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' :) > 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? TIA, Herbert > >> 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 > Best regards, > Tor Rune Skoglund