On Tue, 10 Nov 2009 15:46:27 -0500, Jeff Garzik <jeff@xxxxxxxxxx> wrote: > Now the world has figured out giving a storage device the flexibility to > manage data on a per-object granular basis simplifies applications, and > gives underlying storage more ability to optimize. This is a sleught of hand by OSD vendors, interested in selling for more dollars per gigabyte. > Thus, moving to generic key/value storage actually simplified > applications, by eliminating that mapping. You're so sure about this, I wonder where it comes from. The fact in case of tabled is, it must maintain a database of keys of its own, primarily because (a) it cannot afford round-trips into Chunk for every operation, and (b) to locate the chunks. Both of these databases may be in RAM, but it does not make them non-existing. > However, one glaring difference from SCSI OSD was chunkd's lack of > administrative partitions. SCSI OSDs provide "partitions" within each > logical unit (LUN), each of contains a set of objects within a single > object id namespace. Therefore, if you consider SCSI OSD object id as > the key, then SCSI OSD definitely has multiple key/value tables. This is a completely bogus analogy. OSD vendors want to push their wares into PC space, where one unit is all a computer has. But in the cloud we have thousands of Chunk nodes per each application. That is your partitioning right there: it's called <Cell></Cell>. Look, I would not mind if all this partition stuff was free, but it's not. You decided to embed a partition into a session, so - There's a round trip that you excuse by telling applications to keep long-living connections, thanks a lot - requests to different partitions cannot be pipelined (well, not easily). -- Pete -- To unsubscribe from this list: send the line "unsubscribe hail-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
