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@xxxxxxxxx> 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. - Ted _______________________________________________ Ext3-users mailing list Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
