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

Re: LVM write performance



On 8/8/2011 11:03 PM, Stan Hoeppner wrote:
> On 8/8/2011 2:00 PM, Dion Kant wrote:
>> On 08/08/2011 03:33 PM, Stan Hoeppner wrote:
>>> On 8/8/2011 1:25 AM, Dion Kant wrote:
>>>> Dear list,
>>>>
>>>> When writing to a logical volume (/dev/sys/test) directly through the
>>>> device, I obtain a slow performance:
>>>>
>>>> root@dom0-2:/dev/mapper# dd  of=/dev/sys/test if=/dev/zero
>>>> 4580305+0 records in
>>>> 4580305+0 records out
>>>> 2345116160 bytes (2.3 GB) copied, 119.327 s, 19.7 MB/s
>>>>
>>>> Making a file system on top of the LV, mounting it and write into a file
>>>> is ok:
>>>>
>>>> root@dom0-2:/dev/mapper# mkfs.xfs /dev/sys/test
>>>> root@dom0-2:/mnt# mount /dev/sys/test /mnt/lv
>>>> root@dom0-2:/mnt# dd  of=/mnt/lv/out if=/dev/zero
>>>> 2647510+0 records in
>>>> 2647510+0 records out
>>>> 1355525120 bytes (1.4 GB) copied, 11.3235 s, 120 MB/s
>>>>
>>>> Furthermore, by accident I noticed that writing directly to the block
>>>> device is oke when the LV is mounted (of course destroying the file
>>>> system on it):
>>>>
>>>> root@dom0-2:/mnt# dd  of=/dev/sys/test if=/dev/zero
>>>> 3703375+0 records in
>>>> 3703374+0 records out
>>>> 1896127488 bytes (1.9 GB) copied, 15.4927 s, 122 MB/s
>>>>
>>>> Does anyone know what is going on?
>>>>
>>>> The configuration is as follows:
>>> Yes.  You lack knowledge of the Linux storage stack and of the dd
>>> utility.  Your system is fine.  You are simply running an improper test,
>>> and interpreting the results from that test incorrectly.
>>>
>>> Google for more information on the "slow" results you are seeing.
>>>
>> Hmm, Interpreting your answer, this behaviour is what you expect.
>> However,  I think it is a bit strange to find, with this "improper
>> test", about a factor 10 difference between reading from and writing to
>> a logical volume by using dd directly on the device file. Note that  dd
>> if=/dev/sys/test of=/dev/null does give disk i/o limited results.
> 
> Apparently you are Google challenged as well.  Here:
> http://lmgtfy.com/?q=lvm+block+size
> 
> 5th hit:
> http://blog.famzah.net/2010/02/05/dd-sequential-write-performance-tests-on-a-raw-block-device-may-be-incorrect/
> 
>> What is the proper way to copy a (large) raw disk image onto a logical
>> volume?
> 
> See above, and do additional research into dd and "block size".  It also
> wouldn't hurt for you to actually read and understand the dd man page.
> 
>> Thanks for your advise to try Google. I already found a couple of posts
>> from people describing this similar issue, but no proper explanation yet.
> 
> I already knew the answer, so maybe my search criteria is what allowed
> me to "find" the answer for you in 20 seconds or less.  I hate spoon
> feeding people, as spoon feeding is antithetical to learning and
> remembering.  Hopefully you'll learn something from this thread, and
> remember it. :)

BTW, you didn't mentioned what disk drive is in use in this test.  Is it
an Advanced Format drive?  If so, and your partitions are unaligned,
this in combination with no dd block size being specified will cause
your 10x drop in your dd "test".  The wrong block size alone shouldn't
yield a 10x drop, more like 3-4x.  Please state the model# of the disk
drive, and the partition table using:

/# hdparm -I /dev/sdX
/# fdisk -l /dev/sdX

Lemme guess, this is one of those POS cheap WD Green drives, isn't it?
Just in case, read this too:

http://wdc.custhelp.com/app/answers/detail/a_id/5655/~/how-to-install-a-wd-advanced-format-drive-on-a-non-windows-operating-system

This document applies to *all* Advanced Format drives, not strictly
those sold by Western Digital.

-- 
Stan



Reply to: