Intereting read
- Thread starter Bozo
- Start date
blakerwry
Storage? I am Storage!
I was always tought that writes were slower than reads. And my own experience confirms this. The writer of the review (2nd link) says that this, infact, is quite the opposite and that reads should be slower than writes....or possibly about equal.
I think he's wrong, what do you guys think?
I think he's wrong, what do you guys think?
Mercutio
Fatwah on Western Digital
Logically, on most hard disks there should be large areas of free space (especially on new, large disks). Drive needs to do a write, it probably has some that's fairly close at hand. The magnetic operation works out to be about the same for a read or a write, that shouldn't be an issue.
In a read, you have to seek to a specific area of a disk, wait for the spindle to move the platters to the proper point, and then start reading. Since seeking is really the big problem in terms of disk performance anyway, I can see how writes might be faster.
That said, I think writes usually take a little longer than reads.
In a read, you have to seek to a specific area of a disk, wait for the spindle to move the platters to the proper point, and then start reading. Since seeking is really the big problem in terms of disk performance anyway, I can see how writes might be faster.
That said, I think writes usually take a little longer than reads.
blakerwry
Storage? I am Storage!
yeah, that's the logic he used... seeking would be faster because it's more likely you'll have an empty block to write to close by than the block you'll want to read from.
I think random writes are about equal or possibly faster than random reads.. But sequential writes always seem to be slower than reads... this has been verified through HDtach and file copies in linux and windows.
I dont know why this would be true unless there is some type of interleave or write verification... simply because the platters are going at the same speed whether reading or writing...
I think random writes are about equal or possibly faster than random reads.. But sequential writes always seem to be slower than reads... this has been verified through HDtach and file copies in linux and windows.
I dont know why this would be true unless there is some type of interleave or write verification... simply because the platters are going at the same speed whether reading or writing...
For a drive to write data, doesn't it have to read, or "understand" where it is safe to write data? I would think writes are slower because the drive must determine a writable area, which in turn will involve seeking to an empty part of the drive.
If that isn't the case, then how does the drive know which areas not to write over?
If that isn't the case, then how does the drive know which areas not to write over?
sechs
Storage? I am Storage!
I always thought that the operating system did that work.
blakerwry
Storage? I am Storage!
i would assume the FAT/MFT keep track of where files are located...
The data area on a HDD may as well all be written to, when a file is deleted the data remains written to disk, just the initial link to the file in the FAT is probably removed.
The data area on a HDD may as well all be written to, when a file is deleted the data remains written to disk, just the initial link to the file in the FAT is probably removed.
sechs
Storage? I am Storage!
Handruin said:
The OS uses the FS to do that.
The file system should keep some information about where files are and aren't. The OS can use that information to tell the disk to what sectors to write.
Tannin
Storage? I am Storage!
Doubtless there are other reasons as well, but writes are slower because the seek takes longer, and the seek takes longer because it has to be more accurate. A seek and read operation only needs to get close enough to the track to have a fair chance of reading the data. If it's a tiny bit off, it doesn't matter so long as the data can still be read. And if the data can't be read, then it's no real problem as the ECC system kicks in and you get a retry: i.e., a small loss of performance but no loss of data.
A write, on the other hand, has to be right first time. The head must be centered exactly as even a small error risks corrupting the data being written, but the data on either side of it as well. Seagate used always to quote different seek times for read and write (back when they used to quote seek times at all, that is - these days they don't quote seek times, they quote numbers which are probably something to do with last week's market close, or possibly someone's phone number).
A write, on the other hand, has to be right first time. The head must be centered exactly as even a small error risks corrupting the data being written, but the data on either side of it as well. Seagate used always to quote different seek times for read and write (back when they used to quote seek times at all, that is - these days they don't quote seek times, they quote numbers which are probably something to do with last week's market close, or possibly someone's phone number).
Buck
Storage? I am Storage!
WD still provide Average Read and Write Seek times, plus Track-to-Track Seeks and Full Stroke Seeks in their Technical Reference Manuals. Although those numbers are not always the most accurate.
blakerwry
Storage? I am Storage!
they;re wrong more often than they are right... what's the point?
freeborn
Learning Storage Performance
Sorry, I haven't been checking the boards lately. I figure it's better late than never though.
Writes are slower than Reads. The main reason is settling time. On reads the drive can afford to try to read when the head has not completely settled. If the ECC engine can't compensate for an off track read, it can be retried on the next revolution. For writes much less aggressive settling criteria are used. The drive needs to make sure the head is where it needs to be and track following well before write gate is allowed. Generally, this makes a write operation take about a half revolution longer than a read operation (assuming the write and read are in the same place and the head's starting location is fixed).
Reads are safe and chances can be taken trying to read when the head is still swaying.
Writes must be dead on so chances are not taken, writes only happen when the head is safely track following on the target track.
Free
Writes are slower than Reads. The main reason is settling time. On reads the drive can afford to try to read when the head has not completely settled. If the ECC engine can't compensate for an off track read, it can be retried on the next revolution. For writes much less aggressive settling criteria are used. The drive needs to make sure the head is where it needs to be and track following well before write gate is allowed. Generally, this makes a write operation take about a half revolution longer than a read operation (assuming the write and read are in the same place and the head's starting location is fixed).
Reads are safe and chances can be taken trying to read when the head is still swaying.
Writes must be dead on so chances are not taken, writes only happen when the head is safely track following on the target track.
Free
Bozo
Storage? I am Storage!
One of these days I'll learn how to spell: uh, proof read: uh, or maybe both......
Bozo :mrgrn:
Bozo :mrgrn:
Several days ago I began to suspect that a certain new forum member ("unregistered") over at SR was Michael Schutte, authour of those articles and webmaster at Lost Circuits. Tonight I'm 99% sure.
[The conspiracy theorest in me also rather suspects that he maybe behind a number of other recently created aliases .... most of which seem to be asking RAID 0 centric questions.]
Is this guy looking for feedback? To see what the reaction from the SR community is to his ongoing HDD series? Researching information from the forum? Patting himself on the head?
Who knows.
Overall, I rather like I number of things he has written on in the past (although he is in desperate need of an editor to rework many of his long, convoluted, run on sentences that frequently appear in his articles). In particular, he has excellent knowledge of RAM (former Ramtron employee) and has also demonstrated on many occasions a very good understanding with CPUs and motherboards.
However, his knowledge of hard drive performance (as shown largely by comments and remarks in various Lost Cirucuit articles over the years) has, until recently, often been characterised by ignorence (i.e. stupid statements like Sandra is the best hdd benchmark etc.). It is abundently clear that, with his new series of hdd articles, he is making a concerted effort to correct that situation. Nonetheless, having currently read through the first two in the series, I note that there are still errors to be found.
I really hope he doesn't make a jack ass of himself on SR, because I respect his knowledge in the other fields of interest. Unfortunately, I feel he very well may, as I percieved him to be almost openly bragging while conversing with Mickey. Me thinks he is behaving like an animal transplanted from its native environment - timidly lurking at first and then, after gaining a little confidence in its new surroundings, the bolder and more brazen behaviour begins. He should be wise to tread carefully, here there be monsters....well not so many at SR anymore, but someones bound to trip him up
I myself, after an open exchange with him today, was really tempted to drag him a bit through the mud. But then there were two factors that stopped me. (1) it would take some time to write up a cognant response that would leave nothing more to be said on the matter. And (2) I gave thought about what Eric recently wrote in the MBF anniversery thread in the SR Pub -> "I am so glad the MBF made me realize what a waste of time the minutia of hard drive measurebating were in my life".
And Eric is right of course. Unless your livelihood is deeply connected to possesing the most minutia knowledge of hard drive performance, then there really is no point of arguing with some idiot on the other side of the internet. Now if only I could convince the academia loving side in me to listen to that very advice....yes, we likes to see their glass houses fall don't we my precious.
[The conspiracy theorest in me also rather suspects that he maybe behind a number of other recently created aliases .... most of which seem to be asking RAID 0 centric questions.]
Is this guy looking for feedback? To see what the reaction from the SR community is to his ongoing HDD series? Researching information from the forum? Patting himself on the head?
Who knows.
Overall, I rather like I number of things he has written on in the past (although he is in desperate need of an editor to rework many of his long, convoluted, run on sentences that frequently appear in his articles). In particular, he has excellent knowledge of RAM (former Ramtron employee) and has also demonstrated on many occasions a very good understanding with CPUs and motherboards.
However, his knowledge of hard drive performance (as shown largely by comments and remarks in various Lost Cirucuit articles over the years) has, until recently, often been characterised by ignorence (i.e. stupid statements like Sandra is the best hdd benchmark etc.). It is abundently clear that, with his new series of hdd articles, he is making a concerted effort to correct that situation. Nonetheless, having currently read through the first two in the series, I note that there are still errors to be found.
I really hope he doesn't make a jack ass of himself on SR, because I respect his knowledge in the other fields of interest. Unfortunately, I feel he very well may, as I percieved him to be almost openly bragging while conversing with Mickey. Me thinks he is behaving like an animal transplanted from its native environment - timidly lurking at first and then, after gaining a little confidence in its new surroundings, the bolder and more brazen behaviour begins. He should be wise to tread carefully, here there be monsters....well not so many at SR anymore, but someones bound to trip him up
I myself, after an open exchange with him today, was really tempted to drag him a bit through the mud. But then there were two factors that stopped me. (1) it would take some time to write up a cognant response that would leave nothing more to be said on the matter. And (2) I gave thought about what Eric recently wrote in the MBF anniversery thread in the SR Pub -> "I am so glad the MBF made me realize what a waste of time the minutia of hard drive measurebating were in my life".
And Eric is right of course. Unless your livelihood is deeply connected to possesing the most minutia knowledge of hard drive performance, then there really is no point of arguing with some idiot on the other side of the internet. Now if only I could convince the academia loving side in me to listen to that very advice....yes, we likes to see their glass houses fall don't we my precious.
Mickey
Learning Storage Performance
Hmm. Is that the likely identity for unregistered? I've been puzzled about his background, based on the content of his posts.
e_dawg
Storage Freak
Tony and free's aggressive vs conservative read/write strategies explain the physically slower write phenomenon, but we should remember that in practice, caching allows writes to be much faster than reads in most I/O situations (UPS suggested for critical data), mitigating the effect of slower physical writes.
time
Storage? I am Storage!
There's also elevator seeking, which is readily applicable to writes but much less so or not at all to reads.
The benefit from clustering blocks in close proximity will also depend in part on how much faster track-to-track times are compared to a full stroke seek.
Don't at least some file systems try to ensure that blocks towards the start will tend to be re-used before blocks at the end? And some work through a list of free blocks so that the least recently used is the first in line.
But in particular, when a block is updated, it is usual to overwrite the original block rather than grab a new one that happens to be convenient. To do otherwise would result in massive fragmentation.
An exception here would be the upcoming ReiserFS 4.0, which uses "dancing trees" and does grab the closest logical block. This deviousness is to support full journaling without crippling write performance. Well worth a read if you visit their website.
The benefit from clustering blocks in close proximity will also depend in part on how much faster track-to-track times are compared to a full stroke seek.
Don't at least some file systems try to ensure that blocks towards the start will tend to be re-used before blocks at the end? And some work through a list of free blocks so that the least recently used is the first in line.
But in particular, when a block is updated, it is usual to overwrite the original block rather than grab a new one that happens to be convenient. To do otherwise would result in massive fragmentation.
An exception here would be the upcoming ReiserFS 4.0, which uses "dancing trees" and does grab the closest logical block. This deviousness is to support full journaling without crippling write performance. Well worth a read if you visit their website.