Slashdot Mirror
Long Block Data Standard Finalized
An anonymous reader writes "IDEMA has finally released the LBD (Long Block Data) standard. This standard, in work since 2000, increases the length of the data blocks of each sector from 512 bytes to 4,096 bytes. This is an update that has been requested for some time by the hard-drive industry and the development of new drives will start immediately. The new standard offers many advantages — improved reliability and higher transfer rates are the two most obvious. While some manufacturers say the reliability may increase as much as tenfold, the degree of performance improvement to be expected is a bit more elusive. Overall improvements include shorter time to format and more efficient data transfers due to smaller overhead per block during read and write operations."
Yeah why 4092 bytes? Why not 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 bytes? It seems to me to be the best option
Operating systems tend to use 4096-byte blocks already, as that's the size of a memory page on x86 and amd64. If you were to require 16kb transfers, then the block cache would have to start allocating contiguous four-page groups for DMA transfers and the like, which could be difficult if memory is fragmented; in comparison, pages are the basic allocation unit for RAM, so 4kb's easy to find.
The longer block sizes add reliability because the error correcting codes have more to work with at a time (more data bits, but also more ECC bits).
As for wasted space, that's under the filesystem's control, not the drive's.
Your god may be dead, but mine aren't!
yeah, sure. Give a logical AND knowledgable answer.
Way to ruin the curve.
The Kruger Dunning explains most post on
I can speak with some authority on this - I work for one of those aforementioned hard-drive manufacturers, and have been doing a small amount of work on this exact thing.
The easy answer is this: in order to do ECC-like data checking on a larger set of data (say, a group of eight 512-byte sectors), it means that if you want to write sector three of that eight, you end up having to re-read the whole thing before you do anything else - thus basically giving you 4,096-byte "sector" anyway.
The other half of that answer is this: do you know what the "real" storage capacity of a CD is, without all the error checking? It's a bit less than double. Even most of the enterprise folks wouldn't accept a 40% hit in data density in return for what works out to not that big an increase in reliability (data redundancy doesn't buy you that much unless that data is on different spindles). They'd just rather get the whole data space and do a RAID, especially since that's what they're going to do anyway.
Sig broken, watch for