Subject: Re: [vserver] vservers and inodes
From: Herbert Poetzl <herbert@13thfloor.at>
Date: Tue, 8 Jun 2010 15:49:43 +0200

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