![]() The mac showing "preparing to copy to" and then copy during all this time.ģ3 minutes to copy 644 MB of audio files with the smbd process 99% on random cores. The server completely collapsing, and crank to 20M ARC requests for 33 minutes (!!!) (dragn n drop from one folder to the other with the mac os finder) I* try to copy 708 files (644MegaBytes) from my mac onto SMB share in a folder containing 1659 files (audio wav files) (Gui of course, my users don't even know that command line exists) If anyone has tested something in this kind of setup let me know. There are not so many "viable", "working", "ressources forks aware" file synchronization program available on mac. That's the way the whole branch work, It has to work this way. If I try AFP for exemple performances are better but as AFP is deprecated we can't rely on this setup.Īs a post production company we work with sound files, video files and folder with thousound of files in it. Mac os just only officially support SMB so we are stuck with SMB and SMB has to work. ![]() So with twice the same action we have a different behaviour.īut still as soon we go with intensive metadata over SMB we have performance NIC testing, No differences has been observed during the 2 months test session we've been thru If I launch again with freefilesync the same bunch of dataĪRC Requests demand_metadata jump to 7/10M with moment over 13M but this time it didn't go with smbd process overloading cores. I launch another copy with finder of the same bunch of dataĪRC Requests demand_metadata stay below 4M as during the test sessions we've done some months ago.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |