From: Edward Shishkin <edward.shishkin@gmail.com>
To: ReiserFS development mailing list <reiserfs-devel@vger.kernel.org>
Subject: Reiser4: discard support with delayed issuing of discard requests
Date: Sun, 10 Aug 2014 01:00:01 +0200 [thread overview]
Message-ID: <53E6A7F1.6030006@gmail.com> (raw)
Hello everyone,
Ivan Shapovalov kindly implemented discard support for us.
Now SSD users can mount their reiser4 partitions with the option
"discard" and the file system will issue discard requests to inform
the device that blocks are not longer used.
In reiser4 issuing discard requests is a delayed action (like many
other actions including block allocation, compression, etc). It means
that discard requests are accumulated as the release of blocks and
issued as background process after issuing of all other usual
requests.
Such delayed technique allows to issue discard requests of better
quality, because the discard requests get merged in the process of
accumulation. Another advantage of the delayed discard is that the
"non-queued TRIM" is not a problem for us.
Implementation notes
Managing discard requests is a business of reiser4 transaction
manager. This is because blocks deallocation is a kind of events
which are tracked by the transaction manager. Deallocted extents
are captured by a respective transaction atom. At commit time all
the extents are sorted, merged and discarded right after overwriting
journalled blocks at their permanent location on disk. After issuing
the discard requests we complete the transaction by deallocating
respective blocks at working bitmap (which always resides in memory).
Thus, we guarantee consistency (nobody touches our extents before
discard completion). We don't record information about discard
extents in the journal. The worst thing that can happen after system
crash is missing a number of discard requests. It doesn't break
consistency of the file systems however. For such unpleasant
situations we'll provide support of FITRIM ioctl later.
Also in plans: garbage collection at the head and tail of every
extent to be discarded. The algorithms are complicated, however,
the game is worth the candle.
The patch against reiser4-for-3.15 can be found here:
http://sourceforge.net/projects/reiser4/files/patches/
WARNING: Don't use it for important data for now. Even in the case
of no visible problems, please, check your partition by fsck.reiser4
as frequently as possible. Report about found inconsistency.
Discard support in reiser4progs:
When formatting your SSD partition by mkfs.reiser4 use the option -d:
it will issue discard request for the whole partition before creating
reiser4 structure on it. This option is available in reiser4progs-1.0.9,
please find here:
http://sourceforge.net/projects/reiser4/files/reiser4-utils/reiser4progs
In order to build reiser4progs-1.0.9 you will need libaal-1.0.6,
please find here:
http://sourceforge.net/projects/reiser4/files/reiser4-utils/libaal
Thanks,
Edward.
next reply other threads:[~2014-08-09 23:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-09 23:00 Edward Shishkin [this message]
2014-08-10 15:02 ` Reiser4: discard support with delayed issuing of discard requests dimas
2014-08-10 15:38 ` Daniel Horne
2014-08-10 20:17 ` Edward Shishkin
2014-08-10 20:07 ` Edward Shishkin
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=53E6A7F1.6030006@gmail.com \
--to=edward.shishkin@gmail.com \
--cc=reiserfs-devel@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 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).