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."

Comments

Higher Reliability?

[MankyD]

How does larger block sizes result in better reliability? Intuitively, I would almost think the opposite, since a single byte corruption means a much larger block is now erroneous. I obviously am missing something though.

Re:Higher Reliability?

[silas_moeckel]

I would think it has to do with the ability to have more bits for ecc type functions. Blocks would need to be terminated somehow so there is a fixed overhead per block. Reducing this overhead by a factor of 8 would leave more room for a larger parity type field and the more bits in there the larger failure that it can detect, fix and relocate. This would all assume they will not use the new space to push up sizing. Course this is all my rather speculative guesswork.

Re:Higher Reliability?

[GooberToo]

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.

In the real world this translates into, "more reliability". Reliability has always been relative to dollars spent. This means given the same dollars you are more reliabile. This means, given absolute dollars, you are more reliable.

Why 4096?

[MBCook]

Is there a good reason why 4096 was chosen? Is that just an artifact of this being designed in 2000? At this point very few files on the average system would be smaller than this. It seems to me they could have quite safely chosen something like 16k which would have improved things more, future proofed them more, yet still have been small enough as to not waste a tremendous amount of space (like if they chose 512k).

Why not make it variable, in that each drive can have it's own value (limited to a power of 2, between 512 and say 512k)? That way one drives today could be 4k, with drives in a few years being more without requiring another 7 years for a new standard?

Re:Why 4096?

[42forty-two42]

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.

Re:Why 4096?

[AKAImBatman]

Parent is correct. Pretty much every paging-capable microprocessor in existence uses 4K memory blocks, thus why they're the natural size for a hard disk. In the x86 world, the next step up is 4MB blocks. Burst performance of modern hard disks is quite good, but I have to wonder if 4MB blocks would be helpful or harmful to overall system performance? It might reduce the number of pages, that's for sure.

Discussed Since 2000?

[hardburn]

I'm going to give them a benefit of a doubt and consider that there may be good technical reasons I don't know about that explains why a standards body can't slap something together in a few weeks that says "block sizes are now 4096 bytes instead of 512". There must be. Otherwise, I think we have a new benchmark for bureaucratic inefficiency.

Re:Discussed Since 2000?

[RingDev]

Saying 4096 was probably the easy part. Of course someone probably had to research what the largest (time efficient) and smallest (space efficient) block size would give the greatest advantage in space/time for current average files. But eventually you get into the issue of working with Hard Drive manufacturers who likely have to redesign some circuits and controls _from scratch_, BIOS developers who have to recode to detect and support two different standards, and OS/Driver developers who also have to deal with any low level changes...

You're talking about interacting with likely hundreds of companies trying to come up with a single standard that 1) they can all agree on and 2) won't make any of them lose money. Good luck.

-Rick

Re:Sounds like a good idea to me.

[Dan Ost]

If that kind of lossage bothers you, use a file system that can pack multiple file tails into the same block (reiserfs for sure, ext4 will too, I think). If you've got lots of small files, the impact can be surprising (my portage tree shrunk by about 100MB just by moving it from ext3 to reiserfs!). I've never noticed a difference anywhere else, however.