Ext3 users - Oct 2001 - inode limit ?

Hello,
  I'm using a defualt everything install of 7.2 (kernel 2.4.7-10 #1) 
with a 27 gig ext3 / partition.  The problem that I am experiencing is 
this:  If I create more than (about) 3.5 million distinct files on the 
partition, touch, mkdir, cp and all other file creation methods complain 
that there is no available space on the disk.  A df shows me that the 
partition is only 65% full.  If I delete one of the files, I am able to 
grow one new file that actually fills the several gigs of available 
disk, but if I try to create two files I get the same behavior (no 
available space).

  I tried this on an install that used ext2 but was in all other ways 
exactly the same, and received the same behavior, which leads me to 
believe it's a kernel limitation, not a problem with the filesystem.

  In the 2.2 kernel there was a way to adjust the max-inodes at runtime 
by adjusting the values in /proc/sys/fs/max-inodes file, but I don't see 
this file with the 2.4.7-10 kernel that shipped with 7.2 (and I can't 
create it, even as root).  Is there a way to adjust these values at 
runtime, or do I need to recompile or upgrade the kernel?

  I apologize if this isn't the correct place for this question, I 
didn't see a place to post that was more suitable.

Thanks,
  Douglas

Douglas Brunton wrote:
> 27 gig ext3 / partition.  The problem that I am experiencing
> is this:  If I create more than (about) 3.5 million distinct
> files on the partition, touch, mkdir, cp and all other file
> creation methods complain that there is no available space on
> the disk.
Let's see here, 27GB w/1 node per 8KB (default) = 3.5M inodes.

Sounds like normal operation to me.  ;-PPP
> A df shows me that the partition is only 65% full.
What does "df -i" give you?  That lists inodes free.  I have run
into cases where /var was only 37% full, but 100% inodes were used.
> I tried this on an install that used ext2 but was in all
> other ways exactly the same, and received the same behavior,
> which leads me to believe it's a kernel limitation, not a
> problem with the filesystem.
Or, again, normal operation.
> In the 2.2 kernel there was a way to adjust the max-inodes
> at runtime by adjusting the values in /proc/sys/fs/max-inodes
> file, but I don't see this file with the 2.4.7-10 kernel that
> shipped with 7.2 (and I can't create it, even as root).
I was under the impression that on Ext2 (and Ext3), inodes were
pre-allocated?  And you must specify additional inodes as
mkfs-time???

I assume any /proc/sys/fs/max-inodes value may be the maximum number
the kernel could handle over all filesystems period???
> Is there a way to adjust these values at runtime, or do I
> need to recompile or upgrade the kernel?
I think your filesystem needs to be reformatted with additional
inodes.  Unless, of course, newer Ext2/Ext3 versions can re-allocate
them?  [ Note, I'm just another user and don't understand much about
the underlying filesystems ]

-- TheBS

-- 
Bryan "TheBS" Smith    mailto:b.j.smith@ieee.org   chat:thebs413
Engineer  AbsoluteValue Systems, Inc.  http://www.linux-wlan.org
President     SmithConcepts, Inc.   http://www.SmithConcepts.com
----------------------------------------------------------------
Web site defacements are as much of a national security risk as
inner city kids spray painting.  There is nothing of value, and
nothing that can't be fixed with a little re-paint.  You'd have
to have the equivalent stupidity of someone parking an F-18 in
downtown LA.  Even then, the only damage would be a new scheme!
The US government wants life imprisonment for such "terrorism."

Hi,

On Thu, Oct 25, 2001 at 12:49:37PM -0400, Bryan-TheBS-Smith wrote:
> I was under the impression that on Ext2 (and Ext3), inodes were
> pre-allocated?  And you must specify additional inodes as
> mkfs-time???
Correct.
> I assume any /proc/sys/fs/max-inodes value may be the maximum number
> the kernel could handle over all filesystems period???
/proc/sys/fs/max-inodes limits the number of active inodes open in the
kernel at once, not the number on disk.

Cheers,
 Stephen