Re: tar, backup, growisofs, file names

[Andy Polyakov <appro@fy.chalmers.se>]

> > > > > > > how can i have  * reading from stdin (from tar/bzip)
> > > > > > >                 * named backup files and a filesystem
> > > > > > >                 * no writing to hardisc first (i dont want
> > > > > > >                   to rely on 4.4G beeing free.)
> > >
> > > now i dropped the last point and create a temporal file on the
> > > harddisk first. here is my script:
> > > ...
> > > /bin/tar $TAR_OPTS
> > > bzip2 --best $BKFILE
> > > BKFILE="$BKFILE.bz2"
> > > growisofs $MODE /dev/dvd -J -R $BKFILE
> >
> > Keep in mind for example
> > http://www.mail-archive.com/cdwrite@other.debian.org/thrd4.html#04255.
> > For media interoperability [under Linux], make sure files are smaller
> > that 2GB-1.
> 
> So you dont refere to the old 2gig limit but some
> interoperability thing?

Yes, one can say that. Even though Linux kernel as whole is now free
from 2GB limitation, isofs module still implies this limit and in quite
ugly way. Yes, it should be fixed and it will be fixed at some point.
However! Even if/when it will be fixed, I personally would *still*
recommend to limit files you put into isofs volume to 2GB-1 byte (well,
to 2GB-2K for optimal utilization and performance). Why? Because you
still won't be able to be sure that the kernel you will *have to*
access the volume under is fixed. This is why I say "to ensure
interoperability." It's unfortunate, but *practical* advice.

> growisofs --version
> * growisofs by <appro@fy.chalmers.se>, version 5.13,
>   front-ending to mkisofs: mkisofs 2.01a17 (i686-pc-linux-gnu)

Note that officially released mkisofs versions explicitly warn you about
this 2GB-1 limit and even refuse to include larger files. When this
limitation was removed in some 2.01aX it was suggested to at least keep
the warning message or make it selectable with some option.

> -rw-r--r--    1 root     root      4845822 Dec 12 22:17 /cdrom/lukas-2003-12-12-full.tar.bz2
> -rw-r--r--    1 root     root     2252992766 Dec 12 22:17 /tmp/backup.Ypg3e2/lukas-2003-12-12-full.tar.bz2

Print the above sizes with 'printf "%08x\n" ...' Do you see similarity?
This is how the isofs implementation deficiency manifests itself...

> i also tried to split up my resulting file on the fly:
> growisofs -Z /dev/dvd -debug -R -J -split-output -o lukas-2003-12-12-full.tar.bz2 /tmp/backup.Ypg3e2/lukas-2003-12-12-full.tar.bz2
> growisofs: -o[output] option is not permitted.

I'm not referring to total size of volume, but to size of every file
that is going to volume. In other words you should split *input*,
lukas-2003-12-12-full.tar.bz2, *prior* recording. In your particular
case one could recommend:

tar cf - /some/dir | bzip2 -c | split -b 2095104 - /scr/atch/full.tar.bz2

and then 'growisofs -Z /dev/dvd /scr/atch'. Restore is performed with
'cat /cdrom/full.tar.bz2* | bunzip2 -c | tar xf -', which is perfectly
interoperable among all Unices including deficient Linux
implementations. A.