Re: Overwriting a 4096 byte sector harddisk drive with random data

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

 



On Thu, 2011-07-21 at 15:34 +0300, Gilboa Davara wrote:
> 
> > Sorry, could you please elaborate a bit more on how a higher size
> > block results in better performance.
> > 
> > -- 
> > Kind regards,
> > Yudi
> > 
> 
> Ouch, of the top my head, there two major reasons:
> 1. (Mechanical) disk drives (AKA Hard drives) dislike random read/writes
> as their require the drive to constantly "move" the head to a different
> strip.
> 2. File systems tend to like big blocks as its easier for them to
> allocate adjacent blocks, reducing file fragmentation which in turns
> increases the number of seeks (see 1).

Neither of these points is relevant in the case posited by the OP. She's
writing directly to the drive, not to some file. There is no question of
random versus sequential and there's no filesystem block allocation
going on.

The actual reason for using larger block sizes is that it gives the
driver a chance to minimize the number user-to-kernel data copies. It
may also reduce kernel-to-device DMA operations, depending on whether
the dd sync options are used. Making the bs value an integer multiple of
the the physical block size of the device is probably a good idea in
most circumstances.

> However, using uber-large-blocks (such as 1M) may actually decrease the
> performance due to the synchronous nature of dd itself. 
> 
> Here's a short demo:
> (Taken from a 5 x 500GB software RAID5; ext4 partition over LVM)
> Notice that the best performance is reached when using 64KB blocks.

Writes to an ext4 filesystem inside an LVM volume inside a RAID 5 array
tell you virtually nothing about raw write performance to a single
drive. There are too many factors to consider, one of which is the CPU
cost of calculating block parity and another is the fact that at least
two physical disk writes are taking place for every logical one, and
possibly more if inode and indirect blocks are also being updated.

poc

-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux