Re: xfs: Temporary extra disk space consumption?

[Dave Chinner <david@fromorbit.com>]

On Thu, Mar 24, 2022 at 08:28:30AM +0900, Tetsuo Handa wrote:
> On 2022/03/24 4:16, Dave Chinner wrote:
> > On Wed, Mar 23, 2022 at 08:21:52PM +0900, Tetsuo Handa wrote:
> >> Hello.
> >>
> >> I found that running a sample program shown below on xfs filesystem
> >> results in consuming extra disk space until close() is called.
> >> Is this expected result?
> > 
> > Yes. It's an anti-fragmentation mechanism that is intended to
> > prevent ecessive fragmentation when many files are being written at
> > once.
> 
> OK, this is an xfs specific behavior.
> 
> > Looks like specualtive preallocation for sequential writes is
> > behaving exactly as designed....
> 
> Here is the result of "filefrag -v my_testfile" before close().
> 
> Filesystem type is: 58465342
> File size of my_testfile is 1073741824 (262144 blocks of 4096 bytes)
>  ext:     logical_offset:        physical_offset: length:   expected: flags:
>    0:        0..   65519:   33363497..  33429016:  65520:
>    1:    65520..  229915:   62724762..  62889157: 164396:   33429017:
>    2:   229916..  262143:   63132138..  63164365:  32228:   62889158: eof
>    3:   262144..  294895:   63164366..  63197117:  32752:             unwritten,eof
> my_testfile: 3 extents found
> 
> Filesystem type is: 58465342
> File size of my_testfile is 1073741824 (262144 blocks of 4096 bytes)
>  ext:     logical_offset:        physical_offset: length:   expected: flags:
>    0:        0..  131055:   62724762..  62855817: 131056:
>    1:   131056..  240361:   63813369..  63922674: 109306:   62855818:
>    2:   240362..  262143:   32448944..  32470725:  21782:   63922675: eof
>    3:   262144..  349194:   32470726..  32557776:  87051:             unwritten,eof
>    4:   349195..  524271:          0..    175076: 175077:   32557777: unknown,delalloc,eof
> my_testfile: 4 extents found
> 
> An interesting behavior I noticed is that, since "filefrag -v" opens this file
> for reading and then closes this file descriptor opened for reading, injecting
> close(open(filename, O_RDONLY)) like below causes consumption by speculative
> preallocation gone; close() of a file descriptor opened for writing is not
> required.

Yup. This has never had a measurable impact on real world workloads
for us to need to optimise that away. Besides, ->release() cannot
tell if the prealloc belongs to that fd or not, so even if we were
to gate it on O_RDONLY, closing any writeable fd on that inode would
trigger the same behaviour regardless of whether that was the fd
that hte data was written to....

-Dave.
-- 
Dave Chinner
david@fromorbit.com