From: Dave Chinner <david@fromorbit.com>
To: Lukas Czerner <lczerner@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, tytso@mit.edu, sandeen@redhat.com,
adilger@dilger.ca
Subject: Re: [PATCH 0/1] Batched discard support
Date: Thu, 30 Sep 2010 10:55:35 +1000 [thread overview]
Message-ID: <20100930005535.GV5665@dastard> (raw)
In-Reply-To: <1285750466-3579-1-git-send-email-lczerner@redhat.com>
On Wed, Sep 29, 2010 at 10:54:25AM +0200, Lukas Czerner wrote:
> Hi,
>
> I am working on something I have called "batched discard support" for Ext3
> and Ext4 filesystems. Traditional discard support for filesystems like Ext4
> has been implemented the way that whenever the file is unlinked the
> disk-space that the file was using is trimmed (discarded) by
> sb_issue_discard() to let the device know that this portion of disk is no
> longer in use by the filesystem and can be safely used for wear-leveling.
>
> However, this approach comes with very noticeable performance loss on most
> of SSD devices and LUN's I have the opportunity to test it on. The fact is,
> that bigger discard ranges are more efficient than smaller ones, so it make
> sense try to batch the ranges together wherever it is possible.
>
> I have introduced new filesystem independent ioctl (FITRIM) which can be used
> to send the "trim this portion of filesystem" command down to the filesystem
> which (if implemented) discards all free extents in that range.
>
> The implementation for Ext3 and Ext4 is complete and you can see it here:
>
> http://www.spinics.net/lists/linux-ext4/msg21050.html
>
> Why I am sending it here to linux-fsdevel is because I am introducing new fs
> independent ioctl and new member of super_operations (trim_fs) and we would
> like let you know about this approach (which any filesystem can take
> advantage from) and we would like your comment on this patch before we
> send it upstream.
My first question is: how do you test a filesystem implements
->trim_fs correctly?
That is, if we are going to include a data-destroying ioctl, I
really want some filesystem independent tests written first so that
as filesystems implement ->trim_fs they can be tested for correct
implementation.
Perhaps adding FITRIM support to xfs_io, and a generic test to
xfstests would be the way to go. e.g. write a set of patterned files
to the filesystem, unlink a number of the files, then run some trim
commands on the filesystem exercising corner cases and check that
none of the data in still-active files is damaged (e.g. via md5sum
comparison)....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2010-09-30 0:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-29 8:54 [PATCH 0/1] Batched discard support Lukas Czerner
2010-09-29 8:54 ` [PATCH] Add ioctl FITRIM Lukas Czerner
2010-09-30 0:55 ` Dave Chinner [this message]
2010-09-30 12:17 ` [PATCH 0/1] Batched discard support Lukas Czerner
2010-09-30 16:11 ` Eric Sandeen
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=20100930005535.GV5665@dastard \
--to=david@fromorbit.com \
--cc=adilger@dilger.ca \
--cc=lczerner@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=sandeen@redhat.com \
--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.