glusterfs.git/xlators/protocol/client/src/client-rpc-fops_v2.c, branch v6.3

client-rpc: Fix the payload being sent on the wire

2019-03-29T15:23:52+00:00

The fops allocate 3 kind of payload(buffer) in the client xlator:
- fop payload, this is the buffer allocated by the write and put fop
- rsphdr paylod, this is the buffer required by the reply cbk of
  some fops like lookup, readdir.
- rsp_paylod, this is the buffer required by the reply cbk of fops like
  readv etc.

Currently, in the lookup and readdir fop the rsphdr is sent as payload,
hence the allocated rsphdr buffer is also sent on the wire, increasing
the bandwidth consumption on the wire.

With this patch, the issue is fixed.

Fixes: bz#1692101
Change-Id: Ie8158921f4db319e60ad5f52d851fa5c9d4a269b
Signed-off-by: Poornima G

copy_file_range support in GlusterFS

2018-12-12T15:56:55+00:00

    * 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     "

      - 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

libglusterfs: Move devel headers under glusterfs directory

2018-12-05T21:47:04+00:00

libglusterfs devel package headers are referenced in code using
include semantics for a program, this while it works can be better
especially when dealing with out of tree xlator builds or in
general out of tree devel package usage.

Towards this, the following changes are done,
- moved all devel headers under a glusterfs directory
- Included these headers using system header notation <> in all
code outside of libglusterfs
- Included these headers using own program notation "" within
libglusterfs

This change although big, is just moving around the headers and
making it correct when including these headers from other sources.

This helps us correctly include libglusterfs includes without
namespace conflicts.

Change-Id: Id2a98854e671a7ee5d73be44da5ba1a74252423b
Updates: bz#1193929
Signed-off-by: ShyamsundarR

Land part 2 of clang-format changes

2018-09-12T12:22:45+00:00

Change-Id: Ia84cc24c8924e6d22d02ac15f611c10e26db99b4
Signed-off-by: Nigel Babu

protocol: coverity fixes

2018-08-22T06:45:43+00:00

Fixes CID: 1389388 1389320 1274113 1388881 1388623 1124801 1124795

Change-Id: Ia72abc0560c959b0298f42e25abdfc5523755569
updates: bz#789278
Signed-off-by: Bhumika Goyal

xlators: protocol: Fix deferencing pointer after free coverity issues

2018-08-21T05:01:08+00:00

The pointer of type struct iobuf * is getting dereferenced after
getting freed by iobuf_unref function. Therefore, move this function
after all the dereferences of this pointer type.
Also, it is useful coding standard to have iobuf_unref just after
iobref_add. So, move iobref_add too.

Occurences found using Coccinelle script:
@@
identifier rsphdr_iobuf;
expression E;
identifier func;
@@
*iobuf_unref(rsphdr_iobuf);
...
*E = func(rsphdr_iobuf);

Fixes CID: 1390517, 1390278, 1388666, 1356588, 1356587 at [1].
and also some more occurences which were found using the above script but not
caught by Coverity.
[1]. https://scan6.coverity.com/reports.htm#v42388/p10714/fileInstanceId=84384920&defectInstanceId=25600709&mergedDefectId=1388666

Change-Id: I579e9d12698f14e9e24bc926c6efef16bac5c06c
updates: bz#789278
Signed-off-by: Bhumika Goyal

protocol/client: Remove code duplication

2018-06-15T04:46:29+00:00

client_submit_vec_request() which is used by WRITEV, and PUT
and client_submit_request() used by the rest of the fops have
almost similar code. However, there have been some more checks
- such as whether setvolume was successful or not, and one more
that is send-gid-specific - that have been missed out in the vectored
version of the function.

This patch fixes this code duplication.

Change-Id: I363a28eeead6219cb1009dc831538153e8bd7d40
fixes: bz#1591580
Signed-off-by: Krutika Dhananjay

client/protocol: fix the log level for removexattr_cbk

2018-05-17T04:05:49+00:00

noticed that server protocol actually logs all the errors for
removexattr as INFO, instead of WARNING like client, and hence,
doesn't create a confusion in user.

updates: bz#1576418
Change-Id: Ia6681e9ee433fda3c77a4509906c78333396e339
Signed-off-by: Amar Tumballi

protocol/client: fix memory corruption

2018-03-09T22:31:29+00:00

There was an issue when some accesses to saved_fds list were
protected by the wrong mutex (lock instead of fd_lock).

Additionally, the retrieval of fdctx from fd's context and any
checks done on it have also been protected by fd_lock to avoid
fdctx to become outdated just after retrieving it.

Change-Id: If2910508bcb7d1ff23debb30291391f00903a6fe
BUG: 1553129
Signed-off-by: Xavi Hernandez

protocol: utilize the version 4 xdr

2018-02-01T11:40:24+00:00

updates #384

Change-Id: Id80bf470988dbecc69779de9eb64088559cb1f6a
Signed-off-by: Amar Tumballi