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."
Actually, they're going to take up eight times as much space... YOU FAIL IT! They will waste 3636b space unused in blocks, however, instead of only 112 bytes, so they'll be wasting over 32 times as much space. But then, won't ReiserFS already store multiple files in a single block in some cases?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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!
In addition, it doesn't matter whether the file is less than 512 or, in this case, 4096 bytes. What matters is if the 'size % block_size' is non-zero. I.e. let's say the file is 4090 bytes. It will fit just fine, and you'll only waste 6 bytes. Now the file is 4100 bytes, only 4 bytes over. Except now you need 2 blocks, and thus waste 4092 bytes.
Sure, on a multi-GB file that's not going to matter too much, as even on a TB drive you can only have a few hundred of those, and who's going to miss that 1MB?
However, there's plenty of other files that hover between 1k and 10k, 10k and 100k, 100k and 1MB where those tiny fractions do add up.
That said, GP is still right. Say you do have a TB drive.. unless you only have a few free MB left, you're not going to worry too much about the losses from block sizes.
Let's suppose you can fix one error per 512 byte block or 6 errors per 4096 byte block. Intuitively that might seem like a step back because 6/8 is smaller than 1, but that is not so. If you have 512-byte blocks and get two errors in a 512-byte sequence then that block is corrupt. However if instead you're using 4096 byte blocks then a 512-byte sequence within that block can have two errors since we can tolerate up to 6 errors in the whole block.
Or put another way, consider a 4 k sequence of data, represented by a sequence of digits dependent on the number of errors in each 512 bytes. 00000000 means no errors, 03010000 means 3 errors in the second block and 1 in the fourth block (ie a total of 4 errors in the whole 4096 bytes). With a scheme that can fix only one error per 512 bytes, the block with 3 errors cannot be corrected (because 3 > 1), but in the system which fixes up to 6 errors per 4096, the errors can be fixed because 4 6. This means that the ECC is far more reliable.
Engineering is the art of compromise.
Using 4MB blocks for everything would kill memory performance - and more specifically, mmap performance. Each library loaded in your system would require at least 4MB of ram - probably more, as they have code, data, and zeroed data segments. Additionally, each process would require another 4MB*n. There's no gain for doing this either, except under specialized circumstances, as the OS can already request a batch of sectors from the drive in one operation.
Block size has absolutely nothing to do with how much redundancy you can build in, and I fail to see the logic in assuming so. Makes absolutely no sense. The 2048 bytes stored on a sector of a CD only refers to your data, and absolutely none of them have anything to do with the CD's error-correction mechanisms. They add lots of extra bits to make up their error-correction, over and above your 2048 bytes of data. But, the point is it doesn't matter how much space you reserve to hold user data, you can arbitrarily reserve any amount of space you want for error-correction bits. You can have 16-byte sectors with 16MB of error-correction. Now, *that* would be a lot of redundancy. But certainly something you could do if you want to, and there's not going to be very many people arguing that those 16-byte sectors weren't covered by much redundancy. I doubt anyone would ever use that much redundancy, obviously, but it's just an outrageous example to show that the amount of redundancy has absolutely nothing to do with how much user data is stored per sector.
So... 2 gigabytes?
FGD 135
Pretty much every paging-capable microprocessor in existence uses 4K memory blocks, thus why they're the natural size for a hard disk.
AMD64/x86-64 uses 8KB pages. ARM uses 1KB pages.
No, x64 and ARM both use 4K pages (though ARM has 1K subpages that you can set permissions on individually). Alpha and sparc64 use 8K pages, though.
Ask Wikipedia
It's in the table "Allocation and layout policies". Look at both tail packing and block suballocation.
There are a few others that do, but not many. (JFS, QFS, NWFS, and VMFS are marked yes; NTFS and ZFS are marked partial.)
Let's say you have 4096 bytes arranged as 8x512-byte blocks and each block can correct one error. Now lets say that we RANDOMLY (ie statisticly independently) introduce, say, 4 errors into that set of 8 blocks. Sometimes the errors will fall so that there are at most one error per block. That is correctable. Sometimes the errors will fall so that there are more than one per block. In that case data will be lost.
However, if we can correct up to, say, 6 arbitrarily placed errors per 4096 bytes we can then have 4 errors anywhere in that block and we won't lose data. It does not matter whether they are spread out or clustered together we can always handle those errors.
This makes for stronger correction.
Engineering is the art of compromise.
The word you're looking for is GPT. It has nothing to do with 4k hardware sectors, but it does support up to 128 partitions. Which ought to be enough for anybody (says the man with a 1 average number of partitions per disk in his household).
High-speed Road Trip (18.000KPH)
Extensible Firmware Interface (EFI) supports GUID Partition Table (GPT)