Extremely annoying ext3
Fellow Debs,
I'm sorry this is so long. Specificity before brevity when asking for
help, that's what I always say... Okay, I don't say that a lot.
I have two things to bring to you today (as if I don't post enough of
my silly problems already). The first is why my ext3 drive is so slow,
and the second is what other alternatives I have, if any.
I built a file server machine with the intention of storing all of my
major media and static files in one location for my other machines to
have access to. What better solution than Samba? I installed RedHat
7.3 at first, the distro I was most comfortable with. It worked out
quite well until I wanted to upgrade the kernel or add X11 and the RPM
situation was unacceptable. I decided to switch to Debian.
I mention RedHat because my experience with ext3 in RedHat was much
different than my (as yet small) experience with ext3 in Debian, so
I'm hoping some other folks out there can shed light on this as you
all must have hard drives so someone's gotta know something about it.
I have a couple of old NTFS drives that have data on them that I want
to get onto my brand new 200 gig drive on the file server, so I have a
Windows XP box with the old NTFS drives in it and I'm transferring the
files over the network onto the new ext3 drive in my Debian woody
file server. I know you're all going to tell me that there is fairly
proven NTFS read support in kernel module form, but frankly, I don't
trust it.
So I drag the files on the Windows XP box into a Samba share that sits
on my 200 gig formatted ext3 (formatted ext2, journal written with
tune2fs, and mounted as 'ext3'). I run DU Meter in Windows (nice
little program if you ever have to monitor net traffic in Windows),
and the files copy at 7 or so megs per second for about TWO seconds
before stopping. At this point the file server locks up (no terminal
response, 'top' running inside my SSH session hangs) and the hard
drive light comes on solid for about TEN seconds.
Lather, rinse, repeat.
I read a few articles and posts online about ext3 performance tuning
and I did change some parameters in my /proc/sys/vm/bdflush as
recommended by an article on IBM's website:
http://www-106.ibm.com/developerworks/library/l-fs8
When I tried it again, the bandwidth would top at maybe 4 or 5 megs
per second and only transfer for a moment, break for a moment or two,
and transfer for a moment. Essentially the same level of performance
but now the bursts are much closer together and much less intense. I
never had this problem with RedHat in my recollection, so I wonder
what about the Debian ext3 implementation may be making this happen?
I watched top with a delay of 0.1 seconds and caught kjournald and
keventd at the top of the list MANY of the moments just before the
system hung. I thought JBD might be responsible so I recompiled the
kernel without the debugging support, but that made no difference
whatsoever.
What is this all about?! Is there any way I can fix it? Is it not an
ext3 problem?
And taking a different approach, is ext3 my best bet for simply trying
to maintain data integrity on the drive? I could run ext2 and just
hope the system never goes down, or I could fsck it regularly, but I'm
really looking for something a bit more reliable. I also realize that
ext3 support is, itself, experimental. What else is there that I could
try? I'm not against reformatting the drive, especially since a recent
power failure caused almost half of the thing to be beyond recovery
(fsck ran with -y for about ... Five hours? 100 gig partition.)
I hope someone out there can lend me a hand... You guys/girls have
been fantastic, I'm eager to hear what you have to say.
Thanks!
--
Aaron Bieber
-
Graphic Design // Web Design
http://www.core-dev.com/
aaron@core-dev.com
Reply to: