lscommand executed on a Gluster Filesystem with 200K entries returns immediately. Let's assume a standard Gluster mount:
localhost:/sample_volname on /test type fuse.glusterfs (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072)
and approximately 200K files created inside this mount:
ls /test | wc -l 237329
lscommand returns in no time:
time ls /test/file111111 /test/file111111 real 0m0.049s user 0m0.001s sys 0m0.001s
However, when doing a remote connection to this file system using a
vsftpdclient, the same
lscommand returns in a few seconds:
ftp gluster-1 Connected to gluster-1 . 220 (vsFTPd 3.0.2) Name (gluster-1:root): 331 Please specify the password. Password: 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> ls /test/file111111 227 Entering Passive Mode. 150 Here comes the directory listing. -rw-r--r-- 1 0 0 0 Oct 21 11:22 file111111 226 Directory send OK.
From the vsftpd logs:
Mon Oct 21 10:48:09 2019 [pid 29143] [test] FTP response: "150 Here comes the directory listing." Mon Oct 21 10:48:23 2019 [pid 29143] [test] FTP response: "226 Directory send OK."
The command here took 14 seconds. This time increases if the volume layout contains a higher number of bricks or if the number of files stored is also bigger.
Why is this difference observed?
- Red Hat Gluster Storage 3.x
Subscriber exclusive content
A Red Hat subscription provides unlimited access to our knowledgebase of over 48,000 articles and solutions.