* MBR partitions slow?
@ 2016-08-30 9:32 Ulrich Windl
2016-08-31 15:32 ` Mark D Rustad
0 siblings, 1 reply; 3+ messages in thread
From: Ulrich Windl @ 2016-08-30 9:32 UTC (permalink / raw)
To: linux-kernel; +Cc: Ulrich Windl
Hello!
(I'm not subscribed to this list, but I'm hoping to get a reply anyway)
While testing some SAN storage system, I needed a utility to erase disks quickly. I wrote my own one that mmap()s the block device, memset()s the area, then msync()s the changes, and finally close()s the file descriptor.
On one disk I had a primary MBR partition spanning the whole disk, like this (output from some of my obscure tools):
disk /dev/disk/by-id/dm-name-FirstTest-32 has 20971520 blocks of size 512 (10737418240 bytes)
partition 1 (1-20971520)
Total Sectors = 20971519
When wiping, I started (for no good reason) to wipe partition 1, then I wiped the whole disk. The disk is 4-way multipathed to a 8Gb FC-SAN, and the disk system is all-SSD (32x2TB). Using kernel 3.0.101-80-default of SLES11 SP4.
For the test I had reduced the amount of RAM via "mem=4G". The machine's RAM bandwidth is about 9GB/s.
To my surprise I found out that the partition eats significant performance (not quite 50%, but a lot):
### Partition
h10:~ # ./flashzap -f -s /dev/disk/by-id/dm-name-FirstTest-32_part1
time to open /dev/disk/by-id/dm-name-FirstTest-32_part1: 0.000042s
time for fstat(): 0.000017s
time to map /dev/disk/by-id/dm-name-FirstTest-32_part1 (size 10.7Gib) at 0x7fbc86739000: 0.000039s
time to zap 10.7Gib: 52.474054s (204.62 MiB/s)
time to sync 10.7Gib: 4.148350s (2588.36 MiB/s)
time to unmap 10.7Gib at 0x7fbc86739000: 0.052170s
time to close /dev/disk/by-id/dm-name-FirstTest-32_part1: 0.770630s
### Whole disk
h10:~ # ./flashzap -f -s /dev/disk/by-id/dm-name-FirstTest-32
time to open /dev/disk/by-id/dm-name-FirstTest-32: 0.000022s
time for fstat(): 0.000061s
time to map /dev/disk/by-id/dm-name-FirstTest-32 (size 10.7Gib) at 0x7fa2434cc000: 0.000037s
time to zap 10.7Gib: 24.580162s (436.83 MiB/s)
time to sync 10.7Gib: 1.097502s (9783.51 MiB/s)
time to unmap 10.7Gib at 0x7fa2434cc000: 0.052385s
time to close /dev/disk/by-id/dm-name-FirstTest-32: 0.290470s
Reproducible:
h10:~ # ./flashzap -f -s /dev/disk/by-id/dm-name-FirstTest-32
time to open /dev/disk/by-id/dm-name-FirstTest-32: 0.000039s
time for fstat(): 0.000065s
time to map /dev/disk/by-id/dm-name-FirstTest-32 (size 10.7Gib) at 0x7f1cc17ab000: 0.000037s
time to zap 10.7Gib: 24.624000s (436.06 MiB/s)
time to sync 10.7Gib: 1.199741s (8949.79 MiB/s)
time to unmap 10.7Gib at 0x7f1cc17ab000: 0.069956s
time to close /dev/disk/by-id/dm-name-FirstTest-32: 0.327232s
So without partition the throughput is about twice as high! Why?
Regards
Ulrich
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: MBR partitions slow?
2016-08-30 9:32 MBR partitions slow? Ulrich Windl
@ 2016-08-31 15:32 ` Mark D Rustad
2016-09-01 6:30 ` Antw: " Ulrich Windl
0 siblings, 1 reply; 3+ messages in thread
From: Mark D Rustad @ 2016-08-31 15:32 UTC (permalink / raw)
To: Ulrich Windl; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 350 bytes --]
Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> wrote:
> So without partition the throughput is about twice as high! Why?
My first thought is that by starting at block 0 the accesses were aligned
with the flash block size of the device. By starting at a partition, the
accesses probably were not so aligned.
--
Mark Rustad, MRustad@gmail.com
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 841 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Antw: Re: MBR partitions slow?
2016-08-31 15:32 ` Mark D Rustad
@ 2016-09-01 6:30 ` Ulrich Windl
0 siblings, 0 replies; 3+ messages in thread
From: Ulrich Windl @ 2016-09-01 6:30 UTC (permalink / raw)
To: mrustad; +Cc: linux-kernel
>>> Mark D Rustad <mrustad@gmail.com> schrieb am 31.08.2016 um 17:32 in Nachricht
<E2D72371-913B-4460-A370-C141835AD919@gmail.com>:
> Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> wrote:
>
>> So without partition the throughput is about twice as high! Why?
>
> My first thought is that by starting at block 0 the accesses were aligned
> with the flash block size of the device. By starting at a partition, the
> accesses probably were not so aligned.
Hi!
Thanks for answering. Yes, you are right: Usually I use fdisk to create partitions, and the tool does proper aligning for the partitions. In my case YaST insisted on having a partition before creating a filesystem, so I created on within YaST, and that partition turned out to be badly aligned (I think Yast uses cfdisk internally). I'm sorry that I didn't think about that earlier!
Stracing fdisk, I also learned about ioctl(BLKIOOPT) and related...
Regards,
Ulrich
>
> --
> Mark Rustad, MRustad@gmail.com
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-09-01 6:30 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-30 9:32 MBR partitions slow? Ulrich Windl
2016-08-31 15:32 ` Mark D Rustad
2016-09-01 6:30 ` Antw: " Ulrich Windl
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.