From: Andreas Dilger <adilger@clusterfs.com>
To: jmerkey@comcast.net
Cc: linux-kernel@vger.kernel.org
Subject: Re: Ext3 File System "Too many files" with snort
Date: Thu, 8 Jul 2004 12:21:43 -0600 [thread overview]
Message-ID: <20040708182143.GD23346@schnapps.adilger.int> (raw)
In-Reply-To: <070820041751.25643.40ED899E0006C76E0000642B2200748184970A059D0A0306@comcast.net>
[-- Attachment #1: Type: text/plain, Size: 1598 bytes --]
On Jul 08, 2004 17:51 +0000, jmerkey@comcast.net wrote:
> On a Linux 2.4.21 system running snort with a very large organization
> (30,000 +) workstations I am seeing a "too many files" mesage from ext3
> which results in snort dying and rolling our of memory. Is there a way
> to specifiy a larger number of inode entries dynamically when creating
> an Ext3 file system which gets around this limitation. In theory, a file
> system should not create a limitation on how many files it can contain,
> but I understand that inode base FS's have this limitation.
Do you create a subdirectory for every user? If yes, then there
is a limit of 32000 subdirectories in a single directory for Linux.
It is possible to bump this up to 65000 or so (include/linux/ext3_fs.h
EXT3_LINK_MAX), but not more, because of i_nlink size limits. If you have
so many entries in a single directory I'd also suggest the htree patches
to ext3 (I can send you patches if you want) to improve performance,
but they are not strictly required.
If you are actually running out of inodes, then you can use "-i" or "-N"
to mke2fs to increase the number of inodes in a new filesystem. Since
this defaults to 1 inode per 8kB of space, it seems unlikely that you
would run out of inodes before blocks unless you have lots of small files
(maildir perhaps? even then "modern" emails usually average > 8kB in size
because of HTML crap, lots of headers, attachments, etc).
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2004-07-08 18:21 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-08 17:51 Ext3 File System "Too many files" with snort jmerkey
2004-07-08 18:21 ` Andreas Dilger [this message]
2004-07-11 14:55 ` Michelle Konzack
2004-07-11 17:16 ` Andreas Dilger
-- strict thread matches above, loose matches on Subject: below --
2004-07-09 16:36 jmerkey
2004-07-09 17:04 ` Dave Jones
2004-07-09 18:30 jmerkey
2004-07-09 18:30 jmerkey
2004-07-09 18:44 ` Hans Reiser
2004-07-09 22:26 ` Andreas Dilger
2004-07-09 18:51 jmerkey
2004-07-09 19:01 jmerkey
2004-07-09 19:08 ` Pete Harlan
2004-07-14 3:37 ` Ben Hoskings
2004-07-09 19:20 jmerkey
2004-07-10 5:07 ` Hans Reiser
2004-07-10 8:33 ` Dave Jones
2004-07-10 17:37 ` Hans Reiser
2004-07-10 17:44 ` Christoph Hellwig
2004-07-10 17:57 ` Hans Reiser
2004-07-10 18:54 ` Christoph Hellwig
2004-07-10 19:23 ` Hans Reiser
2004-07-12 10:20 ` Paolo Ciarrocchi
2004-07-12 12:11 ` Jesper Juhl
2004-07-12 23:05 ` Bernd Eckenfels
2004-07-18 7:22 ` Hans Reiser
2004-07-10 19:11 ` Francois Romieu
2004-07-09 23:11 jmerkey
2004-07-10 6:00 jmerkey
2004-07-10 8:38 ` Dave Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040708182143.GD23346@schnapps.adilger.int \
--to=adilger@clusterfs.com \
--cc=jmerkey@comcast.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox