On 10/31/07, Arnd Bergmann <arnd@xxxxxxxx> 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@xxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
