All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Lord <liml@rtr.ca>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
	jens.axboe@oracle.com
Subject: Re: [PATCH, RFC] xfs: batched discard support
Date: Sat, 15 Aug 2009 21:35:17 -0400	[thread overview]
Message-ID: <4A876255.10606@rtr.ca> (raw)
In-Reply-To: <20090816004705.GA7347@infradead.org>

Christoph Hellwig wrote:
> Given that everyone is so big in the discard discussion I'd like to
> present what I had started to prepare for XFS.  I didn't plan to send it
> out until I get my hands onto a TRIM capable device (or at least get
> time to add support to qemu), and so far it's only been tested in
> dry-run mode.
> 
> The basic idea is to add an ioctl which walks the free space btrees in
> each allocation group and simply discard everythin that is free.  Given
> that XFS doesn't gragment freespace very much that's a very efficient
> way to do it.  In addition we also already support setting a threshold
> under which we don't bother to discard an extent, it's currently
> hardcoded in the helper tool.  In the future we could also add things
> like a sequence number in the AG headers if anything has changed at all,
> but let's leave those optimizations until we need them.
> 
> XFS locks the allocation btree using the btree buffers, so we do not
> block allocations from any extent which we're not currenly discarding.
> 
> Now the caveat for that is that we really do want to do the discard
> synchronously, that is wait for the request to finish.  That's what
> I've implemented in this patch, but it's the part I haven't been
> able to test so far.  (and yes, this should be separate patch, but it's
> really just an RFC for now)
> 
> Mark, any chance to try it?  Just create an XFS filesystem, age it a
> bit and then call the attached little trim.c program on the mountmoint
> (or any file inside the filesystem for that matter)
..

Looking at it now.  Thanks, Christoph!

WARNING: multiple messages have this Message-ID (diff)
From: Mark Lord <liml@rtr.ca>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-fsdevel@vger.kernel.org, jens.axboe@oracle.com,
	linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
	xfs@oss.sgi.com
Subject: Re: [PATCH, RFC] xfs: batched discard support
Date: Sat, 15 Aug 2009 21:35:17 -0400	[thread overview]
Message-ID: <4A876255.10606@rtr.ca> (raw)
In-Reply-To: <20090816004705.GA7347@infradead.org>

Christoph Hellwig wrote:
> Given that everyone is so big in the discard discussion I'd like to
> present what I had started to prepare for XFS.  I didn't plan to send it
> out until I get my hands onto a TRIM capable device (or at least get
> time to add support to qemu), and so far it's only been tested in
> dry-run mode.
> 
> The basic idea is to add an ioctl which walks the free space btrees in
> each allocation group and simply discard everythin that is free.  Given
> that XFS doesn't gragment freespace very much that's a very efficient
> way to do it.  In addition we also already support setting a threshold
> under which we don't bother to discard an extent, it's currently
> hardcoded in the helper tool.  In the future we could also add things
> like a sequence number in the AG headers if anything has changed at all,
> but let's leave those optimizations until we need them.
> 
> XFS locks the allocation btree using the btree buffers, so we do not
> block allocations from any extent which we're not currenly discarding.
> 
> Now the caveat for that is that we really do want to do the discard
> synchronously, that is wait for the request to finish.  That's what
> I've implemented in this patch, but it's the part I haven't been
> able to test so far.  (and yes, this should be separate patch, but it's
> really just an RFC for now)
> 
> Mark, any chance to try it?  Just create an XFS filesystem, age it a
> bit and then call the attached little trim.c program on the mountmoint
> (or any file inside the filesystem for that matter)
..

Looking at it now.  Thanks, Christoph!

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2009-08-16  1:35 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-16  0:47 [PATCH, RFC] xfs: batched discard support Christoph Hellwig
2009-08-16  0:47 ` Christoph Hellwig
2009-08-16  1:35 ` Mark Lord [this message]
2009-08-16  1:35   ` Mark Lord
2009-08-16  2:19   ` Mark Lord
2009-08-16  2:19     ` Mark Lord
2009-08-16  2:25     ` Christoph Hellwig
2009-08-16  2:25       ` Christoph Hellwig
2009-08-16  2:49       ` Mark Lord
2009-08-16  2:49         ` Mark Lord
2009-08-16  3:25         ` Mark Lord
2009-08-16  3:25           ` Mark Lord
2009-08-16 13:00       ` Mark Lord
2009-08-16 13:00         ` Mark Lord
2009-08-16 13:53         ` Christoph Hellwig
2009-08-16 13:53           ` Christoph Hellwig
2009-08-16 13:59         ` Mark Lord
2009-08-16 13:59           ` Mark Lord
2009-08-16 14:06           ` Mark Lord
2009-08-16 14:06             ` Mark Lord
2009-08-16 14:23           ` Christoph Hellwig
2009-08-16 14:23             ` Christoph Hellwig
2009-08-16 14:26             ` Mark Lord
2009-08-16 14:26               ` Mark Lord
2009-08-19 20:39 ` Ingo Molnar
2009-08-19 20:39   ` Ingo Molnar
2009-08-20  1:05   ` Christoph Hellwig
2009-08-20  1:05     ` Christoph Hellwig
2009-08-20  1:10     ` Jamie Lokier
2009-08-20  1:10       ` Jamie Lokier
2009-08-20  1:38       ` Douglas Gilbert
2009-08-20  1:38         ` Douglas Gilbert
2009-08-20  1:38       ` Mark Lord
2009-08-20  1:38         ` Mark Lord
2009-08-21 12:46     ` Ingo Molnar
2009-08-21 12:46       ` Ingo Molnar
2009-08-21 18:18       ` ioctls vs syscalls once again Christoph Hellwig
2009-08-21 20:35         ` Ingo Molnar
2009-08-20  1:39   ` [PATCH, RFC] xfs: batched discard support Mark Lord
2009-08-20  1:39     ` Mark Lord
2009-08-20 13:48     ` Ric Wheeler
2009-08-20 14:38       ` Mark Lord
2009-08-20 14:38         ` Mark Lord
2009-08-20 14:42         ` Ric Wheeler
2009-08-20 14:42           ` Ric Wheeler
2009-08-20 17:19           ` Greg Freemyer
2009-08-20 17:19             ` Greg Freemyer
2009-08-20 14:42         ` James Bottomley
2009-08-20 14:42           ` James Bottomley
2009-08-20 15:43         ` Rolf Eike Beer
2009-08-20 15:43           ` Rolf Eike Beer
2009-08-20 17:00           ` Ric Wheeler
2009-08-20 17:00             ` Ric Wheeler
2009-08-20 14:58       ` Douglas Gilbert
2009-08-20 14:58         ` Douglas Gilbert

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=4A876255.10606@rtr.ca \
    --to=liml@rtr.ca \
    --cc=hch@infradead.org \
    --cc=jens.axboe@oracle.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --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 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.