LBAs are a fiction on physical media too.
Mark Roddy
On Tue, Aug 5, 2014 at 6:47 PM, Marion Bond wrote:
> Note that enterprise flash devices implement wear leveling and other
> techniques that abstract even the logical block address from the location
> in physical media.
>
>
>
> Sent from Surface Pro
>
> From: Jan Bottorff
> Sent: Monday, August 04, 2014 4:23 PM
> To: Windows System Software Devs Interest List
>
> > [Put yourself in their shoes – If you reported an issue to your vendor
> and they responded “Who knows? It’s all outdated and you need to change
> your processes.” – what’s your reaction going to be?]
>
> Perhaps a better reply would be to tell them you do know what’s happening,
> and for about the last decade or two, sponging physical disks use a
> variable number of sectors per track, so it’s not possible to report a
> correct CHS geometry. Some drives may be able to tell you their actual
> geometry if you issue the correct mode page request. My memory is geometry
> is generally broken up into zones, there is a list of LBA x to y has
> geometry z values.
>
> If the goal is to pick a value for aligning partition start addresses,
> there are a couple of opinions on what the optimal value would be. You
> could report a value for heads and sectors per track such that the two
> multiplied give a appropriate alignment value. The classic problem with
> this is the the maximum disk size you can describe is vastly smaller than
> current drives, so setting H and S to their largest allowed values gave you
> the largest possible disk, which still is way smaller than current disks
> sizes, which is why we use LBAs now and not CHS.
>
> CHS in it’s bios field width form, can’t come close to describing modern
> sizes of disks. CHS was originally used because it matched up with some
> control registers for an ancient IDE disk controller in the ‘80s.
>
> In general, disks know a lot more about how to optimize their own
> performance than naive software, so there is a good argument you should
> just treat the disk at a linear array of block addresses (and know the
> block size), and let the drive do any performance optimizing.
>
> The partition alignment probably matters based on what RAID striping is
> applied, and one could view that some alignments are better for the RAID
> controller.
>
> There also is the modern issue of Flash memory chunk sizes. Flash memory
> can’t be updated on 512/4096 by boundaries, so you should likely align a
> partition on a natural boundary of the flash block size. If you write a lot
> of chunks a lot smaller than the native block size, you get write
> amplification and it uses up the limited number of writes each flash block
> can do. Writing 512 bytes every 128K or so is probably a great way to wear
> out your flash drive. I don’t think OSs or file systems really know how to
> use write block sizes other than 512/4096 bytes, even though a value like
> 128K is likely a lot better for flash storage life. This is one argument of
> why flash storage should talk in terms of file I/O requests, not blocks. If
> you do file I/O requests to a device, it can optimize it’s performance and
> wear. It might for example use a write mostly file file system, and store
> up changes in NVRAM buffers until a full flash block can be written. This
> offhand seems way more optimal than what we do now.
>
> A lot of storage is controlled by some complex storage controller, which
> may for example deal with blocks of some size unrelated to the physical
> disks. If you do write operations then span two storage controller blocks,
> it may give non-optimal performance. The virtual blocks you get from a
> complex storage controller (like from EMS/Netapp/etc), may report info
> about the optimal block alignment via mode pages.
>
> Jan
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>