Bug 1691833 - Client sends 128KByte network packet for 0 length file copy
Summary: Client sends 128KByte network packet for 0 length file copy
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: GlusterFS
Classification: Community
Component: core
Version: 5
Hardware: x86_64
OS: Linux
high
medium
Target Milestone: ---
Assignee: Xavi Hernandez
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-22 15:57 UTC by Otto Jonyer
Modified: 2023-09-14 05:25 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2020-01-27 10:29:10 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)
Wireshark report of the network overhead (320.81 KB, image/png)
2019-03-22 15:57 UTC, Otto Jonyer
no flags Details

Description Otto Jonyer 2019-03-22 15:57:15 UTC
Created attachment 1546951 [details]
Wireshark report of the network overhead

Description of problem:
Installed Ubuntu Server 18.10 from official release. 
Installed debian packages from ppa:gluster/glusterfs-5 (download.gluster.org)
The problem was originally reproduced on CentOs based on with custom compilation of glusterfs-5.1
 
Created the simplest replica filesystem on 2 nodes and mounted on one of the nodes but it is also reproducible when mounted from dedicated client as well.
Created a 0 length file with "touch /tmp/0length"
Copied the file to gluster mount.
Network capture shows that 128KByte packet is sent to both replica which is a huge network overhead for really small files.

the commands I've used:
  mkdir /mnt/brick
  gluster peer probe 192.168.56.100
  gluster volume create gv0 replica 2 192.168.56.100:/mnt/brick 192.168.56.101:/mnt/brick force
  gluster volume start gv0
  mkdir /mnt/gv0
  mount -t glusterfs 192.168.56.100:/gv0 /mnt/gv0
  touch /tmp/0length
  cp /tmp/0length /mnt/gv0

Version-Release number of selected component (if applicable):
5.5-ubuntu1~cosmic1: glusterfs-client glusterfs-common glusterfs-server

How reproducible:


Steps to Reproduce:
1)  on both nodes: mkdir /mnt/brick
2)  on 192.168.56.101: gluster peer probe 192.168.56.100
3)  gluster volume create gv0 replica 2 192.168.56.100:/mnt/brick 192.168.56.101:/mnt/brick force
4)  gluster volume start gv0
5)  mkdir /mnt/gv0
6)  mount -t glusterfs 192.168.56.100:/gv0 /mnt/gv0
7)  touch /tmp/0length

8)  tcpdump -s 0 -w /tmp/glusterfs.pkt 'host 192.168.56.100'
9)  cp /tmp/0length /mnt/gv0
10) stop network capture and load into wireshark


Actual results:
The network capture is 256KByte length and I see 1-1 'proc-27' calls to both glusterfs nodes with 128KB sizes.

Expected results:
The network capture is a few kilobytes and low network overhead for small files.

Additional info:

Comment 1 Otto Jonyer 2019-03-22 16:18:05 UTC
Very strange for larger sizes:

If I use 7 KByte file I get 2*128 KB packets.
If I use 15, 31 KByte file I get 2*128 KB + 1*32KB packets.
If I use 63, 127 or 129 KByte file I get 6*128KB packets.

Comment 3 Xavi Hernandez 2019-12-19 16:30:10 UTC
I've tested this with 5.11 and 7.0 and I've not observed this issue. All packets are smaller than 1 KiB except the write request, which matches the expected size.

Can you provide some more information and share the packet capture ?

Comment 4 Xavi Hernandez 2019-12-19 18:14:58 UTC
BTW, proc 27 is a LOOKUP request. It seems weird that it uses 128 KiB for the request packet.

Comment 5 Xavi Hernandez 2020-01-09 16:48:32 UTC
@Otto, can you provide some more information about this problem ?

Comment 6 Xavi Hernandez 2020-01-27 10:29:10 UTC
I'm not observing this behavior and I don't have more data to investigate, so I'm closing the bug. If you see that the problem persists and can provide requested data, feel free to reopen it to continue investigating.

Comment 7 Red Hat Bugzilla 2023-09-14 05:25:49 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days


Note You need to log in before you can comment on or make changes to this bug.