I'm noticing in the latest 2.6.28 pre-patches at <a href="http://kernel.org">kernel.org</a>, 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 <div class="gmail_quote">On Wed, Oct 1, 2008 at 11:18 AM, Chris Worley <<a href="mailto:worleys@gmail.com">worleys@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div><div></div><div class="Wj3C7c">On Mon, Sep 29, 2008 at 10:39 AM, Theodore Tso <<a href="mailto:tytso@mit.edu">tytso@mit.edu</a>> 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 <<a href="mailto:worleys@gmail.com">worleys@gmail.com</a>> 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 <a href="http://lwn.net/Articles/293658/" target="_blank">http://lwn.net/Articles/293658/</a>, 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. </div></div>I was perusing David Woodhouse's 2.6.27-rc2 kernel at git://<a href="http://git.infradead.org/users/drzeus/discard-2.6.git" target="_blank">git.infradead.org/users/drzeus/discard-2.6.git</a>, 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 </blockquote></div>