I have an enterprise redhat (reh4) server that was configured a few years ago. I really don't know what else to describe, yet, that might be pertinent, but i continually see an error in the "messages" log:

----
Apr 15 07:10:57 ns01 kernel: EXT3-fs warning (device hda3): ext3_dx_add_entry: Directory index full!
Apr 15 07:10:57 ns01 kernel:
Apr 15 07:10:57 ns01 kernel: EXT3-fs warning (device hda3): ext3_dx_add_entry: Directory index full!
----

I have searched and searched for anything related to this, and have found almost nothing that might describe the severity or cause of the error... or how to fix it.

Does anyone have any ideas?

Thanks, in advance!

Look in man tune2fs for possibilities. Perhaps changing the directory indexing might help.

Do you have any idea which directory is exceeding its maximum size? If so, you might consider creating sub-directories in that directory and moving blocks of files into those sub-directories to create a logical organization of the files. (You might also discover files that can -- and maybe should -- be deleted.) I note from the error message that the directory is located in the third partition of your first drive, so the "problem child" is in that partition. Your /etc/fstab will tell you where that partition is mounted in your file system.

A final option is to convert the file system of that partition to ext4 or zfs or some other file system that has higher limits.

My suggestion would be to clean and rationalize the directory structure on sda3 as the first step, and, if that can't be done, try the tune2fs -O dir_index to see if that helps. As a last resort, convert to a new file system. (I'd also suggest a full backup of the partition before doing anything else.)

that is the best answer that i have seen so far, it gives me direction and much to "look into"... I take it that this has entirely to do with too many files and the directory structure for the volume is full... i will hunt for an excess of files (probably meaningless) and then i will update you.
thanks, for the wisdom.

seen this one?

http://linux.derkeiler.com/Mailing-L.../msg08251.html

awesome... thanks!

ok, still need help...

I have determined that it is qmail that is indirectly the cause... when qmail is turned off, (after a few minutes) the errors to the "messages" log cease.

so, i have moved the /var/qmail directory onto a separate hard drive's partition (and mounted it under "/var/qmail/").

I did the same for "/var/spool", so it is now on a different hard drive, just mounted under "/var/spool".

i am still getting errors "kernel: EXT3-fs warning (device hda3): ext3_dx_add_entry: Directory index full!"

Now, I am contemplating moving "/home/vpopmail/" to another partition.

I am deleting as much of the old stuff as possible.

QUESTIONS:
--how do i locate or trace the actual log entries back to the action and therefore the directory?
--is there any utility that will tell me where the inodes are lacking, or where the highest concentration of files are located?
--would moving the "directory in question" to another partition solve the problem? that is, if i identified the correct problem directory?
--what else should i be doing short of reinstalling the file system?

thanks in advance for your replies... much appreciated!

John

you could try

find / -type d | ( while read A; do B=`ls -l "$A" | wc -l`; if [ "$B" -gt 999 ] ; then echo $B $A; fi ; done)

or

find / -type d | ( while read A; do B=`ls -l "$A" | wc -l`; echo $B $A; done) | sort -n

shows inode usage

ok, and the answer is...

for those who would like some insight...

the journal was corrupt... the answer was simply to remove the journal using tune2fs, and then reapply the journal... the "directory full" error went away, and the kjournal process was not so prominent.

i still have major issues with spam causing my email server to hang up, but at least the machine is not burned with that constant journaling error.

thanks for the help,

John

did you try fscking it, before removing the journal?

yes, at least twice... did not fix a thing. besides, doing the fs check takes a LONG time on larger drives compared to deleting and creating the journal. I also think the risk is low (unless you happen to crash in the few minutes that you dont have the journal in place)... and you don't need to be in single user mode to do this... this can be done on the fly (although i admit i did reboot the server as a matter of a final check).

:-)