Re: [PATCH] btrfs: do more graceful error/warning for 32bit kernel

[David Sterba <dsterba@suse.cz>]

On Fri, Feb 26, 2021 at 07:43:36AM +0800, Qu Wenruo wrote:
> On 2021/2/25 下午11:34, David Sterba wrote:
> > On Thu, Feb 25, 2021 at 07:44:19AM +0800, Qu Wenruo wrote:
> >>
> >>
> >> On 2021/2/25 上午3:18, David Sterba wrote:
> >>> On Sat, Feb 20, 2021 at 10:06:33AM +0800, Qu Wenruo wrote:
> >>>> Due to the pagecache limit of 32bit systems, btrfs can't access metadata
> >>>> at or beyond 16T boundary correctly.
> >>>>
> >>>> And unlike other fses, btrfs uses internally mapped u64 address space for
> >>>> all of its metadata, this is more tricky than other fses.
> >>>>
> >>>> Users can have a fs which doesn't have metadata beyond 16T boundary at
> >>>> mount time, but later balance can cause btrfs to create metadata beyond
> >>>> 16T boundary.
> >>>
> >>> As this is for the interhal logical offsets, it should be fixable by
> >>> reusing the range below 16T on 32bit systems. There's some logic relying
> >>> on the highest logical offset and block group flags so this needs to be
> >>> done with some care, but is possible in principle.
> >>
> >> I doubt, as with the dropping price per-GB, user can still have extreme
> >> case where all metadata goes beyond 16T in size.
> >
> > But unlikely on a 32bit machine. And if yes we'll have the warnings in
> > place, as a stop gap.
> >
> >> The proper fix may be multiple metadata address spaces for 32bit
> >> systems, but that would bring extra problems too.
> >>
> >> Finally it doesn't really solve the problem that we don't have enough
> >> test coverage for 32 bit at all.
> >
> > That's true and it'll be worse as distributions drop 32bit builds. There
> > are stil non-intel arches that slowly get the 64bit CPUs but such
> > machines are not likely to have huge storage attached. Vendors of NAS
> > boxes patch their kernels anyway.
> >
> >> So for now I still believe we should just reject and do early warning.
> >
> > I agree.
> >>
> >> [...]
> >>>>
> >>>> +#if BITS_PER_LONG == 32
> >>>> +#define BTRFS_32BIT_EARLY_WARN_THRESHOLD	(10ULL * 1024 * SZ_1G)
> >>
> >> Although the threshold should be calculated based on page size, not a
> >> fixed value.
> >
> > Would it make a difference? I think setting the early warning to 10T
> > sounds reasonable in all cases. IMHO you could keep it as is.
> 
> The problem is page size.
> 
> If we have 64K page size, the file size limit would be 256T, and then
> 10T threshold is definitely too low.

That makes sense but are there 32bit CPUs with 64K pages? Adding the
warning won't cause harm, of course.

So out of curiosity I searched for that cpu/page combo at it is allowed
eg. on MIPS, oh well.