Write-Read-Verify performance penalty

  • Thread starter Thread starter Franc Zabkar
  • Start date Start date
F

Franc Zabkar

What kind of performance penalty should one expect for a hard drive
during write operations if its ATA Write-Read-Verify feature set is
enabled?

- Franc Zabkar
 
Franc Zabkar said:
What kind of performance penalty should one expect for a hard drive
during write operations if its ATA Write-Read-Verify feature set is
enabled?
Click to expand...

There is a ATA Write-Read-Verify feature? ;-)

Ok, first, only mode 00h is permanent. The others are for
start-up and then disable themselves. Kind of an extended
self-test.

I expect this will very much depend on the request mix.
Lets see.

For long linear writes, you get two rotations instead of one
per cylinder. But you do not get additional seeks. Assume the
cylinder-to-cylinder seek is 2ms and you can immediately
continue writing (due to sector skew). The you get 2ms for the
seek, 8ms to write the cylinder. The verify adds another 8ms.
hence 10ms -> 18ms, i.e. 80% longer time.

For small writes, you get a complete rotation in addition,
but again no additional seek. If you assume the small write
location had to be long-stroke seeked to, you get an additional
8ms (7200rpm) to a seek time + latency of something like 18ms
(what my Hitachi 250GB SATA drive gives according to HDD Sentinel
for random seeks). That would be 18ms normal and 26ms with verify,
i.e. 70% more with verify. Of course with smaller partitions this
gets a bit worse, as the seek+latency time drops.

But overall something like a not too unintuitive slow-down of
80-100% (i.e. roughle half the speed) seems reasonable.

Quite frankly, for this penalty I am thinking about looking
into enabling this for my fileserver. Anybody know how to
set ATA features under Linux?

Arno
 
There is a ATA Write-Read-Verify feature? ;-)
Click to expand...
Ok, first, only mode 00h is permanent. The others are for
start-up and then disable themselves. Kind of an extended
self-test.

I expect this will very much depend on the request mix.
Lets see.

For long linear writes, you get two rotations instead of one
per cylinder. But you do not get additional seeks. Assume the
cylinder-to-cylinder seek is 2ms and you can immediately
continue writing (due to sector skew). The you get 2ms for the
seek, 8ms to write the cylinder. The verify adds another 8ms.
hence 10ms -> 18ms, i.e. 80% longer time.

For small writes, you get a complete rotation in addition,
but again no additional seek. If you assume the small write
location had to be long-stroke seeked to, you get an additional
8ms (7200rpm) to a seek time + latency of something like 18ms
(what my Hitachi 250GB SATA drive gives according to HDD Sentinel
for random seeks). That would be 18ms normal and 26ms with verify,
i.e. 70% more with verify. Of course with smaller partitions this
gets a bit worse, as the seek+latency time drops.

But overall something like a not too unintuitive slow-down of
80-100% (i.e. roughle half the speed) seems reasonable.

Quite frankly, for this penalty I am thinking about looking
into enabling this for my fileserver. Anybody know how to
set ATA features under Linux?

Arno
Click to expand...

Hdparm (>= 9.0) may be able to do it.

The Device Configuration block can be viewed with ...

hdparm --dco-identify

Smartmontools can show you the contents of the Identify Device block,
eg ...

smartctl -a -r ioctl,2 -d usbjmicron scsi10

- Franc Zabkar
 
For long linear writes, you get two rotations instead of one
per cylinder. But you do not get additional seeks. Assume the
cylinder-to-cylinder seek is 2ms and you can immediately
continue writing (due to sector skew). The you get 2ms for the
seek, 8ms to write the cylinder. The verify adds another 8ms.
hence 10ms -> 18ms, i.e. 80% longer time.
Click to expand...

Let's say that an OS writes a 5MB file to the disc in contiguous
sectors all within the one track. Does the OS write the file as one
continuous stream, or does it break it up into blocks of 1024 sectors,
say?

If it does it in blocks, then wouldn't a 5MB (= 10,000 sectors) file
require 10 rotations, if Write-Read-Verify were active?

- Franc Zabkar
 
Franc Zabkar said:
On 11 Sep 2009 20:26:44 GMT, Arno <[email protected]> put finger to
keyboard and composed:
Click to expand...
Let's say that an OS writes a 5MB file to the disc in contiguous
sectors all within the one track. Does the OS write the file as one
continuous stream, or does it break it up into blocks of 1024 sectors,
say?
Click to expand...
If it does it in blocks, then wouldn't a 5MB (= 10,000 sectors) file
require 10 rotations, if Write-Read-Verify were active?
Click to expand...

Well, a modern OS has a buffer-cache and it will write the whole
file continuously, if a few seconds later. Then there is the drive
limit for transfer size and how smart the firmware acts.

The transfer size is an absolute limit for a verify. Since
a result code has to be given at the end, the verify
has to be done before. This is mainly an issue if the transfer
size is not several times larger than a cylinder.

The firmware of course needs to be smart enough to do a parial
verify before moving to the next cylinder. Otherwise you get
one additional longer seek and double the tiome for track-to-track.

So, how much data does fit into a cylinder? (All calculations
are approximations!)
I am not sure. I dod not find infomation with
WD, Hitachi.
Seagate has a product manual up for the 7200.11 generation
that does not give useful data either, at least not directly.
For the 1.5TB model I can make a guess though:
- One rotation in 8.33ms
- Max internal transfer rate 1709Mb/sec = 213MB/s.
=> Maximum of 1.78MB/cylinder = 3470 sectors/cylinder.

Lets to a plausibility check on this. First, we need the
platter size. From the upper photo at
http://en.wikipedia.org/wiki/Hard_disk_platter
I estimate 3.3" outer, lets say usable area up to 3.2".
That 3.2" = 81mm. This gives a outer track length of
254mm, i.e. 10". Recording density is a maximum of
1462kb/in (182kB/in), which gives us a maximum of
1.82MB for the longest cylinder. Fits.

And how mauch data can be written in one request?
This seems to be codes 39h and CEh (the later has a hard
flush to non-volatile, i.e. disk, before command completion).
They need to be present on any LBA48 device. The maximum
transfer size is 65536 sectors, i.e. 33MB.

This means on a curent 1.5TB drive you can fit something
like 18.5 physical cylinders into one write request.
If the drive verifies before moving to the next cylinder,
you get <10% additional slowdown from misalignment.

Now I would really be interessted in somebody measuring this.
I might have the theory all wrong after all...

Arno
 
Back
Top