On Fri, Apr 09, 2021 at 01:24:20PM +0800, 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 <erikjen...@rkjnsn.net>
> Signed-off-by: Qu Wenruo <w...@suse.com>
> Reviewed-by: Josef Bacik <jo...@toxicpanda.com>

I've added some references and updated wording what's the problem. Patch
moved from topic branch to misc-next, thanks.

Reply via email to