Chris Mason wrote:
Quoting Matthew Wilcox (2013-11-12 10:11:51)
I took a look at the SCSI Block Command spec. If I understand it
correctly, SCSI would implement this with the WRITE USING TOKEN command.
I don't see why it couldn't implement this API, though it seems like
SCSI would prefer a separate setup step before the write comes in. I'm
not sure that's a reasonable request to make of the application (nor
am I sure I understand SBC correctly).
What kind of setup would we have to do? We have all the IO in hand, so
it can be organized in just about any way needed.
I like the API, but I'm a little confused not to see a patch saying "Oh,
and here's how we implemented it in btrfs without any hardware support"
;-) It seems to me that the concept is just as good a match for an
advanced filesystem that supports snapshots as it is for the FTL inside
a drive.
Grin, almost Btrfs already does this...COW means that btrfs needs to
update metadata to point to new locations. To avoid an ugly
flush-all-the-io-every-commit mess, we track pending writes and update
the meatadata when the write is fully on media.
We're missing a firm line that makes sure all the metadata updates for a
single write happen in the same transaction, but that part isn't hard.
We're missing good performance in database workloads, which is a
slightly bigger trick.
This is precisely why this is needed:
http://www.spinics.net/lists/linux-fsdevel/msg70047.html
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--
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