loader: freebsd PR: 212139
commitbf907dd191d1577534df4b013e32106ccfe01390
authorToomas Soome <tsoome@me.com>
Sun, 28 Aug 2016 20:58:25 +0000 (28 23:58 +0300)
committerToomas Soome <tsoome@me.com>
Tue, 30 Aug 2016 12:30:07 +0000 (30 15:30 +0300)
tree0881f3c67f92b354b9d64a95a3515f150e97188b
parent56f07d651878ec62f0807859f027ca557f54f8b7
loader: freebsd PR: 212139

Log:
 The read-ahead code from r298230 made it likely the boot code would read
 beyond the end of disk. r298900 added code to prevent this.  Some BIOSes
 cause significant delays if asked to read past end-of-disk.

 We never trusted the BIOS to accurately report the sectorsize of disks
 before and this set of changes.  Unfortuately they interact badly with
 the infamous >2TB wraparound bugs.  We have a number of relatively-recent
 machines in the FreeBSD.org cluster where the BIOS reports 3TB disks as 1TB.

 With pre-r298900 they work just fine.  After r298900 they stop working if
 the boot environment attempts to access anything outside the first 1TB on
 the disk.  'ZFS: I/O error, all block copies unavailable' etc.  It affects
 both UFS and ZFS if they try to boot from large volumes.

 This change replaces the blind trust of the BIOS end-of-disk reporting
 with a read-ahead clip to prevent reads crossing the of end-of-disk
 boundary.  Since 2^32 (2TB) size reporting truncation is not uncommon,
 the clipping is done on 2TB aliases of the reported end-of-disk.
 ie: a 3TB disk reported as 1TB has readahead clipped at 1TB, 3TB, 5TB, ...
 as one of them is likely to be the real end-of-disk.

 This should make the loader on these broken machines behave the same as
 traditional pre-r298900 loader behavior, without disabling read-ahead.
usr/src/boot/sys/boot/i386/libi386/biosdisk.c