Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 12 Aug 2016 12:18:32 -0700
From:      John Baldwin <jhb@freebsd.org>
To:        freebsd-hackers@freebsd.org
Cc:        Andriy Gapon <avg@freebsd.org>
Subject:   Re: on BIOS problems with disks larger than 2 TB
Message-ID:  <490347865.SvN7iQoFWI@ralph.baldwin.cx>
In-Reply-To: <6cec427b-4df1-50f0-3014-a96e5f8210f5@FreeBSD.org>
References:  <6cec427b-4df1-50f0-3014-a96e5f8210f5@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, August 02, 2016 04:35:23 PM Andriy Gapon wrote:
> 
> There are some BIOSes out there that do not properly support disks
> larger than 2TB and cause boot problems if there is any data required
> for boot at offsets larger than 2 TB (TiB, rather).
> 
> The most typical victim is the ZFS boot if a boot pool includes disk
> areas beyond 2TB, because a kernel, or zfsloader or any configuration
> files required by the loader may end up in those "inaccessible" areas.
> 
> It's obvious why 2TiB is a magic value here:
> 2^32 * 512 = 2^41 = 2 * 2^40
> So the problem seems to happen when an LBA is treated as a 32-bit
> integer (unsigned).
> 
> I happen to own one of affected systems and I have done some more
> investigation.  As far as I can see, the only actual problem in my case
> is that a disk size in 512b sectors is reported modulo 2^32 by INT 13h
> AH=48h.  If I "fix up" the parameter, then everything else (i.e. actual
> data reads) seems to work just fine after that.
> 
> I suspect that a large subclass of other problematic systems may have
> exactly the same problem.
> 
> Does anyone have an idea about how we could auto-detect and and
> auto-correct that problem?
> Would that be worth the trouble at all?  Given the gradual de-orbiting
> of BIOS systems.

Hmm, I'm not sure how easy it is to handle this case (i.e. how do you know
if an LBA beyond the size is really legit due to truncation vs coming from
corrupted metadata).  Related is that tsoome's bcache stuff wants to know
where the end of the disk is (to avoid reading off the end), so just
ignoring the size is not easy.

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?490347865.SvN7iQoFWI>