Date: Thu, 25 Aug 2016 20:18:05 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 212139] r298900 introduced a fatal failure case for >2TB disk size reporting bugs Message-ID: <bug-212139-8-AekuBViamI@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-212139-8@https.bugs.freebsd.org/bugzilla/> References: <bug-212139-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212139 --- Comment #1 from Peter Wemm <peter@FreeBSD.org> --- I'm adding another thought experiment hack. The problem is that we can't trust the bios media size reporting mixed with readahead causing read-beyond-end-of-disk. Might it be sufficient to simply de-fang the readahead when crossing 2TB aliases of the end of disk? That should restore behavior comparable to the= old loader. In other words, suppose a 3TB disk incorrectly reported as 1TB. Instead of assuming the disk is actually 1TB, instead we assume it could be 1TB, 3TB, = 5TB, ... for the purposes of preventing readahead. This would prevent readahead= of reading the last sector of a 3TB disk misreported as 1TB. I've probably done the math wrong in the hack, but the idea should be clear enough to show the idea. It just truncates the end-of-disk math to cause i= t to calculate using aliases. I think it would be sufficient, and would be compatible with old 10.x and earlier behavior. It should stop the 10.3 -> 11.0 -> brick upgrade path. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-212139-8-AekuBViamI>