Talk:Logical block addressing

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
???	This article has not yet received a rating on the project's importance scale.
	This article is supported by Computer hardware task force.

Ambiguity in ATA maxes, seek advice

Before I took a stab at clarifying the ATA stuff, the article read:

...limited to 1024/4096/16384, 16/256 and 63 respectively. Original limits were 1024*16*63, but newer BIOSes can transform a coordinate system with more than 16 (virtual) disk heads into one which has more cylinders instead, or they can transform CHS coordinates in a coordinate system of up to 1024*255*63 size...

This isn't really very clear, as it doesn't say what the circumstances were when 1024/4096/16384 was the max and when 1024/255/63 was. We should present all the different eras and their corresponding maxes, hopefully with max volume size calculations for each. -- Finlay McWalter | Talk 23:03, 22 September 2005 (UTC)[reply]

Ignore BIOS Geometry

If Linux (and others) do not use BIOS geometry to determine hard disk size, what does it use? Can we provide an explanation of the alternative scheme?

--64.173.240.130 (talk) 20:49, 18 March 2008 (UTC)[reply]

I'll attempt to do so at a later date. Essentially they communicate with the hard disks using ATA commands themselves, which is how they can ignore the BIOS code. Daniel B. Sedory (talk) 14:58, 20 March 2008 (UTC)[reply]

Complicated topic

For such a simple concept, this topic gets pretty complicated. Besides being an obvious indexing of disk blocks, LBA refers to specific ATA standards, and its interaction with the coexisting CHS systems. Besides the 10/8/6 CHS of INT 13H and the DOS MBR, the 16/4/8 CHS and 28-bit LBA of ATA-1, and the 48-bit LBA of ATA-6, there's a 32 bit LBA in the DOS MBR. There's a lot of history here. Ozga (talk) 01:16, 17 November 2009 (UTC)[reply]

Is LBA affected by remapped sectors?

I haven't worked with HDDs in many years, so I am out-of-date on much. However, I am assuming that drives still have occasional bad spots on their platters--and that the drive's internal logic skips over or remaps those spots to previously unallocated spots on the drive. If so, how is this handled by the drive? Does it tell the controller outside of the drive that those LBAs are badand thus are not available? Or does the drive just assign sectors in a previously unallocated area to "assume" the LBAs of the bad sectors--and do all of this transparently to the external controller? Biscuiteater57 (talk) 13:13, 29 February 2012 (UTC)[reply]

If implemented, bad sector relocation works transparent inside the drive for both CHS and LBA access. If the drive receives a command to read an unrecoverably bad sector, the drive will return an error, otherwise it will return the sector contents without indicating an error. The operating system could decide to mark those areas affected by detected bad sectors in the file system in order to indicate and handle this on a higher level, but this is left entirely to the implementor of the operating system. Smart drives will internally relocate weak sectors before they become unreadable by remapping them to internal spare areas which will not be reported to the outside. Cheap drives typically have smaller reserved areas, whereas server drives have lots of them. The BIOS/operating system can query a drive's view on its fitnet via S.M.A.R.T. etc. --Matthiaspaul (talk) 16:36, 29 February 2012 (UTC)[reply]

Merge/assembly code

I have merged redundant sections from CHS conversion and Cylinder-head-sector; the former includes an assembly code example which is obviously too simple to work right, so I placed it here for review. --Dmitry _{(talk •contibs )} 22:29, 28 October 2010 (UTC)[reply]

Assembler code example

The following procedure calculates the geometric coordinate of a block of data based on an LBA address specified. Only works when AX is enough to hold LBA.

GetCHS proc
  mov  AX, LBA
  xor  DX, DX
  mov  BX, SPT
  div  BX
  inc  DX
  mov  SECT, DL
  xor  DX, DX
  mov  BX, HPC
  div  BX
  mov  CYL, AL
  mov  HEAD, DL
  ret	
GetCHS endp

Incorrect LBA -> CHS Information

You are correct that the code is wrong. Two problems exist in the current code. First, the cylinders and heads need to be swapped. Second, the cylinder is actually 10 bits big when working with the BIOS interrupts while the sector is only 6 bits big. It would be nice for someone to modify this code as this code has propagated through out the internet. (Tested using a custom made boot sector in Bochs emulating a 1.44MB floppy.)

--Jorgy343 (talk) 03:04, 26 December 2009 (UTC)[reply]

LBA and LUN virtualization

What is the purpose of this paragraph? Modern SATA/SAS hard disks use LBA to adress its blocks, so a hardware RAID and/or external SAN drive (which most likely uses Linux inside) should feature a software layer which will make LBA translations between physical disks to present a disk array as a uniform logical drive to the OS. The same goes for SCSI or ATA/SATA device adressing - the software will virtualize LUNs of individual disks and present a unified LUN for the entire storage device. Does it really deserve any specific mention in regard to LBA? --Dmitry _{(talk •contibs )} 12:08, 29 October 2010 (UTC)[reply]

Jeh Needs to learn how to read

So I go to use Wikipedia and find that I got this message from Jeh (talk):

Please refrain from making test edits in Wikipedia pages, such as those you made to Logical block addressing‎, even if you intend to fix them later. 
Such edits appear to be vandalism and have been reverted. If you would like to experiment again, please use the sandbox. 
Thank you. Jeh (talk) 19:10, 10 February 2011 (UTC)

Dear Jeh, if you will pay close attention to the note on my edit, as you should have before spouting off like an idiot with his minuscule seat of fiefdom, you will note that it clearly says, and I quote:

"implemplementation" isn't a word

So am I wrong? Why don't you pull your own head out of your beloved sandbox, implemplement some research, see the diff here and decide for yourself: http://en.wikipedia.org/w/index.php?title=Logical_block_addressing&diff=406640301&oldid=404973263

Wake up. —Preceding unsigned comment added by 58.84.234.136 (talk) 07:46, 1 March 2011 (UTC)[reply]

Ambiguity in "device controller" - overview

In the 2nd para of Overview, it's not clear (to me, at least) whether "drive controller" refers to the PC's IDE or SATA controller, or the control board on the drive itself, though in either case it must be a LBA address which passes down the PATA or SATA cable. —Preceding unsigned comment added by Pleriche (talk • contribs) 12:21, 9 May 2011 (UTC)[reply]

os dependencies, guid partition table

That section does not seem to be entirely correct: NTLOADER-32 doesn't inherently prevent you from booting off a GUID partition table.

XP, 2003 32 bit versions can boot from SCSI drives: SCSI drives are typically not MBR CHS systems, and the logical disks may be identified by GUID in BOOT.INI if "drive/partition" information doesn't exist. — Preceding unsigned comment added by 203.206.162.148 (talk) 04:40, 26 May 2011 (UTC)[reply]

Needs a disambiguation page

This is currently the first Google hit for LBA, which can at least mean linear bounded automaton, probably among other meanings.

Lucaswiman (talk) 17:01, 26 June 2012 (UTC)[reply]

Does LBA know about block size?

It isn't clear if LBA knows or cares about the physical sector size. Does each LBA necessarily uniquely map to a physical sector? All or most drives today have switched to 4096 byte sectors. Linux uses 512 bytes for its logical block size. If LBA blocks also specified a 512 byte size then a single physical sector would span multiple LBAs. On the other hand, if LBA doesn't care about the size of blocks then they could map 1-to-1 to physical sectors.

My guess is that LBA has nothing to do with the notion of block or sector size, so it maps 1-to-1 with a physical sector. Whatever size the physical sectors may be it does not affect the LBA. Note that when I say physical sector, I mean the sector size reported to the world through the drive's interface. There may be hidden translation going on in the drive's firmware. I believe most drive using 4096 byte sector sizes hide this and report 512 byte sector sizes for the purposes of LBA.

At any rate, it would be nice if the article made it clear if LBA is a 1-to-1 mapping to the physical sectors and if LBA requires the notion of a block size. --NoahSpurrier (talk) 23:22, 4 November 2013 (UTC)[reply]

Noahspurrier, if LBA maps to physical sectors, shouldn't it be Logical sector addressing? I think it should be about blocks given the naming and the sense of abstraction in modern systems. However, maybe it does map to physical sectors most of the time. See Rod Smith's article Working Around MBR's Limitations:

In December of 2009, Western Digital introduced the first drives using a new technology, known as Advanced Format. In brief, in a bid to overcome various technical limitations unrelated to disk partitioning, drive manufacturers are beginning a shift from 512-byte to 4096-byte sector sizes. (Western Digital was the first to market, but Seagate and others have followed.) Since partitions are defined in terms of sectors, though, such a shift can at least theoretically provide a boon to those attempting to eke a bit more life out of MBR. On a disk with a 4096-byte sector size, the 2 TiB limit of MBR is boosted eight-fold, to 16 TiB. Of course, a shift to 4096-byte sectors will only delay the inevitable doom of MBR, but it could still be useful as a stopgap measure.

Unfortunately, some OSes and utilities include hard-coded assumptions about sector sizes, and will only work properly with hard disks that employ 512-byte sectors. Although I've not tested it for this effect, the claim is that Windows XP can't handle such disks, although Windows Vista and later, as well as Mac OS X and Linux, can. Linux isn't completely immune to this problem, though; although it handles unusual sector sizes well for the most part, the Linux kernel prior to about version 2.6.33 includes a bug that prevents GPT disks from being properly detected on anything but drives with 512-byte sectors. In order to overcome such problems, all drives I am aware of to date (mid-2011) to use 4096-byte sectors include firmware that presents the illusion of 512-byte sectors to the OS. It's conceivable this will change as drives exceed the 2 TiB limit, although the only model I know of with 4096-byte physical sectors of that size is an Advanced Format model that pretends to have 512-byte sectors.

So it seems at least back in 2011 it was a mixed bag. But also see this 2004 Dell whitepaper BEYOND THE 2-TB SCSI LOGICAL UNIT:

Within the MBR data structure, a partition table contains information describing how the disk is partitioned. Each entry in the table lists the cylinder/head/sector (CHS) location for each partition, as well as the partition type information. Four-byte fields in the partition table restrict the total number of sectors in the logical unit to 232 - 1. Thus, under the x86 architecture, the maximum size of a partition using standard 512-byte sectors is 2 TB. This partition size limitation must be addressed so that applications can take effective advantage of the large logical units enabled by changes to the SCSI Block Command (SBC) set discussed in the next section. The industry is addressing the limitation in the MBR partition table by adopting the GPT format used by the Intel Itanium architecture. GPT identifies and defines partitions by their logical block addresses (LBAs), rather than by CHS location.

II | (t - c) 17:56, 13 December 2015 (UTC)[reply]

To clear this up: "Logical blocks" are a term of art brought over from SCSI, and with SCSI, it assumes that the initiator (the computer) and the target (the drive) have agreed on a block size before reading or writing, either by convention (before Advanced Format, practically all drives that weren't for exotic purposes and weren't CD-ROMs were formatted for 512-byte blocks), or by using the SET BLOCK SIZE command. Once you get to reading or writing, both on ATA and SCSI, the drive will only want to know what address and how many blocks. -lee (talk) 02:16, 3 June 2017 (UTC)[reply]