Bug 121485 - (VM)filesystem access slow, bad inode cache management?
(VM)filesystem access slow, bad inode cache management?
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-04-21 22:48 EDT by Alexandre Oliva
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version: 2.6.5-1.349
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-05-05 13:53:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2004-04-21 22:48:51 EDT
The problem I've had on 5 different boxes was slow filesystem I/O.

stracing rsync showed lstat64 system calls issued by rsync processes
would take forever to complete (quite often 5-10 seconds); then a
burst of progress was made and then it came to a halt again.  Hard
disk leds confirmed this access pattern, except for one of the boxes
that had two disks in RAID 1 resyncing, whose disk access was
constant.  Very odd.

It might have to do with the system running out of real memory, still
with plenty of mostly-unused swap.  In all cases, there was
competition for disk access between rsync (sometimes more than one)
and either prelink or updatedb.  In at least one case, after updatedb
completed rsync became very fast.

Version-Release number of selected component (if applicable):
kernel-2.6.5-1.332
Comment 1 Ralf Ertzinger 2004-04-24 08:50:01 EDT
I noticed this, too, today.
updatedb ran in bursts, stopping in a lstat64() call for several
seconds. vmstat showed almost the entire processor time spent in
iowait. iostat showed no IO access to the disks (apart from some
smallish writes/reads now and then). The system was very sluggish
during that time, programs requiring disk access (even small ones like
"sudo kill <foo>") required several seconds.

After killing updatedb, everything went back to normal.

kernel is kernel-2.6.5-1.339.i686 on an AMD Duron
Comment 2 Arjan van de Ven 2004-05-03 06:09:26 EDT
This should be fixed in the 349 kernel on
http://people.redhat.com/arjanv/2.6/
Comment 3 Alexandre Oliva 2004-05-05 13:53:12 EDT
Confirmed, thanks.

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