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 <erikjen...@rkjnsn.net>
Signed-off-by: Qu Wenruo <w...@suse.com>
This doesn't apply cleanly to misc-next so it needs to be respun, but otherwise
Reviewed-by: Josef Bacik <jo...@toxicpanda.com>
Thanks,
Josef
