mirror of
https://github.com/opnsense/src.git
synced 2026-04-04 17:05:14 -04:00
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 | ||
| bootinfo.c | ||
| bootinfo32.c | ||
| bootinfo64.c | ||
| comconsole.c | ||
| devicename.c | ||
| elf32_freebsd.c | ||
| elf64_freebsd.c | ||
| i386_copy.c | ||
| i386_module.c | ||
| libi386.h | ||
| Makefile | ||
| Makefile.depend | ||
| multiboot.c | ||
| multiboot.h | ||
| multiboot_tramp.S | ||
| nullconsole.c | ||
| pread.c | ||
| pxe.c | ||
| pxe.h | ||
| pxetramp.s | ||
| smbios.c | ||
| smbios.h | ||
| spinconsole.c | ||
| time.c | ||
| vidconsole.c | ||