The speed of copy is very very slow when much files in the folder

[Richard Sharpe]

On Sun, Apr 30, 2017 at 6:31 AM, Nico Kadel-Garcia <nkadel at gmail.com> wrote:
> On Sat, Apr 29, 2017 at 9:58 AM, Richard Sharpe
> <realrichardsharpe at gmail.com> wrote:
>> On Fri, Apr 28, 2017 at 9:18 PM, Nico Kadel-Garcia <nkadel at gmail.com> wrote:
>>> On Fri, Apr 28, 2017 at 11:25 PM, Richard Sharpe via samba-technical
>>> <samba-technical at lists.samba.org> wrote:
>
>>>> The problem with "case sensitive = yes" is that it is only for file
>>>> systems that are case insensitive. Yes, that sounds backwards, but
>>>> that is what it is for.
>>>>
>>>> While it will solve the copying problem if you don't actually have a
>>>> case-insensitive files system, it introduces other big issues. One is
>>>> that it will actually let you create two files with the same name that
>>>> differ only by case, eg, File1.txt and file1.txt. Then you have a
>>>> problem, because which one you get will depend on the exact case used
>>>> when asking for the file. These (and worse) are the dragons I
>>>> mentioned.
>>>
>>> Getting the file you asked for, with the spelling you asked for,
>>> rather than trying to mangle case to match a file with an alternative
>>> name is what I'd *want* and expect. The ancient use of case
>>> insensitive file systems is both confusing and dangerous. This is not
>>> what I would consider "a problem", I'd consider it desired behavior.
>>>
>>>> To use "case sensitive = yes" you need a file system that supports
>>>> case-insensitive lookups, like XFS, ZFS (on Linux) and GPFS, it seems.
>>>
>>> Respectfully, you could and should give up on case insensitive file
>>> names. They are an unnecessary computational and file system
>>> organizational burden.
>>
>> Excuse me while I regard you as a sciolist.
>
> I actually had to look that one up! A simple "you don't know what
> you're talking about" would have sufficed. And sorry, but I've
> considerable experience been dealing with filesystems as part f my
> professional responsibilities since..... dear lord, 1988? And with
> Samba since roughly 1993, when I ported it to SunOS and published
> notes.
>
> Large directories with many files in the same folder have *always*
> been a burden. Filesystems have improved in their ability to handle
> them: I'll note that ext, in particular, has improved in this regard
> since its earliest releases. But attempts to list, to analyze, and
> especially to sort these large directories are a real computational
> burden for the kernel itself. Layering complexity into the kernel to
> optimize performance for large directories more efficiently is not
> free, and has often degraded performance for more modest operations
> and even destabilized the file system itself. ext3, for example, is
> *still* a faster filesystem than ext4 if you don't require the
> journaling (for failure recovery) or improved handling of large
> directories (such as our original poster is seeking). Large
> directories are an old, old problem, with many references.

Wow, all that experience but you still do not understand that Windows
does not have that problem. Hell, even ZFS added case-insensitive
lookups for that reason and I made it work for ZFS on Linux a couple
of years ago (with a lot of help from others, of course).

The point is that Windows does not show this sort of O(N^2) and can
handle case-insensitivity with large numbers of files in directories
and if you want to deploy an enterprise-grade solution with Samba you
cannot tell customers that they need to change their environment to
suit your product.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)