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.
