From: Mark Lord <kernel@teksavvy.com>
To: Greg Freemyer <greg.freemyer@gmail.com>
Cc: Lukas Czerner <lczerner@redhat.com>,
linux-ext4@vger.kernel.org, Jeff Moyer <jmoyer@redhat.com>,
Edward Shishkin <eshishki@redhat.com>,
Eric Sandeen <esandeen@redhat.com>,
Ric Wheeler <rwheeler@redhat.com>, Mark Lord <liml@rtr.ca>
Subject: Re: Ext4: batched discard support
Date: Tue, 20 Apr 2010 16:24:43 -0400 [thread overview]
Message-ID: <4BCE0D8B.5020306@teksavvy.com> (raw)
In-Reply-To: <h2o87f94c371004190920h5e793818x4113da75dd21da8b@mail.gmail.com>
On 19/04/10 12:20 PM, Greg Freemyer wrote:
> Adding Mark Lord in cc.
..
> On Mon, Apr 19, 2010 at 6:55 AM, Lukas Czerner<lczerner@redhat.com> wrote:
..
>> The basic idea behind my discard support is to create an ioctl which
>> walks through all the free extents in each allocating group and discard
>> those extents. As an addition to improve its performance one can specify
>> minimum free extent length, so ioctl will not bother with shorter extents.
..
Perfect. I proposed exactly this last year, but never found time to work it further.
Please proceed with it!
..
>> But you may notice, that there is one problem. bb_bitmap_deleted does
>> not survive umount. To bypass the problem the first ioctl call have to
>> walk through whole file system trimming all free extents. But there is a
>> better solution to this problem. The bb_bitmap_deleted can be stored on
>> disk an can be restored in mount time along with other bitmaps, but I
>> think it is a quite big change and should be discussed further.
..
That's not necessary. It is a simple matter to TRIM a clean filesystem
before it is mounted R/W during the boot sequence. No new information
is required for that operation.
My wiper.sh script already shows walking the freelists and trimming all
available space, something which takes only a couple of seconds on a 120GB
filesystem that has not been kept up-to-date with on-the-fly trim.
Cheers
next prev parent reply other threads:[~2010-04-20 20:24 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-19 10:55 Ext4: batched discard support Lukas Czerner
2010-04-19 10:55 ` [PATCH 1/2] Add ioctl FITRIM Lukas Czerner
2010-04-19 10:55 ` [PATCH 2/2] Add batched discard support for ext4 Lukas Czerner
2010-04-20 21:21 ` Greg Freemyer
2010-04-21 2:26 ` Mark Lord
2010-04-21 2:45 ` Eric Sandeen
2010-04-21 18:59 ` Greg Freemyer
2010-04-21 19:04 ` Ric Wheeler
2010-04-21 19:22 ` Jeff Moyer
2010-04-21 20:44 ` Greg Freemyer
2010-04-21 20:53 ` Greg Freemyer
2010-04-21 21:01 ` Eric Sandeen
2010-04-21 21:03 ` Ric Wheeler
2010-04-21 21:47 ` Greg Freemyer
2010-04-21 21:56 ` James Bottomley
2010-04-21 21:59 ` Mark Lord
2010-04-23 8:23 ` Lukas Czerner
2010-04-24 13:24 ` Greg Freemyer
2010-04-24 13:48 ` Ric Wheeler
2010-04-24 14:30 ` Greg Freemyer
2010-04-24 14:43 ` Eric Sandeen
2010-04-24 15:03 ` Greg Freemyer
2010-04-24 17:04 ` Ric Wheeler
2010-04-24 18:30 ` Greg Freemyer
2010-04-24 18:41 ` Ric Wheeler
2010-04-26 14:00 ` Mark Lord
2010-04-26 14:42 ` Martin K. Petersen
2010-04-26 15:27 ` Greg Freemyer
2010-04-26 15:51 ` Lukas Czerner
2010-04-28 1:25 ` Mark Lord
2010-04-26 15:48 ` Ric Wheeler
2010-04-24 19:06 ` Martin K. Petersen
2010-04-26 14:03 ` Mark Lord
2010-04-24 18:39 ` Martin K. Petersen
2010-04-26 16:55 ` Jan Kara
2010-04-26 17:46 ` Lukas Czerner
2010-04-26 17:52 ` Ric Wheeler
2010-04-26 18:14 ` Lukas Czerner
2010-04-26 18:28 ` Jeff Moyer
2010-04-26 18:38 ` [PATCH 2/2] Add batched discard support for ext4 - using rbtree Lukas Czerner
2010-04-26 18:42 ` Lukas Czerner
2010-04-27 15:29 ` Edward Shishkin
2010-04-21 20:52 ` [PATCH 2/2] Add batched discard support for ext4 Greg Freemyer
2010-04-19 16:20 ` Ext4: batched discard support Greg Freemyer
2010-04-19 16:30 ` Eric Sandeen
2010-04-19 17:58 ` Greg Freemyer
2010-04-19 18:04 ` Ric Wheeler
2010-04-20 20:24 ` Mark Lord [this message]
2010-04-20 20:34 ` Mark Lord
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=4BCE0D8B.5020306@teksavvy.com \
--to=kernel@teksavvy.com \
--cc=esandeen@redhat.com \
--cc=eshishki@redhat.com \
--cc=greg.freemyer@gmail.com \
--cc=jmoyer@redhat.com \
--cc=lczerner@redhat.com \
--cc=liml@rtr.ca \
--cc=linux-ext4@vger.kernel.org \
--cc=rwheeler@redhat.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 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.