In the isync-1.0.4/src/drv_maildir.c file, around line 368 there is a flock followed by fcntl call. It seems that the second call is blocking if the maildir is on a NFS mounted folder.

I undefined the LEGACY_FLOCK macro, so now there is call anly to fcntl. This should do correct locking on modern linux kernels. There is no deadlock now, however did not test concurrent access.

After months of fight and frustration with nfs4 on Ubuntu, I switched to nfs3. And finally I can see the  light at the end of the tunnel! As I was describing here, I made some measurement about copy speed of small files towards nfs server and back. Copying to the server was almost 10 times slower with nfs4 than copying from the server (same harddisk type both on server and client).

Now with nfs3 the speeds are the same in both directions!!!

By having more and more devices around at home, it makes sense to keep all data in one place. I have a server for longer time, that runs a samba server, nfs file server and is acting as host for VirtualBox and Xen virtual machines. I had finally time to complete another phase of this “move everything to server”, by using a central home directory for all the clients.

The experiment was so far not completely successful as the writing speed towards the server is horribly low. I made the following experiments

1. Measured the ip speed with iperf in both directions between the client and server.

on the server:

xxx@yyyyyyyyy:~$ iperf -s
————————————————————
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
————————————————————
[ 4] local 192.168.12.5 port 5001 connected with 192.168.12.11 port 56444
[ 4] 0.0-10.0 sec 753 MBytes 630 Mbits/sec

on the client

uuuuu@qqq:~$ iperf -c 192.168.12.5
————————————————————
Client connecting to 192.168.12.5, TCP port 5001
TCP window size: 16.0 KByte (default)
————————————————————
[ 3] local 192.168.12.11 port 56444 connected with 192.168.12.5 port 5001
[ 3] 0.0-10.0 sec 753 MBytes 631 Mbits/sec

so the transfer rate is quite good (630Mbits/sec) for a Gbit card on both side as the server has a slower PCI.

2. Copied a 100MByte file from the server to the client, it took 1.6 sec

3. copied a the same 100MByte file from the client and it took 60sec!!! so 10 times slower!!! Cannot beleive….

Here is the line from /etc/fstab for the /home folder

192.168.12.5:/XXXXXX/home /home nfs4 auto,rw,nodev,sync,_netdev,noatime,proto=tcp,retry=10,rsize=32768,wsize=32768,hard,intr 0

4. By changing the sync parameter to async there was some significant improvement, but still far from perfect… copying from the server remained 1.6 sec, and copy to the server dropped to 3.6 sec. The same copy on the server, locally takes 1.7 sec.

This means that copying through nfs is twice slower than a local copy without having network bottleneck.

4. Copying 1000 files of 100kbyte from server to client took ~3sec, but back to the server 45secs!!!!! This is really painful. This made it clear, why programs like firefox slowed down since the nfs home. Firefox writes several small files quite often, so …

5. And now some comparison about (half) alternatives. Copying with scp the same 1000 files to the server took 12secs, so almost a quarter of the time spent with nfs.

Important to mention that there is no router between the computers, they are connected with a cat6 cable (gigabit ethernet).

Any suggestion if this copy time could be decreased?