From: Santosh S <santosh.letterz@gmail.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Andreas Dilger <adilger@dilger.ca>, linux-ext4@vger.kernel.org
Subject: Re: Overwrite faster than fallocate
Date: Thu, 23 Jun 2022 17:55:20 -0400 [thread overview]
Message-ID: <CAGQ4T_LU=aZ9og4E6RQgMCTC_RRGKpZzDQCSXjRBUsc9Nz5OkA@mail.gmail.com> (raw)
In-Reply-To: <YrTCbPK94Ejh4ei3@mit.edu>
On Thu, Jun 23, 2022 at 3:43 PM Theodore Ts'o <tytso@mit.edu> wrote:
>
> On Thu, Jun 23, 2022 at 02:28:47PM -0400, Santosh S wrote:
> >
> > What kind of write will stop an uninitialized extent from splitting?
> > For example, I want to create a file, fallocate 512MB, and zero-fill
> > it. But I want the file system to only create 4 extents so they all
> > reside in the inode itself, and each extent represents the entire
> > 128MB (so no splitting).
>
> If you write into an unitialized extent, it *has* to be split, since
> we have to record what has been initialized, and what has not. So for
> example:
>
> root@kvm-xfstests:/vdc# fallocate -l 1M test-file
> root@kvm-xfstests:/vdc# filefrag -vs test-file
> Filesystem type is: ef53
> File size of test-file is 1048576 (256 blocks of 4096 bytes)
> ext: logical_offset: physical_offset: length: expected: flags:
> 0: 0.. 255: 68864.. 69119: 256: last,unwritten,eof
> test-file: 1 extent found
> root@kvm-xfstests:/vdc# dd if=/dev/zero of=test-file bs=1k conv=notrunc bs=4k count=1 seek=10
> 1+0 records in
> 1+0 records out
> 4096 bytes (4.1 kB, 4.0 KiB) copied, 0.000252186 s, 16.2 MB/s
> root@kvm-xfstests:/vdc# filefrag -vs test-file
> Filesystem type is: ef53
> File size of test-file is 1048576 (256 blocks of 4096 bytes)
> ext: logical_offset: physical_offset: length: expected: flags:
> 0: 0.. 9: 68864.. 68873: 10: unwritten
> 1: 10.. 10: 68874.. 68874: 1:
> 2: 11.. 255: 68875.. 69119: 245: last,unwritten,eof
> test-file: 1 extent found
>
> However, if you write to an adjacent block, the extent will get split
> --- and then we will merge it to the initialized block. So for
> example, if we write to block 9:
>
> root@kvm-xfstests:/vdc# dd if=/dev/zero of=test-file bs=1k conv=notrunc bs=4k count=1 seek=9
> 1+0 records in
> 1+0 records out
> 4096 bytes (4.1 kB, 4.0 KiB) copied, 0.000205357 s, 19.9 MB/s
> root@kvm-xfstests:/vdc# filefrag -vs test-file
> Filesystem type is: ef53
> File size of test-file is 1048576 (256 blocks of 4096 bytes)
> ext: logical_offset: physical_offset: length: expected: flags:
> 0: 0.. 8: 68864.. 68872: 9: unwritten
> 1: 9.. 10: 68873.. 68874: 2:
> 2: 11.. 255: 68875.. 69119: 245: last,unwritten,eof
> test-file: 1 extent found
>
> So if you eventually write all of the blocks, because of the split and
> the merging behavior, eventually the extent tree will be put into an efficient state:
>
> root@kvm-xfstests:/vdc# dd if=/dev/zero of=test-file bs=1k conv=notrunc bs=4k count=9 seek=0
> ...
> root@kvm-xfstests:/vdc# filefrag -vs test-file
> Filesystem type is: ef53
> File size of test-file is 1048576 (256 blocks of 4096 bytes)
> ext: logical_offset: physical_offset: length: expected: flags:
> 0: 0.. 10: 68864.. 68874: 11:
> 1: 11.. 255: 68875.. 69119: 245: last,unwritten,eof
> test-file: 1 extent found
> root@kvm-xfstests:/vdc# dd if=/dev/zero of=test-file bs=1k conv=notrunc bs=4k count=240 seek=11
> ...
> root@kvm-xfstests:/vdc# filefrag -vs test-file
> Filesystem type is: ef53
> File size of test-file is 1048576 (256 blocks of 4096 bytes)
> ext: logical_offset: physical_offset: length: expected: flags:
> 0: 0.. 250: 68864.. 69114: 251:
> 1: 251.. 255: 69115.. 69119: 5: last,unwritten,eof
> test-file: 1 extent found
> root@kvm-xfstests:/vdc# dd if=/dev/zero of=test-file bs=1k conv=notrunc bs=4k count=5 seek=251
> ...
> root@kvm-xfstests:/vdc# filefrag -vs test-file
> Filesystem type is: ef53
> File size of test-file is 1048576 (256 blocks of 4096 bytes)
> ext: logical_offset: physical_offset: length: expected: flags:
> 0: 0.. 255: 68864.. 69119: 256: last,eof
> test-file: 1 extent found
> root@kvm-xfstests:/vdc#
>
> Bottom-line, there isn't just splitting, but there is also merging
> going on. So it's not really something that you need to worry about.
>
> Cheers,
>
> - Ted
Nice! Thank you.
prev parent reply other threads:[~2022-06-23 21:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-17 16:38 Overwrite faster than fallocate Santosh S
2022-06-17 22:12 ` Theodore Ts'o
2022-06-17 23:56 ` Santosh S
2022-06-18 0:41 ` Santosh S
2022-06-20 18:52 ` Andreas Dilger
2022-06-23 18:28 ` Santosh S
2022-06-23 19:43 ` Theodore Ts'o
2022-06-23 21:55 ` Santosh S [this message]
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='CAGQ4T_LU=aZ9og4E6RQgMCTC_RRGKpZzDQCSXjRBUsc9Nz5OkA@mail.gmail.com' \
--to=santosh.letterz@gmail.com \
--cc=adilger@dilger.ca \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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.