Re: compound fop design first cut

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 
> 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@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux