Tux

...making Linux just a little more fun!

Talkback:132/renker.html

[ In reference to "Poor Man's Laptop" in LG#132 ]

Gerrit Renker [grrtrr at yahoo.co.uk]
Tue, 19 Dec 2006 09:07:08 +0000 (GMT)

Sorry the initial question never got copied to me, I realised that after reading the talkback some time later. I hope that the below clarifies.

> Any particular reason for not just using a tool, which already exists
> - such as Unison (http://www.cis.upenn.edu/~bcpierce/unison/) which is
> cross platform/OS ?

Unison synchronises between directories - this means if you intend to use it in combination with a USB stick then your USB stick carries an identical copy of all the directories which you intend to synchronise.

But this is not what the article is about.

If you intend to have an identical copy of some of the computer's directories then there are two other alternatives:

(a) mount the USB stick (or USB hard drive) underneath such working directories as you intend to use at home and at work (bind/rbind/move options to mount) In this case you neither need the solution in the article, nor unison.

(b) carry a synchronised version of some work directories on your USB stick. ==> Again you don't need the solution in the article. And you don't even need unison. For this purpose, rsync is useful, has been tested by thousands and is much better than plain cp since it only copies the updates: rsync -a --delete source destination

The solution in the article works and is designed for when you have neither (a) or (b): the former is expensive in terms of hardware, the latter is expensive in terms of space.

Unison or rsync are not sufficient for this purpose.

With regard to solution (b), it may be interesting to see whether there is anything which unison can do that rsync can not.

Gerrit


Top    Back


Kapil Hari Paranjape [kapil at imsc.res.in]
Wed, 20 Dec 2006 09:39:58 +0530

Hello,

> With regard to solution (b), it may be interesting to see whether there is anything
> which unison can do that rsync can not.

"unison" can synchronise in both directions and offer to merge text files. This is something that "rsync" cannot do. This is because "unison" maintains history but "rsync" doesn't. On the other hand this means some storage space used up by "unison".

The basic principle in "unison/rsync" is also used in "git". The "unique name" of a file is its SHA1/MD5 checksum.

In fact you may think of your scheme as a revision/version control scheme with distributed archives: HOME and WORK. The USB stick acts as the "network"[*]. Perhaps this presents alternate approaches.

Regards,

Kapil.

[*] Never underestimage the bandwidth of a truck full of floppies --- Andrew Tannenbaum (sp?) --


Top    Back


Benjamin A. Okopnik [ben at linuxgazette.net]
Wed, 20 Dec 2006 10:11:45 -0600

On Wed, Dec 20, 2006 at 09:39:58AM +0530, Kapil Hari Paranjape wrote:

> 
> [*] Never underestimage the bandwidth of a truck full of floppies
> 		--- Andrew Tannenbaum (sp?)

The oldest version I can recall is "a 747 full of mag tapes." All these massively-parallel versions of the Sneakernet have their uses.

-- 
* Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *

Top    Back


Gerrit Renker [grrtrr at yahoo.co.uk]
Thu, 21 Dec 2006 11:02:36 +0000 (GMT)

Hi Kapil,

thank you for the helpful information.

> The basic principle in "unison/rsync" is also used in "git". The
> "unique name" of a file is its SHA1/MD5 checksum.
> 
> In fact you may think of your scheme as a revision/version control
> scheme with distributed archives: HOME and WORK. The USB stick acts as
> the "network"[*]. Perhaps this presents alternate approaches.
This is correct and I have been thinking whether there is a smarter way of synchronising for this particular scenario, using git. But the space demands of git are quite huge, and it requires much greater discipline when used as a general-purpose tool than when merely tracking directories.

> [*] Never underestimage the bandwidth of a truck full of floppies
> 		--- Andrew Tannenbaum (sp?)
The throughput equation: 128MB USB stick, time to get home: 30 minutes => throughput = 256MB/hour. Btw the origin of the script is about 8 years ago when I could not afford a 120MB zip drive and used a stack of floppies, plus `split' and `cat' to take home larger pieces of software.


Top    Back


Benjamin A. Okopnik [ben at linuxgazette.net]
Thu, 21 Dec 2006 09:18:00 -0600

On Thu, Dec 21, 2006 at 11:02:36AM +0000, Gerrit Renker wrote:

> Hi Kapil,
> 
> thank you for the helpful information. 
> 
> > The basic principle in "unison/rsync" is also used in "git". The
> > "unique name" of a file is its SHA1/MD5 checksum.
> > 
> > In fact you may think of your scheme as a revision/version control
> > scheme with distributed archives: HOME and WORK. The USB stick acts as
> > the "network"[*]. Perhaps this presents alternate approaches.
> This is correct and I have been thinking whether there is a smarter way
> of synchronising for this particular scenario, using git. But the space
> demands of git are quite huge, and it requires much greater discipline
> when used as a general-purpose tool than when merely tracking directories. 
> 
> > [*] Never underestimage the bandwidth of a truck full of floppies
> > 		--- Andrew Tannenbaum (sp?)
> The throughput equation: 128MB USB stick, time to get home: 30 minutes 
>    => throughput = 256MB/hour. 
> Btw the origin of  the script is about 8 years ago when I could not afford a
> 120MB zip drive and used a stack of floppies, plus `split' and `cat' to take
> home larger pieces of software.

You could always use the "multiple archive" feature of 'tar' in those situations, which would happily slice and dice files for you:

# Creates 1024kB archives on floppy
tar -ML1024 -cvf /mnt/fd0/archive.tar /dir/to/back/up
And you could even get fancy by adding a '-F umount' option (executed at the end of each volume) and saving yourself some typing; mounting the new floppy is, of course, best done from another console or xterm. Conversely, you could make friends with 'automount' and save yourself that hassle.

Isn't it nice that we don't need to do that stuff anymore, though? I remember being very happy indeed when SuperDisks came out: I could now transport data in useful amounts, instead of doing all of the above fiddling (or its equivalent in DOS/Wind0ws.)

-- 
* Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *

Top    Back


Gerrit Renker [grrtrr at yahoo.co.uk]
Thu, 21 Dec 2006 21:12:28 +0000 (GMT)

Hi Benjamin,

> # Creates 1024kB archives on floppy
> tar -ML1024 -cvf /mnt/fd0/archive.tar /dir/to/back/up
Kewl! That is something I was ignorant of but it is one of the options which I must commit to secondary storage inside my head :-)

> Isn't it nice that we don't need to do that stuff anymore, though? 
Yeah but the engineering spirit to solve this problem can be later reused in a similar situation. It is great - I just found out that the price of USB sticks has gone lower again.

All the best wishes for a merry Christmas & happy new year Gerrit


Top    Back