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 memory. 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@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org