4

The terminology BLOCK confused me as I am doing some research about disk technology these days.


My Former Understanding

I understand BLOCK generally means a batch of data seen as a whole I/O unit, as described in the wiki page: Block. What I thought a logical block, or a filesystem block refers to is the minimal I/O unit seen as a whole used by specific filesystem, in order to, as the essence of any batch operation, reduce the overheads brought by reading or writing one sector one time. And a physical block is exactly the synonym of a disk sector. This article from Oracle confirmed my understanding.

What's more, I believe the word CLUSTER is just filesystem block in Microsoft's fashion, as suggested by this thread on Reddit.


What Confused Me

The wiki page: Logical Block Addressing I recently came across caused some confusion.

As the substitute for the CHS addressing, it seems that LBA should handle the same task as CHS did: give addresses to sectors, as suggested in this article. But I sense the reluctance of the LBA wiki page to use the word "sector", as well as from its title "Logical Block Addressing".

So, is LBA just a fancy word which actually concerns addressing disk sectors?

Or does LBA-compliant disks really understand the concept of filesystem/logical block, and is capable of making block-level I/O, thus hide the existence of "sector" from operating system?


Also, please correct me if any prerequisite of my question is misunderstood. Thanks.

  • 3
    Depending on the context Block can be used to mean different things. As for LBA you don't care about the sector. In theory the drive could do whatever it wants to do as long as requesting LBA 1 would always return the same block/sector. Take an SSD as an example, which doesn't have the classic concept of sectors. A cluster of blocks is really just that. You're taking the low level "blocks" that might be 512 Byte (usual, classic sectors or nowadays also commonly 4 KiB) and use them as a logical block/cluster on your filesystem level. – Seth Dec 13 '17 at 12:15
  • @Seth So I guess the key idea of LBA is: "hey, 'sector' is something OS shouldn't care about. Let's handle this to embedded disk circuit and only expose logical block to OS"? Is that felicitous? – Cedric Sun Dec 13 '17 at 12:29
  • @Seth And in this way, filesystem considers the underlying disk as an ordered, linear address space, and no longer cares about its internal implementation. But filesystem block is still the concept beyond LBA Block or Physical Block, and is still comprised of multiple such blocks. Am I right? – Cedric Sun Dec 13 '17 at 12:36
  • Yes, people were tired of telling the drive to use the second platter/head, go to the third track and read the fifth sector on that track (CHS). You're correct that a block exposed by the filesystem might consist of multiple LBA blocks. There are various considerations in regard to physical sector sizes, how memory works and what kind of files you want to store to take into account for this. Also different filesystems might handle it differently. – Seth Dec 13 '17 at 12:51
  • 1
    @Seth Your comments really offered me much inspiration. Make it an answer, please! – Cedric Sun Dec 13 '17 at 13:07
4

I understand BLOCK generally means a batch of data seen as a whole I/O unit

The use of the term "block" is widespread in computing, and not restricted to I/O.

What I thought a logical block, or a filesystem block refers to is the minimal I/O unit seen as a whole used by specific filesystem, in order to, as the essence of any batch operation, reduce the overheads brought by reading or writing one sector one time.

IMO it would be careless to make sweeping definitions that encompass all filesystems. Be aware that the I/O blocksize for file data could be different from filesystem metadata. E.G. writes to a file could be consolidated into 4KB (or larger) blocks, but the filesystem journal may need to be written more often (with a smaller block) to ensure data retention.

"Batch operation" is old jargon, and you're using the term in a nonsensical manner.

And a physical block is exactly the synonym of a disk sector.

Only in the context of disk drives.
Magnetic tape requires I/O to be performed in physical blocks, but there is no concept of sectors with tape.

What's more, I believe the word CLUSTER is just filesystem block in Microsoft's fashion, as suggested by this thread on Reddit.

A "cluster" is a unit of allocation in MS filesystems.
Whether I/O is always performed in that same blocksize is questionable. E.G. When the cluster size is 64KB, and the entire file is just 128 bytes, is the filesystem going to write 128 sectors or optimize the I/O to just one sector?

So, is LBA just a fancy word which actually concerns addressing disk sectors?

Essentially yes (for legacy 512-byte sectors).

The integrated controller of the modern disk drive performs the mapping of LBA to physical sector. The actual cylinder, head, and sector that maps to a particular LBA is known only to the drive so that any type of zone-bit recording and relocation for bad sectors can be implemented by the disk drive.

With Advanced Format 512e HDDs that use 4096-byte sectors and a 512-byte transfer size, the term LBA is truly accurate: the address is not of a physical sector, but rather for a logical block consisting of an eighth of a sector.

Or does LBA-compliant disks really understand the concept of filesystem/logical block,

I'm not sure what you mean by "filesystem/logical block", but the answer is probably no.
It's simply a storage device with no concept of organizing the raw data it is storing.

See What kind of api does a sata hard-drive expose?

and is capable of making block-level I/O, thus hide the existence of "sector" from operating system?

The concept of sector (or physical block) cannot be eliminated, simply because that is the minimum unit of I/O. The lowest-levels of the OS (i.e. the device drivers) will always be cognizant of the hardware attributes. But each abstraction layer of the OS will try to obscure those details. So when you read a file, you may not know if it was retrieved from a HDD or DVD or over a network.

FWIW disk controllers (even old ones that used CHS addressing) can perform multi-sector read or write operations, e.g. perform a read of N sequential sectors.

| improve this answer | |
1

You're not wrong with the assumptions you're making but you have to take the context into account. Depending on the context the meaning of the word Block changes.

With LBA you're getting rid of the cumbersome CHS addressing scheme. With CHS you had to tell your drive you want it to use its second head to read the fifth track and the 20th sector on it. With LBA you don't care about those details. You're just telling it to get you the first logical Block. What logic it's using to determine what the first logical Block is, is up to the drive as long as it's a consistent scheme. Requesting the first logical block twice and getting different data would be pretty useless (most likely). This approach also offers some independence from the drive technology being used. For instance take an SSD, it doesn't have heads and tracks and sectors. With LBA you're still able to tell it to get you the first logical Block. This mechanism is pretty low level, you don't really have any understanding what a filesystem might be or what a file might be. The actual size of those blocks is dependent on the hardware. 512 Byte was pretty standard as a sector size for a long time but nowadays (for various reasons) 4 KiB isn't uncommon.

Just as an interesting side note have a look at Constant Angular Velociy(CAV) and Constant Linear Velocity (CLV) and how it impacts physical spinning disks. The latter isn't relevant to hard disks but to other kinds physical spinning disks. It can be interesting to know about the different approaches. As well as the CHS page or more specifically the CHS image. You might notice that in the image the physical dimension of a sector would increase as you go from the inner to the outer tracks. As such the information density would decrease. Notice that I wrote would, as current technology started to put more sectors on the outer tracks. Though it's based on the same principal (ZCAV). Of course with even more modern approaches like flash drives the issues on that level are going to be different (distributing wear and so on).

A cluster is usually a concatenation of the logical blocks to form a block on the filesystem level. So you might have 512 Byte logical blocks on your physical hardware but your filesystem works using 4 KiB blocks/cluster. As such for each block that your filesystem manages you're going to use 8 blocks on your hardware.

Reasons for this might be filesystem limitations (FAT16/32 etc.), performance and the kind of files you store. With bigger clusters you got less overhead to store big files but you will waste storage on smaller files.

| improve this answer | |
  • 1
    Your mention of CLV is irrelevant, since HDDs use a fixed rotational speed, i.e. CAV. Your statement about areal density is inaccurate for modern drives that use zone-bit recording. – sawdust Dec 14 '17 at 10:11
  • @sawdust as far as I know CHS was never used/can't be used with zone bit recording. Hence I mention it in relation to CHS and that particular image. While CLV is not relevant to hard disks it is for, literally, physical spinning disks. It's just a side note because at least I find it interesting that there is also a different approach. Of cause you're correct that zone bit (ZCAV especially) is relevant to current hard drive technology to avoid the problem of lower information density. Again also something that kind of ties into LAB. Thanks for bringing it up, I'll add a link to ZAC shortly. – Seth Dec 14 '17 at 10:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.