When is a block free?

[Chris Worley]

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