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

[Josef Bacik <josef@toxicpanda.com>]

On 2/24/21 8:18 PM, Qu Wenruo wrote:
> Due to the pagecache limit of 32bit systems, btrfs can't access metadata
> at or beyond (ULONG_MAX + 1) << PAGE_SHIFT.
> This is 16T for 4K page size while 256T for 64K page size.
> 
> 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 the boundary at
> mount time, but later balance can cause btrfs to create metadata beyond
> the boundary.
> 
> And modification to MM layer is unrealistic just for such minor use
> case.
> 
> To address such problem, this patch will introduce the following checks,
> much like how XFS handles such problem:
> 
> - Mount time rejection
>    This will reject any fs which has metadata chunk at or beyond the
>    boundary.
> 
> - Mount time early warning
>    If there is any metadata chunk beyond 5/8 of the boundary, we do an
>    early warning and hope the end user will see it.
> 
> - Runtime extent buffer rejection
>    If we're going to allocate an extent buffer at or beyond the boundary,
>    reject such request with -EOVERFLOW.
>    This is definitely going to cause problems like transaction abort, but
>    we have no better ways.
> 
> - Runtime extent buffer early warning
>    If an extent buffer beyond 5/8 of the max file size is allocated, do
>    an early warning.
> 
> Above error/warning message will only be outputted once for each fs to
> reduce dmesg flood.
> 
> Reported-by: Erik Jensen <erikjensen@rkjnsn.net>
> Signed-off-by: Qu Wenruo <wqu@suse.com>

This doesn't apply cleanly to misc-next so it needs to be respun, but otherwise

Reviewed-by: Josef Bacik <josef@toxicpanda.com>

Thanks,

Josef