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.
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 2005-01-25
15:35:29:
> Okay I'm with you so far, but will TSM server be able to tag a file as
> a sparse file even if the client is compressing the file before it
> sends it to TSM? Or does the client mark it as a sparse file. Otherwise
> how would makesparsefile know to restore the file as a sparse file?
>
> Thanks!
>
> Alex
>
> On Tue, 25 Jan 2005, Andrew Raibeck wrote:
>
> > With Unix, I think it is difficult to determine during backup whether
the
> > file is sparse or not, since there aren't any flags that say "I'm a
sparse
> > 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.
> >
> > Try using client compression, as a very sparse file should compress
very
> > well.
> >
> > Regards,
> >
> > Andy
> >
> > Andy Raibeck
> > IBM Software Group
> > Tivoli Storage Manager Client Development
> > Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
> > Internet e-mail: storman AT us.ibm DOT com
> >
> > The only dumb question is the one that goes unasked.
> > The command line is your friend.
> > "Good enough" is the enemy of excellence.
> >
> > "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 01/25/2005
> > 09:53:12:
> >
> >> TSM 5.1.9.0 on windows 2K server.
> >>
> >> We have a new Fedora Core 3 64-bit client, which has a
/var/log/lastlog
> >> sparse file on it, which is 1.2TB, yet only 112K in real blocks used.
> > TSM
> >> is trying to backup the entire 1.2TB file, which is causing some
backup
> >> problems.
> >>
> >> I've never had this issue before so I looked up sparse files in the
UNIX
> >> users guide, and it says sparse files can be "restored" or
"retrieved"
> >> with or without the block holes in it using the makesparsefile option
in
> >> dsm.opt. However, it does not say if this applys to the backup.
> >>
> >> I looked on my another unix client, and it's /var/log/lastlog is 19MB
> > but
> >> only 276 in actual blocks, yet TSM backed it up as 19MB. So it seems
> > that
> >> TSM must backup sparse files WITH the empty data holes in it, and
only
> > has
> >> the option to restore without the holes.
> >>
> >> Is this correct?
> >>
> >> On the other hand, anyone else have a FC3, and seen huge TB sized
> > lastlog
> >> files? That seems way out of hand.
> >>
> >> Thanks in advance,
> >>
> >> Alex
> >> ----- -----
> >> Alex Lazarevich | Systems Administrator | Imaging Technology Group
> >> Beckman Institute | University of Illinois | www.itg.uiuc.edu
> >> 405 North Mathews Avenue Urbana IL 61801
> >> Ph: (217) 244-1565 | Email: alazarev AT itg.uiuc DOT edu
> >> ----- -----
> >
|
