On Monday 21 November 2005 22:20, Bob Manson wrote:
> > By default cp and tar don't work well, but they have a --sparse or -S
> > option. I don't know if --sparse=auto works on NFS (it depends on the FS
> > reporting the real disk usage), but --sparse=always should work (never
> > tested).
> > Ah, but cp --sparse will still read the holes, so it's pointless on NFS.
> > "Good job" means in their creation, right? Because rsync --sparse could
> > also save downloading the holes through the network.
> My colleague, Dan, who helped me develop the script said:
> "rsync --sparse" has the same deficiency as "cp --sparse": since there's
> no dependable API for finding the holes in a sparse file over NFS,
> copying the file from $HOME to /tmp requires reading all the zeros over
> NFS regardless of what userland program is used to do the copying.
Ok, fully correct. Indeed, I think there's in general little point in using
rsync over mounted shares - it will treat the file as locally present and
freely read from it.
> The key to how we speed up the process of creating and storing the COW
> file is that the copy that's stored in the user's home directory is not
> itself a sparse file: it's a tar archive which describes where the holes
> in the file are. That is, we use something along the lines of
> cd /tmp; /usr/bin/star -sparse -c -f $HOME/UML/cow_file.star
> to save the COW file, and
> cd /tmp; /usr/bin/star -sparse -x -f $HOME/UML/cow_file.star
> to unpack it again.
> The actual script uses compression as well (i.e. the -bz flag) so the
> files are a bit smaller than they would be otherwise. All in all, using
> star in this manner make the process a whole lot faster than cp or rsync.
> (GNU tar could also be used but we found that it was a little slower.)
Ok, very interesting - thanks for the thorough explaination.
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB