[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [linux-lvm] LVM incredible slow with Kernel 2.6.11

On Thu, Jun 29, 2006 at 06:15:23PM +0200, Dieter St?ken wrote:
> Cristian Livadaru wrote:
> > me again ... isn't there anybody that could give ANY hint on what's
> > wrong?
> > 
> > I did some test with dd and the result is terrible!
> > 
> > LVM
> > explendidos:/shared# dd if=/dev/zero of=test1.dd bs=64 count=1000
> > 1000+0 records in
> > 1000+0 records out
> > 64000 bytes transferred in 20.019969 seconds (3197 bytes/sec)
> seems the data gets written synchronously without any buffering.
> Thus each write is delayed until the data is really written to
> disk. For a 5400 RPM disk you get 90 transactions per seconds.
> This gives about 10 seconds for 1000 chunks. "bs=64" means
> 64 bytes! so each sector will be written multiple times.
> So may be the system even reads in each sector again each time
> before writing it, thus it takes two turns which gives 20 seconds.
> Unfortunately I can't tell why this happens :-(
> May be "direct IO" takes place (like for oflags=direct),

where could I check this? 

> or this is some configuration option of LVM, i don't know about.
> Try using "hdparm" to see, if DMA etc. is enabled. Have a look

no matter how it's set, the result is always the same.
I could'nt find any usefull information in any logfiles, I enabled LVM
verbose mode and debug output but still nothing was found.

> into /var/log/messages or use "dmesg" for nay hardware problems.
> I recently discovered the "blockdev" command. Do you use any special
I have read in some posts on the mailinglist about blockdev but not
quite sure on how I could use it to solve my problem.

> ext3 feature? You may try "tune2fs -o journal_data_writeback".
> If you don't have relevant data on the LV, you may try to write
> to the LV device directly. Is it slow for read, too? try "hdparm -t"

hdparm -t /dev/share/sharevg

 Timing buffered disk reads:  146 MB in  3.01 seconds =  48.50 MB/sec
 HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
 ioctl for device

I tried tune2fs but it didn't get any better.
I also dont understand why with kernel 2.4 I get about 5mb/s instead of
the 350kb/s 
not that 5mb would be great but still, much better then 350kb/s

Maybee I should mention that this is some "want-to-be" raid controler
that was on the mainboard.

0000:00:0e.0 RAID bus controller: Triones Technologies, Inc. HPT374 (rev


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]