Re: Proposal to improve filesystem/block snapshot interaction

["Kyungmin Park" <kmpark@infradead.org>]

On 10/31/07, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 30 October 2007, Jörn Engel wrote:
> > On Tue, 30 October 2007 23:19:48 +0900, Dongjun Shin wrote:
> > > On 10/30/07, Arnd Bergmann <arnd@arndb.de> wrote:
> > > >
> > > > Not sure. Why shouldn't you be able to reorder the hints provided that
> > > > they don't overlap with read/write bios for the same block?
> > >
> > > You're right. The bios can be reordered if they don't overlap with hint.
> >
> > I would keep things simpler. Bios can be reordered, full stop. If an
> > erase and a write overlap, the caller (filesystem?) has to add a
> > barrier.
>
> I thought bios were already ordered if they affect the same blocks.
> Either way, I agree that an erase should not be treated special on
> the bio layer, its ordering should be handled the same way we do it
> for writes.
>

To support the new ATA command (trim, or dataset), the suggested hint
is not enough.
We have to send the bio with data (at least one sector or more) since
the new ATA command requests the dataset information.

And also we have to strictly follow the order using barrier or other
methods at filesystem level
For example, the delete operation in ext3.
1. delete some file
2. ext3_delete_inode() called
3. ... -> ext3_free_blocks_sb() releases the free blocks
4. If it sends the hints here, it breaks the ext3 power off recovery
scheme since it trims the data from given information after reboot
5. after transaction, all dirty pages are flushed. after this work, we
can trim the free blocks safely.

Another approach is modifying the block framework.
At  I/O scheduler, it don't merge the hint bio (in my terminology, bio
control info) with general bio. In this case we also consider the
reordering problem.
I'm not sure it is possible at this time.

Thank you,
Kyungmin Park
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html