On Tue, 2008-08-12 at 11:14 +0200, Jens Axboe wrote: > On Sat, Aug 09 2008, David Woodhouse wrote: > > This time on top of the for-2.6.28 branch of > > git://git.kernel.dk/linux-2.6-block.git > > > > I've made it cope with merging and sorting discard requests, still as a > > separate patch at the end of the sequence. I don't think we have a > > problem with discards passing writes in the queue, any more than we > > _already_ had a problem with writes passing writes. > > But we don't already have this problem, that is the point. For page > cache writes, the page cache nicely solves this issue for us - a write > that comes in later gets to wait on the page lock before proceeding. So > at least it's ordered. For O_DIRECT, the issuer is on his own. > > I think this is a serious problem and that we must ensure that an > overlapping write doesn't pass a previously issued discard request. So > in that sense, discards must be considered soft barriers. OK, that makes sense. Enabling merges is now the last commit in git.infradead.org/users/dwmw2/discard-2.6.git so we can easily drop it for now. Now that I've updated the FAT code to merge discard requests for contiguous chains, it's not a massive issue. I'd still quite like to make it work though -- file systems that care can always use explicit barriers to ensure that the DISCARD requests are handled before any subsequent reallocation and write to the same sectors. If we want to allow that option for those who submit bios directly, is it sufficient to set BIO_RW_SYNC to the flags in blkdev_issue_discard, or do we really need REQ_SOFTBARRIER? There doesn't seem to be a way to indicate that in ->bi_rw. -- David Woodhouse Open Source Technology Centre David.Woodhouse@xxxxxxxxx Intel Corporation -- 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
