I migrated a small company (7 PCs) from Samba (Windows network) to Seafile.
All the machines are running Windows 10 and I am using the latest SeaDrive client (v0.7).
The libraries are pretty huge, the main one for example has nearly 500 GB and many many thousands of files with very deep folder structures.
The problem now is that it takes about 3-5 minutes (depending on the machine, they are not equal) to show the files list. So after a fresh boot if an employee opens the S: drive, nearly all libraries (folders) are empty. They then have to close the windows file manager, wait a few mins, reopen it and then the files appear.
Of course they complain and are very frustrated now because their samba share never had this problem.
What should I do? Split the big libraries into smaller ones, would that even help? Or maybe it is a performance problem as the Seafile Server runs on a virtual machine (Ubuntu Server 16.04) and the I/O is not all that good actually (RAID 5 with enterprise class HDDs but just 5400 rpm) and I can’t do anything but upgrade the hardware?
I think in general you are right. On the other hand I think it’s not a good idea to let every PC sync the whole data. SeaDrive reduces the sync to structure only, but you said, it’s very deep.
I prefer to have a seafile server and a samba server and sync data between them with a terminal client. Of course rights management is not so flexible and library encryption is gone, too. But the samba server is always “up to date” and the sync times on startup are gone.
By design, the file list only need to be loaded from server during first time login. Then it will be stored locally and loaded into memory when the program started.
Do you have to wait a few minutes every time you start the program? Can you check the log file?
Thanks for your quick reply and sorry for taking that long to answer.
Still the same problem here even after reducing the size of my library. Directly after booting SeaDrive, (Drive S:) shows the libraries but they have no content even though seadrive is already started. Every library folder appears to be empty. What I also noticed is that some clients which do not have local admin permissions (Windows domain login, no local admin permissions) do not show the seadrive explorer icons (green checkmark etc.) but they do have the same problem so I don’t think it is related.
I took a copy of the logs and here are the results of a typical start in the morning.
Start of SeaDrive: 08:52:35
Files appearing: 08:55:15
Here is an extraction from the logs, the library which causes the problems is called “Daten”:
[06/12/17 08:52:35] seadrive.c(589): Starting SeaDrive client 0.7.0
[06/12/17 08:52:35] seadrive.c(614): rpc server started.
[06/12/17 08:52:38] repo-mgr.c(2385): switching account to http://192.168..*** @.de.
[06/12/17 08:52:39] sync-mgr.c(561): Repo ‘Meine Bibliothek’ sync state transition from ‘synchronized’ to ‘committing’.
[06/12/17 08:52:39] sync-mgr.c(2488): All operations of repo Meine Bibliothek(07a82bf9) have been processed.
[06/12/17 08:52:39] sync-mgr.c(561): Repo ‘Meine Bibliothek’ sync state transition from ‘committing’ to ‘synchronized’.
[06/12/17 08:53:42] sync-mgr.c(561): Repo '’ sync state transition from ‘synchronized’ to ‘committing’.
[06/12/17 08:53:42] sync-mgr.c(2488): All operations of repo’’(ceecdbaf) have been processed.
[06/12/17 08:53:42] sync-mgr.c(561): Repo ‘’********’’ sync state transition from ‘committing’ to ‘synchronized’.
[06/12/17 08:54:43] sync-mgr.c(1357): All repo fs trees are loaded.
[06/12/17 08:54:43] sync-mgr.c(561): Repo ‘Daten’ sync state transition from ‘synchronized’ to ‘committing’.
[06/12/17 08:54:43] sync-mgr.c(2488): All operations of repo Daten(9569258d) have been processed.
[06/12/17 08:54:43] sync-mgr.c(561): Repo ‘Daten’ sync state transition from ‘committing’ to ‘synchronized’.
[06/12/17 08:55:14] sync-mgr.c(561): Repo ‘Daten’ sync state transition from ‘synchronized’ to ‘get sync info’.
[06/12/17 08:55:14] [06/12/17 08:55:14] sync-mgr.c(561): Repo ‘Daten’ sync state transition from ‘get sync info’ to ‘downloading’.
http-tx-mgr.c(4806): Download with HTTP sync protocol version 1.
[06/12/17 08:55:14] http-tx-mgr.c(1117): Transfer repo ‘9569258d’: (‘normal’, ‘init’) --> (‘normal’, ‘check’)
[06/12/17 08:55:14] http-tx-mgr.c(1117): Transfer repo ‘9569258d’: (‘normal’, ‘check’) --> (‘normal’, ‘commit’)
[06/12/17 08:55:14] http-tx-mgr.c(1117): Transfer repo ‘9569258d’: (‘normal’, ‘commit’) --> (‘normal’, ‘fs’)
[06/12/17 08:55:14] http-tx-mgr.c(1117): Transfer repo ‘9569258d’: (‘normal’, ‘fs’) --> (‘finished’, ‘finished’)
[06/12/17 08:55:14] sync-mgr.c(561): Repo ‘Daten’ sync state transition from ‘downloading’ to ‘load repo’.
[06/12/17 08:55:15] sync-mgr.c(561): Repo ‘Daten’ sync state transition from ‘load repo’ to ‘synchronized’.
At home I am syncing HUGE web projects with thousands and thousands of files using the Linux SeaDrive client. I did not encounter such behaviour there. Only happens with the windows client at my customer’s location it seems.
Maybe it really is an I/O problem because of the low hard drive speed (5400rpm) in my customer’s server in combination with the fact that the SeaFile Server is running in a virtual machine rather than on dedicated hardware?
At home I am using ARM devices (1x Odroid XU4 for Seafile, 2x Odroid C2 for mySQL and Memcache) and a huge USB3.0 drive.
From your log, it took the client about two minutes to load the directories locally. How many directories under the S: drive do you have? The problem is not related to the server. The loading speed is related to the number of directories.
But some libraries in S: drive should already have contents when other libraries are still being loaded.