[tahoe-dev] "tahoe stats" command

[Andrej Falout]

Hello,

> Yeah, that sounds like something has gone wrong. Could you 'ls' some of the
> directories and see if there's anything obviously missing?

I abbreviated the command line for the sake of readability. The full
command was:

/usr/bin/time --append
--output=/data-local/logs/repo/restoreBackups-polar-data-Pictures-Latest_09-02-11_14-33.log
-- tahoe cp --recursive --verbose
tahoe:'Backups/polar/data/Pictures/Latest' '/tmp/Pictures-RESTORE'
--node-directory='/home/andrej/.tahoe-allmydata.com/' >>
/data-local/logs/repo/restoreBackups-polar-data-Pictures-Latest_09-02-11_14-33.log
2>&1

Restore did work. I found the files in:

/home/andrej/--node-directory=/home/andrej/.tahoe-allmydata.com

:-)

So:

1) Not the first time --node-directory is causing the problems; some
commands want it in one place, other in another, some don't accept it
at all. It might be useful to have a environment variable as
alternative to this flag; maybe TAHOE_NODE_DIRECTORY?

2) Some kind of progress indicator is needed very much, for both
backup ('backup') and restore ('cp') operations. Percentage completed,
estimated completion time, transfer speed... Without --verbose,
practically nothing is shown in the console.

3) Backup ('backup') can be more or less resumed without too much
impact; If I am looking at at the right way, restore ('cp') cannot? It
will always restart downloading ALL files in the source, even if
identical files can already be found in destination?

4) It would be nice to be able to choose to create soft links instead
of creating duplicates of... well, duplicate files, when restoring.

5) non-ASCII names - tickets #565 and #534 : I hope for a resolution
yesterday, as most filesystems this days are created as Unicode.
Hopefully, there are no such limitations with 'backup' command?

6) symlinks - it would be very helpful, if not necessary, to have the
ability to follow soft links as an option, for both 'cp' and 'backup',
if the links themselves are not preserved in there existing form after
the restore ('cp') operation.

And above all:

Restoring 4577444kb, 5212 files, 206 directories, took 10:06:29.

Now, we can argue that upload 'cp' is slow because asymmetric ADSL
lines (I'm not convinced, as Duplicity front end is several times
faster, and my connection was far from saturated) , and that it's
acceptable to have initial backup running for a long time, and that
subsequent differential backups will take mostly acceptable time.
Nobody's panicking when backing up, so "no worries" as we say here.

With downloads, or particularly restores, the story is different. When
people NEED to restore, they are more often then not PANICKING, and
not very patient or tolerant. When a user NEED to restore from backup,
10 hours for 4GB will just not do. Needless to say, with this speed
(if I can use this word here), my ADSL connection was barely crossing
4% utilization.

If I can have only one wish regarding this project, it would be that
all focus after the imminent release is placed on speed.

I'd suggest taking as the starting point, Carbonite for backups, and
WizzDrive for restores, and the time table from
http://www.pcauthority.com.au/GroupTests/134829,online-backup.aspx

Thank you for your help and advice!
-- 
Andrej Falout