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@xxxxxxxxxxxxx