I'm noticing in the latest 2.6.28 pre-patches at kernel.org, ext4 has a call
to sb_issue_discard, but the call that was in David Woodhouse's ext2 branch
is gone. Will only ext4 support "discards" going forward?
Thanks,
Chris
On Wed, Oct 1, 2008 at 11:18 AM, Chris Worley <worleys at gmail.com>
wrote:
> On Mon, Sep 29, 2008 at 10:39 AM, Theodore Tso <tytso at mit.edu>
wrote:
> > On Mon, Sep 29, 2008 at 09:24:33AM -0600, Chris Worley wrote:
> >> On Tue, Sep 16, 2008 at 3:32 PM, Chris Worley <worleys at
gmail.com>
> wrote:
> >> > For example, in balloc.c I'm seeing ext3_free_blocks_sb
> >> > calls ext3_clear_bit_atomic at the bottom... is that when the
block is
> >> > freed? Are all blocks freed here?
> >>
> >> David Woodhouse, in an article at http://lwn.net/Articles/293658/,
is
> >> implementing the T10/T13 committees "Trim" request in
2.6.28 kernels.
> >>
> >> Would it be appropriate to call "blkdev_issue_discard"
at the bottom
> >> of ext3_free_blocks_sb where ext3_clear_bit_atomic is being
called?
> >
> > Unfortunately, it's not as simple as that. The problem is that as
> > soon as you call trim, the drive is allowed to discard the contents of
> > that block so that future attempts to read from that block returns all
> > zeros. Therefore we can't call Trim until after the transaction
has
> > committed. That means we have to keep a linked list of block extents
> > that are to be trimmed attached to the commit object, and only send
> > the trim requests once the commit block has been written to disk.
> >
> > It's on the ext4 developer's TODO list to add Trim support to
ext3 and
> > ext4.
>
> I was perusing David Woodhouse's 2.6.27-rc2 kernel at
> git://git.infradead.org/users/drzeus/discard-2.6.git, and noticed he
> has the discard built-in to where I was talking about for ext2... so I
> coded our driver to handle discards, and it works very nicely!!!
>
> The journaling issue you raise is not a show-stopper on the block
> device side: if the block device has to maintain a couple of blocks
> that are not really in use, it's no big deal (eventually the blocks
> will be re-written and the universe will be in order again)... for the
> users, I can understand if the discard is preserved on the block
> device, while the fs still thinks there's good data in there (we'll
> give you back all zeros on read).
>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://listman.redhat.com/archives/ext3-users/attachments/20081202/043bf45c/attachment.htm>