Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 27 Jul 2021 19:01:12 -0400
From:   "Theodore Ts'o" <tytso@mit.edu>
To:     Mikhail Morfikov <mmorfikov@gmail.com>
Cc:     linux-ext4@vger.kernel.org
Subject: Re: Is it safe to use the bigalloc feature in the case of ext4
 filesystem?
Message-ID: <YQCQODCGtJRTKwS9@mit.edu>
References: <0dc45cbd-b3b0-97ab-66a9-f68331cb483e@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0dc45cbd-b3b0-97ab-66a9-f68331cb483e@gmail.com>
Precedence: bulk

On Fri, Jul 23, 2021 at 05:30:13PM +0200, Mikhail Morfikov wrote:
> In the man ext4(5) we can read the following:
> 
>     Warning: The bigalloc feature is still under development, 
>     and may not be fully supported with your kernel or may 
>     have various bugs. Please see the web page 
>     http://ext4.wiki.kernel.org/index.php/Bigalloc for details. 
>     May clash with delayed allocation (see nodelalloc mount 
>     option).
> 
> According to the link above, the info is dated back to 2013, 
> which is a little bit ancient.
> 
> What's the current status of the feature? Is it safe to use 
> bigalloc on several TiB hard disks where only big files will be 
> stored?

Yes; the places where bigalloc is perhaps not as well tested is
support FALLOC_FL_COLLAPSE_RANGE, FALLOC_FL_INSERT_RANGE, and
FALLOC_FL_PUNCH_HOLE.  Bigalloc is also not very efficient for large
directories (where we allocate a full cluster for each directory
block).  Older kernels did not handle ENOSPC errors when delayed
allocation was enabled, but that has since been fixed, and bigalloc is
passing file system regression tests, so it should safe to use as
you've described.

Cheers,

					- Ted