Thanks both Matt and Eric,
That is really interesting. I do tend to use "mc" since it can handle
multiple keys readily (eg when a user reports a problem). It was
noticable that when getting the recursive listing of the "slow" bucket
using mc, the output did appear in a "chunked" manner,
Hi,
I just did some testing to confirm, and can report, with "mc ls -r"
appears to be definitely inducing latency related to Unix path
emulation.
Matt
On Mon, Nov 5, 2018 at 3:10 PM, J. Eric Ivancich wrote:
> I did make an inquiry and someone here does have some experience w/ the
> mc command
I did make an inquiry and someone here does have some experience w/ the
mc command -- minio client. We're curious how "ls -r" is implemented
under mc. Does it need to get a full listing and then do some path
parsing to produce nice output? If so, it may be playing a role in the
delay as well.
The numbers you're reporting strike me as surprising as well. Which version are
you running?
In case you're not aware, listing of buckets is not a very efficient operation
given that the listing is required to return with objects in lexical order.
They are distributed across the shards via a
I have one user bucket, where inexplicably (to me), the bucket takes an
eternity to list, though only on the top level. There are two
subfolders, each of which lists individually at a completely normal speed...
eg (using minio client):
[~] % time ./mc ls fried/friedlab/
[2018-09-26 16:15:48
