> However, I’d be even more comfortable with an even simpler approach that > avoids the need to solve what the database folks (who have dealt with > complex transactions for years) would tell us is a really hard problem. > Instead of designing for every case we can imagine, let’s design for the > cases that we know would be useful for improving performance. Open plus > read/write plus close is an obvious one. Raghavendra mentions > create+inodelk as well.
From object interface (Swift/S3) perspective, this is the fop order and flow for object operations: GET: open(), fstat(), fgetxattr()s, read()s, close() HEAD: stat(), getxattr()s PUT: creat(), write()s, setxattr(), fsync(), close(), rename() DELETE: getxattr(), unlink() Compounding some of these ops and exposing them as consumable libgfapi APIs like glfs_get() and glfs_put() similar to librados compound APIs[1] would greatly improve performance for object based access. [1]: https://github.com/ceph/ceph/blob/master/src/include/rados/librados.h#L2219 Thanks. - Prashanth Pai _______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
