Comment 12 for bug 436612

Revision history for this message
Natalia Bidart (nataliabidart) wrote :

Some info from my current system in my laptop:

nessita@miro:~$ u1sdtool --list-folders | grep subscribed=True
4: id=2db262f5-a151-4c19-969c-bb5ced753c61 subscribed=True path=/home/nessita/Documents/tesis
5: id=0e0a3c0d-ddb8-4926-ad71-c33fd6079e6a subscribed=True path=/home/nessita/.purple/logs
8: id=9ea892f8-15fa-4201-bdbf-8de99fa5f588 subscribed=True path=/home/nessita/Public

nessita@miro:~$ find Ubuntu\ One/ Documents/tesis/ Public/ .purple/logs | wc -l
27074

* Every first time I start syncdaemon (in each boot), the metadata load doesn't finish and SD apparently crashes without leaving any trace. This means that the log file has nothing but:

2010-11-11 08:54:50,330 - ubuntuone.SyncDaemon.VM.MD - DEBUG - metadata version: 6
2010-11-11 08:54:50,385 - ubuntuone.SyncDaemon.fsm - INFO - loading updated metadata

and syncdaemon is not working. So I run u1sdtool -s again, and the log file is rotates and the load metadata process restart, and I get something like this:

2010-11-11 09:04:12,049 - ubuntuone.SyncDaemon.VM.MD - DEBUG - metadata version: 6
2010-11-11 09:04:12,050 - ubuntuone.SyncDaemon.fsm - INFO - loading updated metadata
2010-11-11 09:06:05,100 - ubuntuone.SyncDaemon.fsm - INFO - initialized: idx_path: 19704, idx_node_id: 15127, shares: 12

So the second metadata load process finish because the first attempt cached most of the files in the disk cache. So the second attempt takes 2 minutes when most of the files are already in the disk cache! So this amount of time is extremely large.