When is a block free?
 

Where in the ext2/3 code does it know that a block on the disk is now free to reuse?
Thanks,
Chris
_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

When is a block free?
 

Chris Worley wrote:
Where in the ext2/3 code does it know that a block on the disk is now
free to reuse?


Thanks,

Chris

Hi Chris,

File systems track which blocks are free from the file system creation
time (mkfs), creation of new files and deletion. Ext2/3 is the
gatekeeper for all deletions, so it knows when file system blocks
transition from the used state to the free state. Ext file system use
bitmaps to track the blocks that are allocated or not.


Regards,

Ric

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

When is a block free?
 

On Tue, Sep 16, 2008 at 3:32 PM, Chris Worley <worleys@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?

Chris
>
> On Tue, Sep 16, 2008 at 3:03 PM, Chris Worley <worleys@gmail.com> wrote:
>>
>> On Tue, Sep 16, 2008 at 2:17 PM, Ric Wheeler <rwheeler@redhat.com> wrote:
>>>
>>> Chris Worley wrote:
>>>>
>>>> Where in the ext2/3 code does it know that a block on the disk is now
>>>> free to reuse?
>>>>
>>>> Thanks,
>>>>
>>>> Chris
>>>
>>> Hi Chris,
>>>
>>> File systems track which blocks are free from the file system creation
>>> time (mkfs), creation of new files and deletion. Ext2/3 is the gatekeeper
>>> for all deletions, so it knows when file system blocks transition from the
>>> used state to the free state. Ext file system use bitmaps to track the
>>> blocks that are allocated or not.
>>
>> Where (in the code... what routine... or what's the name of the bitmap) is
>> the "free" bit set? I've been looking through the code and don't see
>> exactly where the block is marked as free.
>> Thanks,
>> Chris
>>>
>>> Regards,
>>>
>>> Ric
>>>
>>
>
>

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

When is a block free?
 

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@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.

- Ted

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

When is a block free?
 

On Mon, Sep 29, 2008 at 10:39 AM, Theodore Tso <tytso@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@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

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

When is a block free?
 

On Wed, Oct 01, 2008 at 12:18:21PM -0600, Chris Worley wrote:
>
> 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!!!

I'm not sure what you mean by "our driver"?

> 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).

It's no issue on the block device side at all, but from the user's
point of view it can be quite disastrous. Consider the following
shell script:

cp /etc/passwd /etc/passwd.vipw
vi /etc/passwd.vipw
<sanity check /etc/passwd.vipw for correctness>
# atomically update /etc/passwd
mv /etc/passwd.vipw /etc/passwd

Now assume that we crash right after the "mv" command, but before the
transaction has committed. The net result will be that the contents
of the /etc/passwd file will be all zeros, which some might
consider.... unfortuate.

This is exactly the same issue for why we can't just zero data blocks
on the unlink command, but instead have to wait until the unlink
operation has actually been committed in the journal.

- Ted

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

When is a block free?
 

On Wed, Oct 1, 2008 at 12:59 PM, Theodore Tso <tytso@mit.edu> wrote:
> On Wed, Oct 01, 2008 at 12:18:21PM -0600, Chris Worley wrote:
>>
>> 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!!!
>
> I'm not sure what you mean by "our driver"?

Our driver for the ioDrive:

http://fusionio.com/Products.aspx

So far, all I've implemented is the "discard" in the read/write
callback; no barrier, no ioctl.

>
>> 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).
>
> It's no issue on the block device side at all, but from the user's
> point of view it can be quite disastrous.
<snip>

Maybe that should effect the priority of implementation for ext[34]?

Chris

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

When is a block free?
 

On Wed, Oct 01, 2008 at 01:46:00PM -0600, Chris Worley wrote:
>
> Maybe that should effect the priority of implementation for ext[34]?
>

It's on our todo list, but at the moment you can't even *get* SSD's
that have the trim command, apparently for love or money. So that
affects the priority as well. If someone wants to ship me an SSD that
has trim support, ideally in a 2.5" 9mm hard drive SATA form factor
with at least 128gigs, I promise you that would affect priority of
that feature, at least for me. :-)

- Ted

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

When is a block free?
 

On Thu, Oct 2, 2008 at 2:59 AM, Theodore Tso <tytso@mit.edu> wrote:


On Wed, Oct 01, 2008 at 01:46:00PM -0600, Chris Worley wrote:

>

> Maybe that should effect the priority of implementation for ext[34]?

>




also i am inferring correctly* that the SAN array vendors who are now implementing thin provisioning i.e. allocate space on writes can benefit from this ? now that the array can know which blocks are free and update its own list of free blocks?*



_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

When is a block free?
 

On Wed, Oct 1, 2008 at 11:36 PM, Balu manyam <balu.manyam@gmail.com> wrote:
>
>
> On Thu, Oct 2, 2008 at 2:59 AM, Theodore Tso <tytso@mit.edu> wrote:
>>
>> On Wed, Oct 01, 2008 at 01:46:00PM -0600, Chris Worley wrote:
>> >
>> > Maybe that should effect the priority of implementation for ext[34]?
>> >
>>
>
> also i am inferring correctly that the SAN array vendors who are now
> implementing thin provisioning i.e. allocate space on writes can benefit
> from this ?

Absolutely.

Chris
> now that the array can know which blocks are free and update its
> own list of free blocks?
>

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users