On Wed, Sep 06, 2017 at 03:19:37PM +0200, Christoph Hellwig wrote: > > You could also say that flush sequence counting code doesn't belong > > to xfs code at all. There is nothing xfs specific about it. > > > > If we had an API: > > > > flush_seq = blkdev_get_flush_seq(bdev, flush_seq); > > blkdev_issue_flush_after(bdev, flush_seq); > > > > I am sure it would have been useful to more fs. > > > > In fact, block drivers that use blk_insert_flush(), > > already have serialized flush requests, so implementing > > the above functionality would be quite trivial for those. > > > > I am not fluent enough in block layer to say if this makes sense. > > Christoph? Should we add some block people to this discussion? > > Not that the interface can't be based on blkdev_issue_flush as > our most important flushes are submitted asynchronously. > > But except for that tying into the flush state machine sounds > very interesting. Let me look into that as the designate > xfs <-> block layer liaison.
That sounds like a nice idea to me, particularly if there is potential for other users. I'll wait to look into doing anything in XFS until we see how this turns out. Thanks. Brian > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
