Hi,
seems the problem is solved now by using option -dump.
I nevertheless report what i experienced and why i think
i failed to notice the importance of -dump.
If you decide to skip this part, please have a look
at the end of this mail : "abort too soft"
where i report incidents which might be of interest
for your ongoing work on errctl= .
My failure to use -dump was in part due to psychology :
dump/restore is traditionally an awful, hyper specific
tool to serialize and deserialize filesystems. Far from
what any reasonable backup should strive for.
But it was also due to the man page together with star's
behavior :
> > what file types other than PF_UNIX sockets are known
> > to raise error condition SPECIALFILE with artype=exustar ?
> > star: '/dev/log' unsupported file type 'socket'. Not dumped.
>
> Star with artype=exustar supports all possible filetypes that
> are used on Solaris.
Good to know.
I nevertheless get those messages with
star -c artype=exustar -acl
> I thought you like to use star to make backups.
> Why then do you use star in a mode that is intended for best
> portability between different POSIX systems?
Huh ?
Up to now i thought star was _all_ about backups.
... RTFMing ...
Do you mean with "make backups" that i should always
use option -dump (or "level=0") ?
I just tried and it makes the messages vanish.
I assume it is better to leave the artype-decision to -dump
and not to set artype=exustar explicitely.
gnutar was only a remote idea (for maximum portablity).
I got the strong impression that exustar is the preferrable
format for maximum exactness of recorded files and their
attributes.
I got led to artype=exustar by the man page when i
tried to employ -acl. This option refused to work
as
star -c -acl ...
and the man page mentions "[Aa][Cc][Ll]" mainly together
with options "artype=xustar" or "level=".
The description of "diffopts=" says:
"acl Compare access control lists. This only
works if the archive is in exustar format
and has been created with star's -acl
option."
The incremental examples from the man-page did work
without artype=exustar. I was a bit puzzled but
thought that with exustar i would get the best effort
out of star.
Checking the archive type a level=0 backup by
-print-artype did produce the answer "exustar archive".
So a sentence about the benefits of -dump would have
been helpful at the description of artype=exustar .
I now understand exustar as a prerequisite for
premium exactness but not as being at the level where
a user should tune exactness on the first hand.
> > I understand that powerful artype=exustar does not support
>
> It does of course, but you don't want them unless you are doing
> real and accurate backups.
Ew. That's a cryptic statement together with my experiences.
(I take it as a pointer towards option -dump)
Yes. I don't want them. I also don't want the messages.
But i want all other possibly more important messages
of star.
> > the default (despite the "do not" in man 1 star).
> > artype=star does not complain about sockets but the man page
> > gives me the impression that exustar is superior otherwise.
>
> The old star format is from 1986 and tries to be a clean extension
> on the historic tar archive format from 1978 while being
> definitely pre POSIX.1-1988.
A small paragraph (positioned quite early in star.1) about
the appropriate choice of archive formats would be helpful.
Like
- If you want maximum recording fidelity with file
attributes and properties, then use options ...
- If you want compatibility with other tar-like programs,
then use options ...
- If you want a full incremental backup of a single entire
filesystem see section "INCREMENTAL BACKUPS"
> Even ufsdump silently omits sockets from the backup....
> Star _includes_ them if in backup mode.
There is no term "backup mode" in the man page.
(I take it for "-dump" now)
There is a term "copy mode" but this does imply -dump .
There is also "archive mode" mentioned with "copy mode".
I find lots of other modes in the man page.
[start nostalgy]
> On a vanilla SVr4, there are no socket in the filesystem.
> Sockets reappeared around 1998 when SUSv2 did replace
> the t_* based networking interface by the old socked based
> system requiring that dup(2) on a socket works.
> As this is only possible if the socket implementation is in
> the kernel, Solaris did put sockets back into the kernel and
> did re-introduce socket typed files again althouth even the
> *BSD man pages from 1979 mentions socket files as being obsolete and
> unwanted....
I am maintaining a few programs which do IPC.
I considered to employ PF_UNIX sockets for local
communications but refrained because they are so
poorly documented and seem not to have been a
stable standard in the past.
(Named pipes aren't much better though.)
Learned my IPC from SunOS (on a "SUN IPC" workstation)
which brought very nice examples for IP based sockets.
[end nostalgy]
Now hugging my AMD 2600+ with its gig of RAM :))
> > I consider to use errctl= with a file containing the line
> > SPECIALFILE *
> > In a test it worked fine for artype=exustar -acl .
>
> Not needed if you use star for backups....
Ok, ok, ok. I will use -dump. :))
> BTW: I am just adding new features to the errctl= system
> that allows to tell star to abort on specific errors instead
> hiding them.
Good idea.
The lower the skills of the backup operator the
more harsh (but well balanced) should be the
reaction on unexpected problems.
I've seen a person storing daily backups for years
of which each single write run produced error
messages and told that person (in english) that the
backup was incomplete.
Regrettably the person knew hardly any english and
was only trained to watch for hard aborts.
There were tears flowing when the backups were
finally needed.
Your error handling concept allows a skilled
admin to describe the known problems so that
unskilled operators get a more clear feedback
from the backup utility.
I will try to make good use of it.
I encountered some overly soft aborts resp. misleading
error messages when using -fifo .
From my report sketch (still under construction) :
------------------------------------------------------
Suboptimal error message and sometimes abort too soft
with -fifo :
------------------------------------------------------
I aborted a star run (-fifo by default) by pressing CTRL+C
and got this message :
star: 362598 blocks + 0 bytes (total of 3713003520 bytes = 3625980.00k).
star: Success. Sync pipe read error on pid 10836 flags 0x1.
"Success" is a contradiction to the rest of the message.
Whyever errno is 0, one should avoid to expose that pseudo
error description text "Success" as standalone sentence.
Of course star did report further :
star: 362598 blocks + 8192 bytes (total of 3713011712 bytes = 3625988.00k).
star: The following problems occurred during archive processing:
star: Cannot: stat 0, open 0, read/write 0. Size changed 0.
star: Missing links 0, Name too long 0, File too big 0, Not dumped 28.
so one can hardly mistake the run for a real success.
Normally my script aborts on CTRL+C while star is running with -fifo.
But i experienced twice an overly soft abort with star-1.5a64
(while it piped into /dev/null) :
star: 373270 blocks + 8192 bytes (total of 3822292992 bytes = 3732708.00k).
star: 373270 blocks + 8192 bytes (total of 3822292992 bytes = 3732708.00k).
star: The following problems occurred during archive processing:
star: Cannot: stat 0, open 0, read/write 0. Size changed 0.
star: Missing links 0, Name too long 0, File too big 0, Not dumped 28.
star: Processed all possible files, despite earlier errors.
my own shell code then reacted on the 254 exit
+ ret=254
CAUTION: star had problems with some files. See messages above.
but was not aware that the problem was fatal.
The reading of files was not completed at that moment, i'm quite
sure. The disk was visibly busy and the run would have ended
with a count like
star: 481922 blocks + 0 bytes (total of 4934881280 bytes = 4819220.00k).
if not interrupted.
"Not dumped 28" is the usual count of PF_UNIX sockets which
were excluded (due to lack of -dump option).
So possibly i was quite lucky to get warned at all.
With star -no-fifo i get much more plausible aborts :
star: 3038 blocks + 0 bytes (total of 31109120 bytes = 30380.00k).
where my script sees
+ ret=141
and can react accordingly.
So i will use -no-fifo by default especially since many of
my writes get piped into cdrecord with its own fifo anyway.
Thanks for your support.
Have a nice day :)
Thomas
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.