Mailinglist Archive: opensuse (946 mails)

< Previous Next >
Re: [opensuse] WD Green AV HD: rsync read errors mapping
On 03/09/17 07:47 PM, Carlos E. R. wrote:
An interleave of three meant that after sector #1 came two other
sectors, then (IIRC) sector #2; ie, while the computer processed sector
#1 the disk had time to continue rotating, and it would get to sector #2
just as the cpu was ready for it, after skipping two other sectors.
Setting no interleave would mean that when the cpu was ready for #2, the
disk head would be at #4, thus having to rotate one full turn more
before reaching #1 again. On my computer I think I needed an interleave
of 13. Yes, I tested and timed all numbers from 1 to 13.

Yes, I do recall all this.
It was an emergent property of the high cost of components, in this case of
Now memory is cheap the disk controller reads a whole track at a time.
I think it writes a whole track at a time.
Or maybe a few if the head covers that much.

Now I come to think about it in this manner, it makes me wonder about what
badblocks is actually doing.

If badblocks is clumping 64 4096 bytes blocks at a time, what kind of
granularity are we really working with, what is the real visibility?

If not all tracks have the same capacity, then trying to force this fixed scan
size scan onto the way the disk controller is dealing with buffering is going to
make the efficiency and interaction .... weird.

But lets face it; we're forcing a long standing BUFSIZE of 512 bytes from the
program POV, a result of the archaic dis block size, onto a file system model
that parametrized the disk block size long ago. The Berkeley Fast File System
of the early 1980s used a 4K internal model, so there's nothing new about this
magic number.

Of course when we get to deal with SSDs this all becomes moot.

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting frowned upon?

To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >