On 08/20/2011 12:53 AM, Stan Hoeppner wrote:
> On 8/19/2011 4:38 PM, Dion Kant wrote:
>
>> I now think I understand the "strange" behaviour for block sizes not an
>> integral multiple of 4096 bytes. (Of course you guys already knew the
>> answer but just didn't want to make it easy for me to find t
On 8/19/2011 4:38 PM, Dion Kant wrote:
> I now think I understand the "strange" behaviour for block sizes not an
> integral multiple of 4096 bytes. (Of course you guys already knew the
> answer but just didn't want to make it easy for me to find the answer.)
>
> The newer disks today have a secto
On 08/14/2011 02:30 PM, Dion Kant wrote:
> On 08/14/2011 01:23 PM, Dion Kant wrote:
>> Forget
>> about the previous results, they will be wrong because of libgcc stream
>> buffering and I did not check how these buffers are actually written to
>> kernel space.
> libgcc uses writev to write out an a
On 08/14/2011 01:23 PM, Dion Kant wrote:
> Forget
> about the previous results, they will be wrong because of libgcc stream
> buffering and I did not check how these buffers are actually written to
> kernel space.
libgcc uses writev to write out an array of buffers to kernel space
User bs Actual
On 8/14/2011 2:14 AM, Dion Kant wrote:
> On 08/13/2011 03:55 PM, Stan Hoeppner wrote:
>> My explanation to you wasn't fully correct. I confused specifying no
>> block size with specifying an insanely large block size. The other post
>> I was referring to dealt with people using a 1GB (or larger)
On 08/14/2011 09:14 AM, Dion Kant wrote:
> The good and problematic block sizes do not really coincide with the
> ones I observe with dd, but the odd behaviour is there.
When testing on Linux kernel 2.6.37.6-0.5-xen, I found that a sync()
call did not give any guarantee that the buffers are actuall
On 08/13/2011 03:55 PM, Stan Hoeppner wrote:
> My explanation to you wasn't fully correct. I confused specifying no
> block size with specifying an insanely large block size. The other post
> I was referring to dealt with people using a 1GB (or larger) block size
> because it made the math easier
On 8/13/2011 9:45 AM, Ivan Shmakov wrote:
>> Stan Hoeppner writes:
>
> […]
>
> > The horrible performance with bs=512 is likely due to the LVM block
> > size being 4096, and forcing block writes that are 1/8th normal size,
> > causing lots of merging. If you divide 120MB/s by 8 you get 1
> Stan Hoeppner writes:
[…]
> The horrible performance with bs=512 is likely due to the LVM block
> size being 4096, and forcing block writes that are 1/8th normal size,
> causing lots of merging. If you divide 120MB/s by 8 you get 15MB/s,
> which IIRC from your original post, is approx
On 8/13/2011 6:53 AM, Dion Kant wrote:
> Stan,
>
> You are right, with bs=4096 the write performance improves
> significantly. From the man page of dd I concluded that not specifying
> bs selects ibs=512 and obs=512. A bs=512 gives indeed similar
> performance as not specifying bs at all.
>
> Wh
On 08/09/2011 07:13 PM, Stan Hoeppner wrote:
> On 8/9/2011 9:12 AM, Dion Kant wrote:
>
>> Thanks for your remarks. The disk info is given below. Writing to the
>> disk is oke when mounted, so I think it is not a hardware/alignment
>> issue. However your remarks made me do some additional investiga
On 8/9/2011 9:12 AM, Dion Kant wrote:
> Thanks for your remarks. The disk info is given below. Writing to the
> disk is oke when mounted, so I think it is not a hardware/alignment
> issue. However your remarks made me do some additional investigations:
>
> 1. dd of=/dev/sdb4 if=/dev/zero gives s
On 08/09/2011 06:30 AM, Stan Hoeppner wrote:
> 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
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 p
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
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 record
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 (
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
18 matches
Mail list logo
