ADSM-L

Re: unix sparse file backup?

2005-01-26 07:12:36
Subject: Re: unix sparse file backup?
From: "Marcel J.E. Mol" <marcel AT MESA DOT NL>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 26 Jan 2005 13:12:18 +0100
Nice test.
I tried it on a linux box and got the same results.
I wanted to see if there is perhaps a difference in
the backup/restore time and transfer rates.
But both files take the same amount of time to backup or
restore and transfer rates are also the same.

You don't even have to use the -makesparsefile=yes option.
The spares file is just restored as sparse file...

-Marcel

On Wed, Jan 26, 2005 at 09:28:47AM +0059, Jurjen Oskam wrote:
> On Tue, Jan 25, 2005 at 03:56:00PM -0700, Andrew Raibeck wrote:
>
> > > > file, here is allocation map". My understanding is that during restore,
> > > > TSM analyzes the data for lengthy patterns of zeroes in the data stream,
> > > > and that is how MAKESPARSEFILE works; but TSM does not do that analysis
> > > > during the backup.
>       [...]
> > The TSM server is not actively "aware" of a file's attributes. The
> > "sparseness" of the file is determined at restore time, after the data has
> > been uncompressed, but before it is written to the disk.
>
> I've just been testing this a bit. I've created two files, both 10M
> large. Both are entirely filled with zeros. One is sparse, one isn't:
>
> $ dd if=/dev/zero of=test-real bs=1024 count=10240
> 10240+0 records in.
> 10240+0 records out.
> $ dd if=/dev/zero of=test-sparse bs=1024 count=1 seek=10239
> 1+0 records in.
> 1+0 records out.
> $ ls -l test-real test-sparse
> -rw-r--r--   1 joskam   staff      10485760 Jan 26 08:52 test-real
> -rw-r--r--   1 joskam   staff      10485760 Jan 26 08:52 test-sparse
> $ cmp test-real test-sparse
> $ du -k test-real test-sparse
> 10240   test-real
> 4       test-sparse
>
> Then I did (dsmc output compacted):
>
> $ dsmc sel test-real test-sparse
> Normal File-->        10,485,760 /home/joskam/test-real [Sent]
> Normal File-->        10,485,760 /home/joskam/test-sparse [Sent]
> Total number of bytes transferred:    20.00 MB
>
> $ rm test-real test-sparse
> $ ls -l test-real test-sparse
> ls: 0653-341 The file test-real does not exist.
> ls: 0653-341 The file test-sparse does not exist.
> $ dsmc rest -makesparsefile=yes test-real
> Restoring      10,485,760 /home/joskam/test-real [Done]
> Total number of bytes transferred:    10.00 MB
>
> $ dsmc rest -makesparsefile=yes test-sparse
> Restoring      10,485,760 /home/joskam/test-sparse [Done]
> Total number of bytes transferred:    10.00 MB
>
>
> If what you're stating above is true, TSM would have no knowledge of
> whether a file was originally sparse or not. But it does:
>
> $ du -k test-real test-sparse
> 10240   test-real
> 4       test-sparse
>
> Both the above files were restored with MAKESPARSEFILE=YES, but only
> the file that originally was sparse is restored as such.
>
> I repeated this with 512 MB files, and got the exact same results.
> With these larger files however, it was easily observable that
> the sparse file and the normal file took the same amount of time to
> be sent to the TSM server. This also applied to restoring.
>
> So it would seem that sparse files are indeed sent to and stored on
> the TSM server without any "holes". However, it would also seem that
> the TSM server does indeed know whether a file was sparse or not.
>
> I did not test whether sparse files are restored with the same layout,
> i.e. whether the "holes" in restored sparse files are in the same
> place as the "holes" in the original files.
>
> --
> Jurjen Oskam
>   "E-mail has just erupted like a weed, and instead of considering
>   what to say when they write, people now just let thoughts drool
>   out onto the screen." - R. Craig Hogan

--
     ======--------         Marcel J.E. Mol                MESA Consulting B.V.
    =======---------        ph. +31-(0)6-54724868          P.O. Box 112
    =======---------        marcel AT mesa DOT nl                 2630 AC  
Nootdorp
__==== www.mesa.nl ---____U_n_i_x______I_n_t_e_r_n_e_t____ The Netherlands ____
 They couldn't think of a number,           Linux user 1148  --  counter.li.org
    so they gave me a name!  -- Rupert Hine  --  www.ruperthine.com

<Prev in Thread] Current Thread [Next in Thread>