From: Jan Kara <jack@suse.cz>
To: Dave Chinner <david@fromorbit.com>
Cc: Sitsofe Wheeler <sitsofe@gmail.com>,
linux-fsdevel@vger.kernel.org, drh@sqlite.org
Subject: Re: Questions about filesystems from SQLite author presentation
Date: Tue, 7 Jan 2020 09:47:23 +0100 [thread overview]
Message-ID: <20200107084723.GA26849@quack2.suse.cz> (raw)
In-Reply-To: <20200106101518.GI23195@dread.disaster.area>
On Mon 06-01-20 21:15:18, Dave Chinner wrote:
> On Mon, Jan 06, 2020 at 07:24:53AM +0000, Sitsofe Wheeler wrote:
> > For 3. it sounded like Jan Kara was saying there wasn't anything at
> > the moment (hypothetically you could introduce a call that marked the
> > extents as "unwritten" but it doesn't sound like you can do that
>
> You can do that with fallocate() - FALLOC_FL_ZERO_RANGE will mark
> the unused range as unwritten in XFS, or you can just punch a hole
> to free the unused space with FALLOC_FL_PUNCH_HOLE...
Yes, this works for ext4 the same way.
> > today) and even if you wanted to use something like TRIM it wouldn't
> > be worth it unless you were trimming a large (gigabytes) amount of
> > data (https://youtu.be/-oP2BOsMpdo?t=6330 ).
>
> Punch the space out, then run a periodic background fstrim so the
> filesystem can issue efficient TRIM commands over free space...
Yes, in that particular case Richard was mentioning with Sqlite, he was
asking about a situation where he has a DB file which has 64k free here,
256k free there and whether it helps the OS in any way to tell that these
areas are free (but will likely get reused in the future). And in this case
I told him that punching out the free space is going to do more harm than
good (due to fragmentation) and using FALLOC_FL_ZERO_RANGE isn't going to
bring any benefit to the filesystem or the storage. He was also wondering
whether using TRIM for these free areas on disk is useful and I told him
that for current devices I don't think it will bring any benefit with the
sizes he is talking about.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2020-01-07 8:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-06 7:24 Questions about filesystems from SQLite author presentation Sitsofe Wheeler
2020-01-06 10:15 ` Dave Chinner
2020-01-07 8:40 ` Sitsofe Wheeler
2020-01-07 8:55 ` Jan Kara
2020-01-07 17:18 ` Darrick J. Wong
2020-01-07 8:47 ` Jan Kara [this message]
2020-01-06 15:40 ` Amir Goldstein
2020-01-06 16:42 ` Matthew Wilcox
2020-01-07 9:28 ` Sitsofe Wheeler
2020-01-06 18:31 ` Amir Goldstein
2020-01-07 9:16 ` Jan Kara
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=20200107084723.GA26849@quack2.suse.cz \
--to=jack@suse.cz \
--cc=david@fromorbit.com \
--cc=drh@sqlite.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=sitsofe@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).