All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: Dave Chinner <david@fromorbit.com>,
	"Darrick J. Wong" <djwong@kernel.org>
Cc: linux-xfs <linux-xfs@vger.kernel.org>
Subject: Re: xfs: Temporary extra disk space consumption?
Date: Thu, 24 Mar 2022 08:28:30 +0900	[thread overview]
Message-ID: <29f2af94-3f79-5044-aae1-9e10a30d4864@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <20220323191647.GT1544202@dread.disaster.area>

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.

----------
diff -u my_write_unlink.c my_write_unlink2.c
--- my_write_unlink.c
+++ my_write_unlink2.c
@@ -23,6 +23,8 @@
                return 1;
        printf("Before close().\n");
        system("/bin/df -m .");
+       close(open(filename, O_RDONLY));
+       system("/bin/df -m .");
        if (close(fd))
                return 1;
        printf("Before unlink().\n");
----------

----------
Before write().
Filesystem     1M-blocks   Used Available Use% Mounted on
/dev/sda1         255875 130396    125479  51% /
Before close().
Filesystem     1M-blocks   Used Available Use% Mounted on
/dev/sda1         255875 132447    123428  52% /
Filesystem     1M-blocks   Used Available Use% Mounted on
/dev/sda1         255875 131420    124455  52% /
Before unlink().
Filesystem     1M-blocks   Used Available Use% Mounted on
/dev/sda1         255875 131420    124455  52% /
After unlink().
Filesystem     1M-blocks   Used Available Use% Mounted on
/dev/sda1         255875 130396    125479  51% /
----------


  reply	other threads:[~2022-03-23 23:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-23 11:21 xfs: Temporary extra disk space consumption? Tetsuo Handa
2022-03-23 16:51 ` Darrick J. Wong
2022-03-23 19:16 ` Dave Chinner
2022-03-23 23:28   ` Tetsuo Handa [this message]
2022-03-24  1:13     ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=29f2af94-3f79-5044-aae1-9e10a30d4864@I-love.SAKURA.ne.jp \
    --to=penguin-kernel@i-love.sakura.ne.jp \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.