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."
> NOTHING is 512 bytes anymore.
Shortcuts can easily be 512 bytes long.
For example I've got a shortcut to a file on C:\, which is 391 bytes actual size, 4096 bytes on the disk.
I don't have access to the actual standard, but would guess that they're really claiming more reliability for the same storage capacity, not more reliable in absolute terms.
They can take what would have been per-block overhead with smaller sector sizes and reuse that data space for more robust error correcting codes, while maintaining the same capacity.
But, good question, since in terms of absolute reliability I can't picture anything in the current spec which would prevent private (not visible at the interface level) methods from being used (RAID within a drive?) with current drives.
"National Security is the chief cause of national insecurity." - Celine's First Law
Did the space for the bootloader just increase to 4096 as well? For those unaware, the BIOS loads just the first sector of the disk into memory, the bootloader takes it from there. It would certainly let them get a lot more resilient, now they only barf if things are not as expected.
Live today, because you never know what tomorrow brings
With some probably minor inconvenience, you could fix that by using a Zipped archive. And someone will likely come up with a low-impact solution based on that.
The parent raises a point though: now that we have bigger sectors, are we finally getting a standard for partition tables with more than 4 entries without using logical partitions?
It's about effing time!
512 bytes was good for floppy disks. I think we should have started upping the sector size around the same time as we hit the 528mb 1024-cylinder limit back in the early 90's. Considering that a modern hard drive has anywhere from one-half to two billion sectors, and that's some serious overhead for no reason. Error-correction is "easier" if it's spread over larger blocks. Why ? Because most files are quite large, and corrupting a 512 byte chunk is just as bad as corrupting a 4096 or 8192 byte chunk, because it's hosing the file either way. Might as well pool the ECC together and offer better protection for the large block, while still wasting less bits than the sum of all the small sectors' ECC. Even without the proposed ECC algorithm overhaul, larger blocks would allow more usable data per platter.
The downside is that we've had 512 byte sectors for so long, everyone's hardcoded the number in their apps and drivers. The biggest risk involved is to patch all that software... one little glitch could hose a ton of data.
-Billco, Fnarg.com
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
What's so hard about that?
Go read the Linux Kernel mailing list, and you'll find interactions between the block layer and the virtual memory are one of the most difficult things to make work right in an operating system. The size of the block on the hard disk matters most to the driver, its mostly transparent to the rest of the operating system. The only thing it changes on actual file systems is the minimum filesystem block should be 4K minimum.
If it's already transparent, then what is the big deal? If what you say is true, they could make blocks/sectors as long as they want and we won't need to know (except the driver writers need to know what constraints exist in the interface to send the read and write commands to the drive).
Sorry to bust YOUR bubble, but I do know how the OS works, and how it's interface works. The issue depends on what blocksize the commands between driver and hardware require. If you cannot instruct the hardware at a finer resolution than 512 bytes at a time, then writing 256 bytes really does mean that the OS at some layer (maybe in the driver, maybe at a higher layer, depending on the OS) will read 512 bytes, update 256 of them, and write 512 back. If that interface is being changed to require 4096 bytes minimum per I/O operation, then it really does increase the needed transfer work going on between the driver and hardware.
My post was meant in part to be humorous, and in part to raise an issue. The issue is the transparency of the driver to hardware interface. I do know from random encounterings that for IDE it really does require the driver do I/O operations in multiples of 512. That really does affect the 256 byte I/O request from userspace, but it's not really a serious request due to the caching nature of modern operating systems. And there is no reason in the world why they cannot have been doing 4096 byte or longer blocks for years or decades. If they have been doing it, there's no news (but that's typical Slashdot, so how would we know). Given the I/O command interface is in units of 512 bytes, it's probably convenience that whatever long block size the drive uses be an exact whole multiple of 512 bytes, even that is not essential. A couple decades ago I wrote a "driver" for a mainframe OS that handled I/O requests in units of 4096 bytes, with an on-disk blocksize of 18432 bytes. If you do your arithmetic, you can see that is 4.5x. So some I/O request blocks end up spanning physical blocks on disk. No big deal.
Now I have not been following PC hardware technology very much, so I don't know how much has been added to the I/O interface capability. If they have added a new byte-level I/O command set, then fine. Do you even know if they have?
now we need to go OSS in diesel cars