ReiserFS fragmentation = dismal disk IO? No way to defrag without a format?

February 09th, 2007 - 04:34 pm ET by primealert | Report spam
Hi all,

I have a fairly large ReiserFS (3) partition, sitting on top of Linux
software RAID-5. Over time, as the disk filled, write performance has
degraded to the point where if the disk is 95% full you basically
cannot write files to it anymore. Even at 90% full disk writes can
plummet to around 26KB/s (yes, kilobytes, not megabytes). That means
copying a 350MB file takes over 3 hours! Basically, the partition
can't even keep up with the transfer rate of a modem :(

The symptoms are CPU "system" time spikes to 95-99% and all
interactive tasks becomes very slow (normally system time for copying
files is under 5%). You can type into an xterm faster than the system
can keep up and it can take 30 seconds to move the cursor across the
desktop to click on an icon. CTRL-C'ing the file copy operation brings
everything back to life.

Using a fragmentation checker (fragck.pl http://forums.gentoo.org/viewtopic-p-3081971.html)
shows 95% of the files on the partition (350MB->8GB) have 5000 to
10000 fragments... which sounds extremely high. Running the only
defrag util I could find (http://ck.kolivas.org/apps/defrag/
defrag-0.06/) does improve things... but any time that script hits one
of the heavily fragemneted files the copying rate slows to around
25-50KB/s. I can't tell if it's a problem of reading a heavily
fragemented file... or writing the copy back out again (or both)

This is a 2.6.18.6 kernel system, and DMA is enabled with hdparm
(hdparm -Tt shows raw transfer rates of 30-45MB's for the individual
disks)

If anybody has suggestions of how to properly defrag ReiserFS... or
even suggestions on how to track down what the underlying problem
is... it would be very appreciated.

Thanks!

Mike
email Follow the discussionReplies 4 repliesReplies Make a reply

Replies

#1 Dances With Crows
February 12th, 2007 - 11:50 am ET | Report spam
On Mon, 12 Feb 2007 03:54:28 +0100, Robert Heller staggered into the
Black Sun and said:
At 11 Feb 2007 16:00:01 -0800 wrote:
Whoa. Smallest file's 350M? This is not a situation where
ReiserFS is insanely appropriate.


I initially used ReiserFS because of it's capability to resize itself
larger and smaller (can any other filesystem be shrunk yet?).


ext3 can be resized (has to be dismounted).



There are only 2 filesystems in common use that can be shrunk: ReiserFS
and ext3. You have to umount ext3 filesystems to shrink them. Like the
LVM HOWTO says, it's a lot easier to expand filesystems, LVs, VGs, and
PVs than it is to shrink them.

disks are grouped in 2 soft-RAID-5 arrays LVM'd together to look like
one filesystem.





2 PVs, each made out of N disks in softRAID-5? Interesting.

It's been through 2 capacity upgrades already by using Reiser to
shrink the filesystem small enough to fit on one array... LVM then
migrates all used blocks onto that single array while the other is
taken offline and replaced with larger disks. Then LVM reimports that
second upgraded array back into itself and Reiser is told to expand
to use the new free space.





I think this approach would work OK with ext3, provided you can umount
the LVs. If you can't do that, you'll be forced to add the new disks,
pvcreate them, vgextend the VG onto the new PVs, lvextend, then resize
the FS. Then pvmove the old PV out. I think that might work. I don't
know for sure though, as I currently only have 1 PV on my desktop.

The files are still online and "live" most of the time this is going
on, it's a pretty slick system that seems to work well. But perhaps
growing/shrinking ReiserFS over time with the fragmentation made
things worse.





This is possible. I don't know for sure; I have a lot less data at home
and most everything at ork is on hard-RAID.

I'd still like to avoid taking everything offline to replace it with
ext3/XFS (and I'd like to keep the current method of adding
capacity), so for now I'm going to move some of the oldest files
offline to get about 20-30% free space





This is probably a very good plan for getting reasonable performance
back. HTH,

One suspects that with one side demanding DRM and the other side
demanding it not get in the way of enjoying the purchase, friable DRM is
the technical solution that makes everyone happy. --AdB, in ASR
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see

Similar topics