gmane.comp.archivers.star.user

stalling

Ryan Lovett — 2013-04-08T21:44:38

With star 1.5.2 on the latest Solaris 10, we are seeing star appear to
stall in the middle of dumping a ZFS snapshot to tape. Attaching dtruss,
iosnoop, and opensnoop to the affected process shows no activity. We
invoke star with:

  star -C /path/to/.zfs/snapshot/20130407 -c -S -acl artype=exustar \
-sparse -time -xdev \
-multivol -wtardumps -new-volume-script=/usr/local/sbin/mtx-next \
errctl=/usr/local/etc/star-errctl.conf \
-not pat=*/.Trash/* pat=*/.cache/* pat=*/.thumbnails/* pat=*/.nfs* \
level=0 fs-name=/path/to blocks=512 file=/dev/rmt/1cn .

I don't believe it is a problem with the tape device since we can kill the
hanging star and run another (on another filesystem) right after which
runs to completion.

Does anything above suggest why the star process stalls or waits?

How can one debug this further?

Thanks for your time,
Ryan

exclude directories

Ashley — 2013-02-25T21:29:38

Hi there

How can I exclude a few directories?
I have tried using --exclude-from $EXCL_LIST  and listed the directories 
in the said file, but
this does not work?

Thank you in advance!!

--one-file-system

Ashley — 2013-01-09T09:25:40

Hi there

I am using "mount --bind ..." in order to give ftp users access to 
specific folders they need, outside of
their home folder. So multiple mounts to the same /data/ folder

Problem is now when I backup it includes multiple copies of these folders.

Does star have a "--one-file-system " equivalent, or do I need to make a 
list
of all the folders mounted with the bind option and put these in an 
Exclude list?

Any other suggestions will be much appreciated!

Thank You in advance!

Span filesystem across two tapes

James R. Chavez — 2012-12-23T08:07:08

Hi,

I have been struggling with my Ufsdump backups for some time now.
Regardless of the blocksize i use I see very little improvement in
speed. I have been looking for a replacement and there are a few
threads out there that claim star is much faster. I have a few file
systems that span multiple LTO tapes. Currently I use ufsdump to span
these large filesystems across multiple takes in a script. I would
like to use star so I have been reading the man page on how to span
tapes and I see "-multivol". However this seems to be an interactive
only option.

Note that  -multivol  is  an  interactive  option  that
          prevents   star  from  being  used  in  non-interactive
          environments.   If  you  like  to  use  it  in  a  non-
          interactive    environment,   you   need   to   specify
          new-volume-script=script in addition in order to  auto-
          mate the media change procedure.


So my question,can anyone on the list share how I can use star tospan
a large filesystem across mul

star segmentation fault

Ashley — 2012-11-06T13:08:59

Hi there

I am running star 1.5.1-4.fc13.i686 on Fedora 13

If I use either tsize or multivol option I get "Segmentation fault (core 
dumped)"

Any help or advise will be much appreciated!!
Thank you in advance!

Problem compiling star on Debian squeeze

Ruud Baart — 2011-06-24T07:11:59

I have compiled star many times in different Debian systems. After 
downloading the needed dev-packages and after first compiling smake I 
usually manage to compile star without problems. On Debian Squeeze (the 
latest version of Debian) I can't compile star. Any help would be nice.

This is the error:

In file included from avoffset.c:32:
../include/schily/schily.h:246: error: conflicting types for ‘getline’
/usr/include/stdio.h:651: note: previous declaration of ‘getline’ was here

When I remove the definition of getline in schily.h I get other similar 
errors. After I have removed all other conflicting declarations, smake 
fails to compile star because the definitions are not correct.

I attach the output of smake (perhaps the list refuses attachements). 
This is the result without modifying any include file.

Buffer overflow in name_to_tcb

Lasse Kliemann — 2011-06-13T16:55:06

Compiled star with CFLAGS="-D_FORTIFY_SOURCE=2 -O2" on GCC 4.5.3, 
Glibc 2.13, Linux 2.6.39.1. Then created a file with a long name 
(100 characters) and tried to pack it up:

$ mkdir test
$ cd test
$ touch 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
$ star -c f=../test.tar .
*** buffer overflow detected ***: /tmp/schily-2011-06-05/star/OBJ/i686-linux-cc/star terminated
======= Backtrace: =========
/usr/lib/libc.so.6(__fortify_fail+0x40)[0xb77a17d0]
/usr/lib/libc.so.6(+0xe37ea)[0xb779f7ea]
/usr/lib/libc.so.6(__strcpy_chk+0x3f)[0xb779eb3f]
/tmp/schily-2011-06-05/star/OBJ/i686-linux-cc/star[0x8070c84]
/tmp/schily-2011-06-05/star/OBJ/i686-linux-cc/star[0x80610cf]
/tmp/schily-2011-06-05/star/OBJ/i686-linux-cc/star[0x8061f71]
/tmp/schily-2011-06-05/star/OBJ/i686-linux-cc/star[0x806217e]
/tmp/schily-2011-06-05/star/OBJ/i686-linux-cc/star[0x804c14b]
/tmp/schily-2011-06-05/star/OBJ/i686-linux-cc/star[0x8051b4b]
/usr/lib/libc.so.6(__libc_start_main+0xe6)[0xb76d

Feature requests related to sparse files

2011-03-15T12:34:22

Hi,

Here are a couple of suggestions relating to star's support for sparse files.

1. Allow -force-hole to apply to archive creation, not just extraction.

The -force-hole option tells star to extract all files from an archive
sparsely. That is, for files in the archive which contain regions of
all-zero bytes, star creates corresponding holes in the output files.

The advantage of doing that is the sparse files created occupy less disk
space and are faster to work with. (Reading holes is very fast since no
actual disk I/O is needed.) However, -force-hole only applies on archive
extraction, not creation.

Suppose you have some non-sparse files which have large all-zero regions.
You want to archive them efficiently. What you'd like to happen, is for
star to scan the files for all-zero regions, and archive them as sparse
files. The tar archive will thus be much smaller, and future extraction
much faster. The archive will likely be more compressible and compression
will be faster.

The -sparse option has no eff

star tape I/O suggestion

2011-03-03T19:12:23

Hi,

The default blocking factor of star (and other tar programs) is 20, so
data is written in chunks of 10240 bytes.

While using that small a tape block size allows for wider interchange,
writing one block at a time gives lower performance than necessary. When
writing to tape, the user can set fixed block size mode, e.g. by doing
  mt -f /dev/nst0 setblk 10240

Each tape I/O can then be a multiple of the block size, rather than a
single block. On my system the Linux kernel imposes an arbitrary limit on
I/O length of 512KB. But that would still allow each I/O to be of 51
10240-byte blocks.

It would thus improve performance if star were able to, when writing to
tape, write in chunks of 51 blocks (in this example). The final write
would be for a lower number of blocks. The same could apply for reading
from tape.

star issue when creating archives

2011-03-01T18:22:58

Hi,

I'm writing to report a possible star bug/issue/misfeature. (I'm using
star 1.5 on Linux.)

When creating an archive which is a normal file, if the archive file
already exists it is silently overwritten, but the file length is not
changed. So stale/old data remains at the end of the archive when the
amount of data written is less than the old archive length.

By comparison, GNU tar also overwrites the file silently, but truncates it
so no stale data remains at the end.

I think it would be preferable to by default print a message saying the
archive already exists and exit. If the user overrides that, star should
truncate the (existing) archive file so no previous data remains.

To demonstrate the problem, try this (where file1 and file2 are any files):
  star -v -c f=archive.tar file1 file2
  ls -l archive.tar
  star -v -c f=archive.tar file2
  ls -l archive.tar
  star -v -t f=archive.tar

Compare with doing:
  tar -vcf gnu_archive.tar file1 file2
  ls -l gnu_archive.tar
  tar -vcf gnu_archive.tar file2

skipping newer files faster

Lasse Kliemann — 2010-08-05T21:59:41

_______________________________________________
Star-users mailing list
Star-users< at >lists.berlios.de
https://lists.berlios.de/mailman/listinfo/star-users