[Gluster-devel] compound fop design first cut
Pranith Kumar Karampuri
pkarampu at redhat.com
Wed Dec 9 05:52:36 UTC 2015
On 12/09/2015 10:39 AM, Prashanth Pai wrote:
>> 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()
Krutika implemented fstat+fgetxattr(http://review.gluster.org/10180). In
posix there is an implementation of GF_CONTENT_KEY which is used to read
a file in lookup by quick-read. This needs to be exposed for fds as well
I think. So you can do all this using fstat on anon-fd.
> HEAD: stat(), getxattr()s
Krutika already implemented this for sharding
http://review.gluster.org/10158. You can do this using stat fop.
> PUT: creat(), write()s, setxattr(), fsync(), close(), rename()
This I think should be a new compound fop. Nothing similar exists.
> DELETE: getxattr(), unlink()
This can also be clubbed in unlink already because xdata exists on the
> Compounding some of these ops and exposing them as consumable libgfapi APIs like glfs_get() and glfs_put() similar to librados compound APIs would greatly improve performance for object based access.
> : https://github.com/ceph/ceph/blob/master/src/include/rados/librados.h#L2219
> - Prashanth Pai
More information about the Gluster-devel