RE: Newbie: -tsize vs -j

Ahh, now I see what the problem is.  I can think of two things that
might work.

One solution would be to make your script very smart, and if a file was
larger than a cd, you could send it a tsize of something small (100MB?)
and just put the chunks of data on the cd as they will fit.  Unless you
are backing up CD or DVD images, I find your problem is not very common,
so this solution would be in my opinion ok for the worst case scenario.

The other solution will probably not work since I have not tried it,
Jorg probably knows best.  You might be able to just write to
the /dev/hdc or whatever device your cd writer is maybe when it gets
full it will send an EOT (end of tape) signal like a tape drive will.
If it works, that would be spiffy.  If it doesn't work, maybe somewhere
there is a driver that will cause a cdr to show up as a tape device.

I highly recommend going to tape.  You can get into an LTO for around
$1000, or internal AIT2 for $500.  That's not much in the grand scheme
of things.  You will end up with less to manage, and in my opinion have
a vastly improved system.  There are cheaper systems out there also, but
I would say these would be a good place to start if you are on a tight
budget.

I use a SAIT autoloader from Quantum for my stuff, and I am not going
back.  With mtx and star, I can start a backup on Friday, and have the
whole thing finished on Monday when I get to work, no attention needed.

Dan

On Mon, 2006-04-24 at 12:02 -0400, [email protected] wrote:
> Hi Dan,
> 
> Thanks for the reply! 
> 
> I couldn't see a solution when the file to be added is larger than the
> desired tsize.  
> 
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Daniel Davidson
> Sent: Monday, April 24, 2006 11:49 AM
> To: [email protected]
> Cc: [email protected]
> Subject: RE: [Star-users] Newbie: -tsize vs -j
> 
> 
> Couldn't you also write a script that keeps adding files one at a time
> to the archive until say the archive's current size plus the size of the
> new file is greater than your file limit.  Then you could just start a
> new file.
> 
> That would approximate what you want to do at the cost of increased
> processor usage and disk I/O.  But if you are writing files to cd/dvd,
> that should not be such a big deal.
> 
> I haven't tried this though, so I might just talking out my rear.  If
> you can go to tapes, this becomes much easier to do.
> 
> Dan
> 
> 
> On Sun, 2006-04-23 at 11:47 -0400, [email protected] wrote:
> > I'm trying to get cd or dvd size archive files using star. Star is 99.9%
> > perfect for my use. With -j I guess the -tsize becomes a
> not-to-exceed-size.
> > 
> > I don't want to use "split" since a single media failure in the middle
> would
> > make recovery of later blocks tough.
> > 
> > The .1% issue:
> > 
> > I guess I'll just write a shell script to take multiple archive files to
> > make the iso. I'll have wasted space on the cd/dvd - but if I make tsize
> > 200m it should only be about 100m. 
> > 
> > Do you see a better way?
> > 
> > I appreciate your time. 
> > 
> > -----Original Message-----
> > From: Joerg Schilling [mailto:[email protected]] 
> > Sent: Sunday, April 23, 2006 7:03 AM
> > To: [email protected]; [email protected]
> > Subject: Re: [Star-users] Newbie: -tsize vs -j
> > 
> > 
> > <[email protected]> wrote:
> > 
> > > Thanks for star - looks like it will work for my file archiving
> > > requirements.
> > >
> > > Is there a way to have the -tsize value be evaluated after compression? 
> > >
> > > Using this command: 
> > >
> > > /opt/csw/bin/star -cj -tsize=700m \
> > > -multivol -dump -M \
> > > -C=/usr \
> > > new-volume-script=nf.sh \
> > > -acl -artype=exustar f=f001 f=f002 f=f003 f=f004 f=f005 f=f006 f=f007 \
> > > level=0 -time .
> > >
> > > Produces the following files:
> > >
> > >  253963147 Apr 14 10:58 f001
> > >  180915793 Apr 14 11:01 f002
> > >  257749914 Apr 14 11:05 f003
> > >  279395825 Apr 14 11:10 f004
> > >    1580019 Apr 14 11:10 f005
> > 
> > This is the expected behavior.
> > 
> > > I was expecting each full file to be 734003200 bytes. 
> > 
> > Why? You don't see the archives but compressed variants....
> > 
> > If it wiould refer to the size past compression, your wich from below
> would
> > not be possible to implement.
> > 
> > > Also, is it possible to restore a multi-volume archive without some of
> the
> > > volumes?  In other words, if a media error prevents part 2 from being
> > > recovered, will parts 3 + be recoverable?
> > 
> > You will be able to recover the files (see man page) but not be able to 
> > do the special actions that are needed for incremental restores.
> > 
> > ---> All file content on the "good" parts of the tape is restorable
> > 
> > ---> implicit additional information is lost.
> > 
> > Jörg
> > 
> 
> _______________________________________________
> Star-users mailing list
> [email protected]
> http://lists.berlios.de/mailman/listinfo/star-users
>