Why Does an 'ls' Command Executed from a 'vsftpd' Connection on a Gluster Volume with 200k+ Files Take Several Seconds?

Solution Verified - Updated -


  • An 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

    A plain lscommand returns in no time:

    time ls /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.
    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.

Current Customers and Partners

Log in for full access

Log In