summaryrefslogtreecommitdiffstats
path: root/glusterfs-api.pc.in
Commit message (Collapse)AuthorAgeFilesLines
* copy_file_range support in GlusterFSRaghavendra Bhat2018-12-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * libglusterfs changes to add new fop * Fuse changes: - Changes in fuse bridge xlator to receive and send responses * posix changes to perform the op on the backend filesystem * protocol and rpc changes for sending and receiving the fop * gfapi changes for performing the fop * tools: glfs-copy-file-range tool for testing copy_file_range fop - Although, copy_file_range support has been added to the upstream fuse kernel module, no release has been made yet of a kernel which contains the support. It is expected to come in the upcoming release of linux-4.20 So, as of now, executing copy_file_range fop on a fused based filesystem results in fuse kernel module sending read on the source fd and write on the destination fd. Therefore a small gfapi based tool has been written to be able test the copy_file_range fop. This tool is similar (in functionality) to the example program given in copy_file_range man page. So, running regular copy_file_range on a fuse mount point and running gfapi based glfs-copy-file-range tool gives some idea about how fast, the copy_file_range (or reflink) can be. On the local machine this was the result obtained. mount -t glusterfs workstation:new /mnt/glusterfs [root@workstation ~]# cd /mnt/glusterfs/ [root@workstation glusterfs]# ls file [root@workstation glusterfs]# cd [root@workstation ~]# time /tmp/a.out /mnt/glusterfs/file /mnt/glusterfs/new real 0m6.495s user 0m0.000s sys 0m1.439s [root@workstation ~]# time glfs-copy-file-range $(hostname) new /tmp/glfs.log /file /rrr OPEN_SRC: opening /file is success OPEN_DST: opening /rrr is success FSTAT_SRC: fstat on /rrr is success copy_file_range successful real 0m0.309s user 0m0.039s sys 0m0.017s This tool needs following arguments 1) hostname 2) volume name 3) log file path 4) source file path (relative to the gluster volume root) 5) destination file path (relative to the gluster volume root) "glfs-copy-file-range <hostname> <volume> <log file path> <source> <destination>" - Added a testcase as well to run glfs-copy-file-range tool * io-stats changes to capture the fop for profiling * NOTE: - Added conditional check to see whether the copy_file_range syscall is available or not. If not, then return ENOSYS. - Added conditional check for kernel minor version in fuse_kernel.h and fuse-bridge while referring to copy_file_range. And the kernel minor version is kept as it is. i.e. 24. Increment it in future when there is a kernel release which contains the support for copy_file_range fop in fuse kernel module. * The document which contains a writeup on this enhancement can be found at https://docs.google.com/document/d/1BSILbXr_knynNwxSyyu503JoTz5QFM_4suNIh2WwrSc/edit Change-Id: I280069c814dd21ce6ec3be00a884fc24ab692367 updates: #536 Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com>
* *.pc: Fix include path in CflagsAndrea Bolognani2017-11-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The include path in glusterfs-api.pc looks like -I${includedir}/glusterfs However, client code will include the glusterfs headers using #include <glusterfs/api/glfs.h> rather than #include <api/glfs.h> which makes the "/glusterfs" part entirely unnecessary. More importantly, on some platforms such as FreeBSD, the header files for glusterfs will be installed in /usr/local/include, which is *not* part of the compiler's default include path, so compilation will fail with something like fatal error: 'glusterfs/api/glfs.h' file not found #include <glusterfs/api/glfs.h> ^~~~~~~~~~~~~~~~~~~~~~ The fix is to simply drop the extra "/glusterfs". The same change is applied to other *.pc files as well, althought I haven't actually tested those. A test program (gfapi-load-volfile) and the glfsxmp example application were using the wrong include paths, so they had to be fixed as well. Change-Id: I9a16de47fee7ab9c12d1cb823bbe061a69352670 BUG: 1508947 Signed-off-by: Andrea Bolognani <abologna@redhat.com>
* build: make contrib/uuid dependency optionalNiels de Vos2015-04-101-0/+1
| | | | | | | | | | | | | | | | | | | On Linux systems we should use the libuuid from the distribution and not bundle and statically link the contrib/uuid/ bits. libglusterfs/src/compat-uuid.h has been introduced and should become an abstraction layer for different UUID APIs. Non-Linux operating systems should implement their compatibility layer there. Once all operating systems have an implementation in compat-uuid.h, we can remove contrib/uuid/ from the repository completely. Change-Id: I345e5357644be2521685e00358bb8c83c4ea0577 BUG: 1206587 Signed-off-by: Niels de Vos <ndevos@redhat.com> Reviewed-on: http://review.gluster.org/10129 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Vijay Bellur <vbellur@redhat.com>
* gfapi: add glfs_h_acl_set() and glfs_h_acl_get()Niels de Vos2015-03-181-2/+2
| | | | | | | | | | | | | | | | | | | | | These two functions add support for POSIX ACLs through the GFAPI-handle interface. The initial infrastructure for POSIX ACLs based on libacl has been added with the required changes to the POSIX xlator: - http://review.gluster.org/9627 NetBSD does not support POSIX ACLs, so using any of the functions should return ENOTSUP. URL: http://www.gluster.org/community/documentation/index.php/Features/Improved_POSIX_ACLs Change-Id: Ie74f3f963c3f9d576cb2f2a1e6d97e3cd4b01eda BUG: 1185654 Signed-off-by: Niels de Vos <ndevos@redhat.com> Reviewed-on: http://review.gluster.org/9736 Reviewed-by: Kaleb KEITHLEY <kkeithle@redhat.com> Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Vijay Bellur <vbellur@redhat.com>
* build: Start using library versioning for various librariesHarshavardhana2014-01-181-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to libtool three individual numbers stand for CURRENT:REVISION:AGE, or C:R:A for short. The libtool script typically tacks these three numbers onto the end of the name of the .so file it creates. The formula for calculating the file numbers on Linux and Solaris is /path/to/library/<library_name>.(C - A).(A).(R) As you release new versions of your library, you will update the library's C:R:A. Although the rules for changing these version numbers can quickly become confusing, a few simple tips should help keep you on track. The libtool documentation goes into greater depth. In essence, every time you make a change to the library and release it, the C:R:A should change. A new library should start with 0:0:0. Each time you change the public interface (i.e., your installed header files), you should increment the CURRENT number. This is called your interface number. The main use of this interface number is to tag successive revisions of your API. The AGE number is how many consecutive versions of the API the current implementation supports. Thus if the CURRENT library API is the sixth published version of the interface and it is also binary compatible with the fourth and fifth versions (i.e., the last two), the C:R:A might be 6:0:2. When you break binary compatibility, you need to set AGE to 0 and of course increment CURRENT. The REVISION marks a change in the source code of the library that doesn't affect the interface-for example, a minor bug fix. Anytime you increment CURRENT, you should set REVISION back to 0. Change-Id: Id72e74c1642c804fea6f93ec109135c7c16f1810 BUG: 862082 Signed-off-by: Harshavardhana <harsha@harshavardhana.net> Reviewed-on: http://review.gluster.org/5645 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Niels de Vos <ndevos@redhat.com> Reviewed-by: Vijay Bellur <vbellur@redhat.com>
* zerofill: Update API versionM. Mohan Kumar2013-11-121-1/+1
| | | | | | | | | | | | version 6 adds zerofill FOP BUG: 1028673 Change-Id: I27cfc48cd6f7f0f6daf94e1c9cfbe420a0d090af Signed-off-by: M. Mohan Kumar <mohan@in.ibm.com> Reviewed-on: http://review.gluster.org/6255 Reviewed-by: Bharata B Rao <bharata.rao@gmail.com> Tested-by: Bharata B Rao <bharata.rao@gmail.com> Reviewed-by: Anand Avati <avati@redhat.com>
* api: glusterfs-api.pc.in (and libgfchangelog.pc.in) use rpath (-Wl,-R...)Kaleb S. KEITHLEY2013-08-281-1/+1
| | | | | | | | | Change-Id: Icdd23f1c31421c882db106cdad1b1406569594ca BUG: 1002220 Signed-off-by: Kaleb S. KEITHLEY <kkeithle@redhat.com> Reviewed-on: http://review.gluster.org/5717 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Anand Avati <avati@redhat.com>
* api: Bump version to 5.Vijay Bellur2013-07-041-1/+1
| | | | | | | | | | | version 5 adds support for fallocate & discard. Change-Id: Ifdc226953a25e4a4eb63e55d2a7c7ec77c397215 BUG: 953694 Signed-off-by: Vijay Bellur <vbellur@redhat.com> Reviewed-on: http://review.gluster.org/5276 Reviewed-by: Bharata B Rao <bharata.rao@gmail.com> Tested-by: Gluster Build System <jenkins@build.gluster.com>
* pkg-config: present API version and not package versionAnand Avati2013-05-251-1/+2
| | | | | | | | | | | | | | | | | | | This way PKG_MODULE() autoconf test checks for required API rather than release version (e.g required API could be in all all of 3.4.5, 3.5.1, 3.6.4 etc.) With the first "release" of gfapi, the current version (4) will be frozen. Version 3 is sufficient for QEMU's requirement. Version 4 is necessary for Samba VFS Change-Id: Iada3a4c88b9c67413dcd57004fd8a62926a21b42 BUG: 953694 Signed-off-by: Anand Avati <avati@redhat.com> Reviewed-on: http://review.gluster.org/4932 Reviewed-by: Vijay Bellur <vbellur@redhat.com> Tested-by: Gluster Build System <jenkins@build.gluster.com>
* glusterfs-api.pc: pkgconfig for API consumersAnand Avati2012-07-181-0/+11
Change-Id: I08c60ff9ec5d336077c39f903720f8850d4ddc72 BUG: 839950 Signed-off-by: Anand Avati <avati@redhat.com> Reviewed-on: http://review.gluster.com/3665 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Amar Tumballi <amarts@redhat.com> Reviewed-by: Kaleb KEITHLEY <kkeithle@redhat.com>
generated by cgit (git 2.34.1) at 2024-11-12 18:40:14 +0000