Bug 28883 - It costs about a week to add 20000 users on fresh beta2
Summary: It costs about a week to add 20000 users on fresh beta2
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.1
Hardware: i386
OS: Linux
high
high
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact: Aaron Brown
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-02-22 17:23 UTC by Bill Huang
Modified: 2005-10-31 22:00 UTC (History)
2 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2003-06-03 01:51:00 UTC


Attachments (Terms of Use)

Description Bill Huang 2001-02-22 17:23:59 UTC
Here is  a report from Fujitsu,they used a script to add 60000 users on
fresh Florence beta2.While the users were added,system 
started to become slow down,as a result,it cost about one week to add 20000
new users.

Fujitsu also tried to add 60000 users on TurboLinux Advanced server 6,which
uses kernel2.2.18,this was not occured.
Though the bug was also occured on Kondara 2000,which uses kernel2.2.16.

I had asked Fujitsu to test on Fisher and Wolverine to confirm the bug.

Test machine:
Chipset:i810
CPU:Celeron 700
Memory:128MB

Here is the script file Fujitsu used.

=====useradd60000.sh=====
#! /bin/csh
set num = 65500

while ($num > 5500)
          useradd -m -u "$num" "user$num"
     @       num--
end
=========================

There is another case,when 8000 new users were added,there were ext2 error
message occured on console.
After fsck was used to repair the file system,new users can be added.

Here is the error message.

======Error message on console==========
           EXT2-fs error (device ide0(3,1)): ext2_readdir: bad entry in
directory #197199:
           rec_len is smaller than minimal - offset=0, inode=0, rec_len=0,
name_len=0
           EXT2-fs error (device ide0(3,1)): ext2_readdir: bad entry in
directory #770436:
           rec_len is smaller than minimal - offset=0, inode=0, rec_len=0,
name_len=0
           EXT2-fs error (device ide0(3,1)): ext2_readdir: bad entry in
directory #541282:
           rec_len is smaller than minimal - offset=0, inode=0, rec_len=0,
name_len=0
           EXT2-fs error (device ide0(3,1)): ext2_readdir: bad entry in
directory #115336:
           directory entry across blocks - offset=0, inode=1507458121,
rec_len=35836, name_
           len=53
           EXT2-fs error (device ide0(3,1)): ext2_readdir: bad entry in
directory #1328354:
           rec_len is smaller than minimal - offset=0, inode=0, rec_len=0,
name_len=0

===========================================

Comment 1 Michael K. Johnson 2001-02-22 19:09:06 UTC
Bob, could you try to reproduce this?

Comment 2 Michael K. Johnson 2001-02-22 21:22:02 UTC
To clarify, it is the ext2 errors I want to reproduce

ext2 doesnt handle 20,000 entries in one directory (/home) very well,
which probably significantly contributes to the slowdown.

For that many accounts, it is best to have multiple directories on the
way to a users's home directory.  There are many schemes for that.
You could put the user's home directory in /home/$(($num%100))/ in
this contrived instance; often parts of user names are used instead.
(Future filesystems for Linux will be better able to handle this,
but from a practical standpoint it is often better to have multiple
disks allocated to home directories anyway.)

Comment 3 Bob Matthews 2001-02-23 16:22:10 UTC
I was able to add about 10,000 users with the current kernel
(2.4.1-0.1.14enterprise) before filling up /home.  No indication of disk
corruption.

Comment 4 Bob Matthews 2001-02-25 20:33:59 UTC
However, we are now seeing EXT2 errors under heavy load memory contention.  See
kernel testing homepage.

Comment 5 Pete Zaitcev 2002-10-09 00:13:56 UTC
The bug wasn't handled for a while. Is there an interest still?
Care to reproduce on 8.0?

Mind, the 10,000 files in a directory is going to be VERY slow,
but there should be no corruption.


Comment 6 Pete Zaitcev 2003-06-03 01:51:00 UTC
Seems like the issue got stale. Oh well...



Note You need to log in before you can comment on or make changes to this bug.