99cbd70f0b
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. PR: 212139 Discussed with: tsoome, allanjude |
||
---|---|---|
.. | ||
amd64_tramp.S | ||
biosacpi.c | ||
bioscd.c | ||
biosdisk.c | ||
biosmem.c | ||
biospci.c | ||
biospnp.c | ||
biossmap.c | ||
bootinfo32.c | ||
bootinfo64.c | ||
bootinfo.c | ||
comconsole.c | ||
devicename.c | ||
elf32_freebsd.c | ||
elf64_freebsd.c | ||
i386_copy.c | ||
i386_module.c | ||
libi386.h | ||
Makefile | ||
Makefile.depend | ||
multiboot_tramp.S | ||
multiboot.c | ||
multiboot.h | ||
nullconsole.c | ||
pread.c | ||
pxe.c | ||
pxe.h | ||
pxetramp.s | ||
smbios.c | ||
smbios.h | ||
spinconsole.c | ||
time.c | ||
vidconsole.c |