How does Logical Cluster Number to LBA translation happen in NTFS?

Question

I'm reading about NTFS, and I found out that NTFS uses LCN (Logical Cluster Number) addresses for files. The information about data blocks are stored in the FCB of the file which is located in MFT.

As I understand, Ii believe it goes like this:

When a file read/write is requested by a process, the process uses the LCN's and these LCN's are then translated to LBA addresses by multiplying the LCN * cluster size. Then these LBA addresses are send to the disk controller which in turn then translates these LBA addresses to the actual physical block where the data is present.

More specifically: a process issues a syscall open() specifying file name and access rights, then the corresponding file is found in the system wide table (say some other process is also using the file), FCB is copied to per process table, then file blocks are fetched by the FS using all these mappings depending on the process needs!

Is my understanding correct?

References:

Book: OS Concepts page: 568

same book page: 875

quote:

NTFS uses logical cluster numbers (LCNs) as storage addresses. It assigns them by numbering clusters from the beginning of the device to the end. Using this scheme, the system can calculate a physical storage offset (in bytes) by multiplying the LCN by the cluster size.

Answer 1

You just need a few things.

• Offset to file system (typically start of the partition when dealing with NTFS) and also referred to as 'hidden sectors'
• You need to know sectors per cluster

We can get all this from the volume boot block:

Then we get LBA = hidden sectors (offset) + LCN * (sectors per cluster)

Note: for my data recovery related tools I never rely on 'hidden sectors' field in boot sector but rather rely on actual LBA address of the boot sector and assume that to be the offset from which I count clusters.

Then these LBA addresses are send to the disk controller which in turn then translates these LBA addresses to the actual physical block where the data is present.

Yes. If we assume traditional drive then no LBA to anything conversion takes place. But even if we consider SMR or SSD drives in which LBA addresses are dynamically mapped to physical addresses, from the perspective of the OS nothing changes as that part is handled by the drive's firmware.

NTFS uses logical cluster numbers (LCNs) as storage addresses. It assigns them by numbering clusters from the beginning of the device to the end.

I rather refer to it as start of the file-system, as IMO device could be easily confused for physical device or drive, for which LBA 0 would be the start. And we do not count clusters from LBA 0, we count from cluster 0 (in case of NTFS). So we need offset to cluster 0 relative to LBA 0.

Since in NTFS everything is a file, so is the boot 'sector' itself (referred to as $Boot in $MFT). And since it's the first file of the volume or file system we find it in cluster zero.