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.. :)
>> 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