Overwriting a 4096 byte sector harddisk drive with random data

[Patrick O'Callaghan]

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