From: Michael Monnerie <michael.monnerie@is.it-management.at>
To: xfs@oss.sgi.com
Cc: Christoph Hellwig <hch@infradead.org>,
Lukas Czerner <lczerner@redhat.com>
Subject: Re: xfs: add FITRIM support
Date: Wed, 5 Jan 2011 23:07:35 +0100 [thread overview]
Message-ID: <201101052307.38379@zmi.at> (raw)
In-Reply-To: <alpine.LFD.2.00.1101051105120.3095@dhcp-lab-213.englab.brq.redhat.com>
[-- Attachment #1.1: Type: Text/Plain, Size: 1766 bytes --]
On Mittwoch, 5. Januar 2011 Lukas Czerner wrote:
> If we
> notice that we are running out of space in advance (how much in
> advance?), we can start trimming smaller chunks, until we reach
> reasonable a reasonable pool of reclaimed space, or until we trim
> the whole device.
Would it be possible that all blocks that have been in use since the
last FITRIM run can be logged? Like this, we would only need to clean
those. If you have a 2TB volume, probably only 25% of it have been
rewritten (=500GB) since the last run, and of that maybe 80% are still
in use at the time we run FITRIM, so only 100GB would need the cleanup.
Maybe each AG could store a bitmap of written blocks, that are reset by
a FITRIM run. That could be an asynchronous written bitmap and shouldn't
disturb performance too much. Maybe it's even only needed to store a bit
per sunit*swidth blocks, to keep that table small. A mount option could
be used to enable that feature, so only those which use thin
provisioning or SSDs or similar devices enable it at wish.
Especially for 100TB size devices that seems like something that should
be thought of, as maybe if you run FITRIM once a week there, only <10TB
have been rewritten, if at all, and such a table would boost a FITRIM
run a lot.
But maybe this is just bullshit of my tired brain, and I'm not a dev so
I have no idea how hard it would be to implement that.
--
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc
it-management Internet Services: Protéger
http://proteger.at [gesprochen: Prot-e-schee]
Tel: +43 660 / 415 6531
// ****** Radiointerview zum Thema Spam ******
// http://www.it-podcast.at/archiv.html#podcast-100716
//
// Haus zu verkaufen: http://zmi.at/langegg/
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-01-05 22:05 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-25 11:23 xfs: add FITRIM support Christoph Hellwig
2010-12-22 21:41 ` Alex Elder
2010-12-28 16:09 ` Christoph Hellwig
2011-01-03 10:49 ` Lukas Czerner
2010-12-23 1:44 ` Dave Chinner
2010-12-30 11:41 ` Christoph Hellwig
2011-01-03 10:57 ` Lukas Czerner
2011-01-03 23:25 ` Dave Chinner
2011-01-05 10:21 ` Lukas Czerner
2011-01-05 22:07 ` Michael Monnerie [this message]
2011-01-05 22:50 ` Dave Chinner
2011-01-06 8:10 ` Michael Monnerie
2011-01-06 8:33 ` Lukas Czerner
2011-01-06 8:40 ` Lukas Czerner
2011-01-06 9:17 ` Dave Chinner
2011-01-06 16:50 ` Michael Monnerie
2011-01-06 18:10 ` Christoph Hellwig
2011-01-06 18:08 ` Christoph Hellwig
2011-01-06 18:06 ` Christoph Hellwig
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=201101052307.38379@zmi.at \
--to=michael.monnerie@is.it-management.at \
--cc=hch@infradead.org \
--cc=lczerner@redhat.com \
--cc=xfs@oss.sgi.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