[Dirvish] Dirvish occupies the same space on disk for each run as for the initial run

[Jon Radel]

Stefan Knoll wrote:
> The strange thing is, the initial sync runs approx. 10 mins for each of 
> the two jobs. Each subsequent job runs 10 secs. max, which is o.k. 
> because there are not many files which get changed. However each backup 
> occupies exactly the same amount of disk space as the initial one. I 
> have now 4 backups plus the initial one and they are occupying approx. 
> 18,5GB
> My understanding was, that diskspace will only get allocated if a file 
> actually gets changed, so why does the occupied space grows and grows???

How are you measuring all this?  Especially given the difference in run
time, there is a possibility that you are simply measuring the wrong
thing, but dirvish itself is doing exactly what it should be.

If you use something like du to measure how much disk space is used, it
will report that every backup takes up 18.5 GB, +- a bit as things
change on the client machine, if you measure each backup individually.
This does not, however, mean that two backups together are actually
taking up 37 GB on the hard disk.

If this is what is happening, I've found that the following experiment
helps me think about it:

[jradel at dcasniff ~]$ cd /tmp
[jradel at dcasniff tmp]$ mkdir fakebackups
[jradel at dcasniff tmp]$ cd fakebackups
[jradel at dcasniff fakebackups]$ mkdir a
[jradel at dcasniff fakebackups]$ dd if=/dev/zero of=a/backup count=10000
10000+0 records in
10000+0 records out
5120000 bytes (5.1 MB) copied, 0.0705026 seconds, 72.6 MB/s
[jradel at dcasniff fakebackups]$ mkdir b
[jradel at dcasniff fakebackups]$ ln a/backup b/backup
[jradel at dcasniff fakebackups]$ du -sh a
5.0M    a
[jradel at dcasniff fakebackups]$ du -sh b
5.0M    b
[jradel at dcasniff fakebackups]$ du -sh .
5.0M    .

Or, I created one 5M file but have two directories, a and b, which are
both 5M big, but the contents of the directory they're in, is also only
5M in size.

You can find a more detailed discussion of this whole matter, and how
hard links work in practice, in the archives for this list.

--Jon Radel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2890 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.dirvish.org/pipermail/dirvish/attachments/20080127/9949db8d/attachment.bin