Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
HELP!: Both sun- & gnu-tar loop. Symlink loop? *STAR* better?
104 views
Skip to first unread message
David Combs
Aug 10, 2012, 3:28:35 PM8/10/12
to
It's a zfs file-system, but since zfs incredibly has no way to
do true backups (to a file, disk, or tape, to take off-site),
am using what zfs-best-practices suggested, tar.
(What was Sun thinking? This huge marketing push for an OS-part
(zfs) that allows no backup to a can-move-to-off-site-place?
You'd think that management wouldn't allow them to release
the thing until they did nave a working zfsDump,
given their loyal customer base's
over 25 years experience with the totally essential
dump (aka ufsdump)!)
Tried sun tar. Looped, HUGE output before had to kill it.
I've gnu tar (v26) right now, with same result, forever
growing and disk-eating (separate DLINK NAS)!
I guess I have to kill it before it eats that 2 terabyte
thing.
The gnu-tar man page, I recall, says that, by default,
it does NOT actually *follow* symlinks.
Clearly something is wrong within my single zfs pool.
Don't know what. *If* I have a symlink
loop, there should be no problem, right?, so long as
no one (eg tar) derefs (follows) them, but just
leaves them as text names of tree paths.
(Please: am I correct?).
QUESTION: any switches (options) I should have used,
in either sun or gnu tar?
(General Question: which is generally better of those
two tars?)
---
Please, dear god, could this NEXT tar be a solution?:
Some people here swear by STAR (ess-tar, Schilly's tar).
It is supposed to be truly *far* superior to any other tar.
Problem is, there's *so many* options (man page is 50 pages
long, printed!), with many maybe from way back when, when all
tars (except his) had bugs galore, but are no longer
so useful with newer tars abounding, but back then
he had to be compatible. (Got to be *some* reason for
all those options!)
I read it, and those 50 printed pages blows my 70 years old mind!
It's *way* over my head. (I've communicated with him,
and his response was that (his) star man-page was completly
straightforward, and should be no problem
reading and understand it. Something like that.)
So, please:
DOES ANYONE KNOW THAT 100-option PROGRAM, "STAR"?
If so, please give me a command, with proper
options, that might actually succeed on my huge
(90 gig) directory tree.
THANKS MUCH!
David
PS: hey guys, I'm getting *really* freaked out, with
maybe NO way to back up this zfs!
do true backups (to a file, disk, or tape, to take off-site),
am using what zfs-best-practices suggested, tar.
(What was Sun thinking? This huge marketing push for an OS-part
(zfs) that allows no backup to a can-move-to-off-site-place?
You'd think that management wouldn't allow them to release
the thing until they did nave a working zfsDump,
given their loyal customer base's
over 25 years experience with the totally essential
dump (aka ufsdump)!)
Tried sun tar. Looped, HUGE output before had to kill it.
I've gnu tar (v26) right now, with same result, forever
growing and disk-eating (separate DLINK NAS)!
I guess I have to kill it before it eats that 2 terabyte
thing.
The gnu-tar man page, I recall, says that, by default,
it does NOT actually *follow* symlinks.
Clearly something is wrong within my single zfs pool.
Don't know what. *If* I have a symlink
loop, there should be no problem, right?, so long as
no one (eg tar) derefs (follows) them, but just
leaves them as text names of tree paths.
(Please: am I correct?).
QUESTION: any switches (options) I should have used,
in either sun or gnu tar?
(General Question: which is generally better of those
two tars?)
---
Please, dear god, could this NEXT tar be a solution?:
Some people here swear by STAR (ess-tar, Schilly's tar).
It is supposed to be truly *far* superior to any other tar.
Problem is, there's *so many* options (man page is 50 pages
long, printed!), with many maybe from way back when, when all
tars (except his) had bugs galore, but are no longer
so useful with newer tars abounding, but back then
he had to be compatible. (Got to be *some* reason for
all those options!)
I read it, and those 50 printed pages blows my 70 years old mind!
It's *way* over my head. (I've communicated with him,
and his response was that (his) star man-page was completly
straightforward, and should be no problem
reading and understand it. Something like that.)
So, please:
DOES ANYONE KNOW THAT 100-option PROGRAM, "STAR"?
If so, please give me a command, with proper
options, that might actually succeed on my huge
(90 gig) directory tree.
THANKS MUCH!
David
PS: hey guys, I'm getting *really* freaked out, with
maybe NO way to back up this zfs!
John D Groenveld
Aug 10, 2012, 4:07:25 PM8/10/12
to
In article <k03nd3$fn2$1...@panix1.panix.com>,
<URL:http://docs.oracle.com/cd/E23824_01/html/821-1462/zfs-1m.html#scrolltoc>
What's failing for you?
>It's *way* over my head. (I've communicated with him,
>and his response was that (his) star man-page was completly
>straightforward, and should be no problem
>reading and understand it. Something like that.)
I found Joerg Schilling's manpage readable.
>So, please:
>
>DOES ANYONE KNOW THAT 100-option PROGRAM, "STAR"?
>
>If so, please give me a command, with proper
>options, that might actually succeed on my huge
>(90 gig) directory tree.
>
>THANKS MUCH!
>
>David
>
>PS: hey guys, I'm getting *really* freaked out, with
>maybe NO way to back up this zfs!
What is your configuration?
John
groe...@acm.org
David Combs <dkc...@panix.com> wrote:
>It's a zfs file-system, but since zfs incredibly has no way to
>do true backups (to a file, disk, or tape, to take off-site),
>am using what zfs-best-practices suggested, tar.
zfs(1M) snapshot and send work for me.
>It's a zfs file-system, but since zfs incredibly has no way to
>do true backups (to a file, disk, or tape, to take off-site),
>am using what zfs-best-practices suggested, tar.
<URL:http://docs.oracle.com/cd/E23824_01/html/821-1462/zfs-1m.html#scrolltoc>
What's failing for you?
>It's *way* over my head. (I've communicated with him,
>and his response was that (his) star man-page was completly
>straightforward, and should be no problem
>reading and understand it. Something like that.)
>So, please:
>
>DOES ANYONE KNOW THAT 100-option PROGRAM, "STAR"?
>
>If so, please give me a command, with proper
>options, that might actually succeed on my huge
>(90 gig) directory tree.
>
>THANKS MUCH!
>
>David
>
>PS: hey guys, I'm getting *really* freaked out, with
>maybe NO way to back up this zfs!
John
groe...@acm.org
Doug McIntyre
Aug 10, 2012, 7:48:36 PM8/10/12
to
dkc...@panix.com (David Combs) writes:
>It's a zfs file-system, but since zfs incredibly has no way to
>do true backups (to a file, disk, or tape, to take off-site),
>am using what zfs-best-practices suggested, tar.
>(What was Sun thinking?
Does 'zfs send' not work for you?
>It's a zfs file-system, but since zfs incredibly has no way to
>do true backups (to a file, disk, or tape, to take off-site),
>am using what zfs-best-practices suggested, tar.
>(What was Sun thinking?
David Combs
Aug 10, 2012, 10:32:06 PM8/10/12
to
In article <k03plt$lk2k$1...@tr22n12.aset.psu.edu>,
lack of a decent, actually useful zfs mental model:
Yeah, but what does it send, that you can use on
another (*fresh*, solaris zfs) machine?
It is really a basic misunderstanding of mine:
don't you have to have on the machine the basic
data that you originally put there via ufsrestore.
Gigabytes of stuff from a lev-0 dump on a UFS machine.
Say I make a snapshot soon after I do the ufsrestore.
I then put ("send") the snapshot to a tape.
Machine crashes and dies.
BIG QUESTION: What use is that tape? What's on it?
As I understand
it, the relatively few files that got modified (by me) --
only the *pre*-modification versions of *those* files
end up on the saved snapshot.
PLEASE: is that true?
Things I never modified never end up on a snapshot. PLEASE --
and is that correct?
QUESTION: So what use is that tape, taken to a fresh machine?
-----
Worse yet, suppose you had made lots of level 0 ufsdumps
on your prior sun UFS-bassed machine.
BUT you don't remember *which one*
you originally ufsrestored to the zfs-machine.
So you have no way to recreate
the machine (and os version and patch-level) you had before
you did that first snapshot.
Please: Is that true?
So what use is that "zfs send" tape going to be
on this 2nd, new replacement machine?
EVEN WORSE YET, they (sun manuals) say how easy it is
to get rid of a old snapshot, via zfs destroy. And you've
stupidly get rid of some of those way-old snapshots.
Only later you learn about the -I option to zfs send. Its
existence implies you want to include all the snapshots
that were ever made. But the doc for "destroy" never
says, I think I recall, that if you *ever* plan to use
"send -I", better not use destroy.
Look, from my blather, you can see that I am missing a
good mental model of zfs, what it *really* does, how
it *really* works, and how in the real world *people actually
use it*.
(I totally blame Sun for this. The course-videos on Solaris
10 never discuss all this. Nor even the $50 zfs-course dvd from
Oracle goes into that.)
--------- "clones":
(OT but FYI: I have never, never, never understood what I'd
actually use the clone-feature for.)
NEW SUBJECT:
------------------------------- re: star and 50pg man page:
which I have to hold in my head at one time, before
I can totally understand or grok it.
SO many switches. I just don't have enough
background to understand, for most of them,
WHY he had to add them, what problem they solved
(back then), a sentence or two of scenarios in
which you'd need a given one of them.
You guys, unlike me, do now or at least for some
period of time have worked in a group of people,
and by discussions etc you taught each other, or
leaned by osmosis.
Or look at Bell Labs or Berkeley or the AI lab, where
all these guys (geniuses all) taught each other.
Me, ever since I left school, have been pretty much
on my own.
Some people can read a book or man page and instantly
say to themselves, "Cool -- I see exactly how I can
apply this thing (option, say)."
Anyway, that's the situation. I need more handholding,
*repetitive* handholding on the same thing, and
even then (lousy memory since birth) I have to
document it in my own words.
And of course I can't get that on STAR.
----
Thanks for perserving through this long followup,
which I should have retitled and made into TWO
followups, one on zfs send and one on star.
David
John D Groenveld <groe...@cse.psu.edu> wrote:
>In article <k03nd3$fn2$1...@panix1.panix.com>,
>David Combs <dkc...@panix.com> wrote:
>>It's a zfs file-system, but since zfs incredibly has no way to
>>do true backups (to a file, disk, or tape, to take off-site),
>>am using what zfs-best-practices suggested, tar.
>
>zfs(1M) snapshot and send work for me.
><URL:http://docs.oracle.com/cd/E23824_01/html/821-1462/zfs-1m.html#scrolltoc>
>
>What's failing for you?
Here I show my really basic misunderstanding,
>In article <k03nd3$fn2$1...@panix1.panix.com>,
>David Combs <dkc...@panix.com> wrote:
>>It's a zfs file-system, but since zfs incredibly has no way to
>>do true backups (to a file, disk, or tape, to take off-site),
>>am using what zfs-best-practices suggested, tar.
>
>zfs(1M) snapshot and send work for me.
><URL:http://docs.oracle.com/cd/E23824_01/html/821-1462/zfs-1m.html#scrolltoc>
>
>What's failing for you?
lack of a decent, actually useful zfs mental model:
Yeah, but what does it send, that you can use on
another (*fresh*, solaris zfs) machine?
It is really a basic misunderstanding of mine:
don't you have to have on the machine the basic
data that you originally put there via ufsrestore.
Gigabytes of stuff from a lev-0 dump on a UFS machine.
Say I make a snapshot soon after I do the ufsrestore.
I then put ("send") the snapshot to a tape.
Machine crashes and dies.
BIG QUESTION: What use is that tape? What's on it?
As I understand
it, the relatively few files that got modified (by me) --
only the *pre*-modification versions of *those* files
end up on the saved snapshot.
PLEASE: is that true?
Things I never modified never end up on a snapshot. PLEASE --
and is that correct?
QUESTION: So what use is that tape, taken to a fresh machine?
-----
Worse yet, suppose you had made lots of level 0 ufsdumps
on your prior sun UFS-bassed machine.
BUT you don't remember *which one*
you originally ufsrestored to the zfs-machine.
So you have no way to recreate
the machine (and os version and patch-level) you had before
you did that first snapshot.
Please: Is that true?
So what use is that "zfs send" tape going to be
on this 2nd, new replacement machine?
EVEN WORSE YET, they (sun manuals) say how easy it is
to get rid of a old snapshot, via zfs destroy. And you've
stupidly get rid of some of those way-old snapshots.
Only later you learn about the -I option to zfs send. Its
existence implies you want to include all the snapshots
that were ever made. But the doc for "destroy" never
says, I think I recall, that if you *ever* plan to use
"send -I", better not use destroy.
Look, from my blather, you can see that I am missing a
good mental model of zfs, what it *really* does, how
it *really* works, and how in the real world *people actually
use it*.
(I totally blame Sun for this. The course-videos on Solaris
10 never discuss all this. Nor even the $50 zfs-course dvd from
Oracle goes into that.)
--------- "clones":
(OT but FYI: I have never, never, never understood what I'd
actually use the clone-feature for.)
NEW SUBJECT:
------------------------------- re: star and 50pg man page:
>
>>It's *way* over my head. (I've communicated with him,
>>and his response was that (his) star man-page was completly
>>straightforward, and should be no problem
>>reading and understand it. Something like that.)
>
>I found Joerg Schilling's manpage readable.
For my brain, there's just way too much stuff all of
>>It's *way* over my head. (I've communicated with him,
>>and his response was that (his) star man-page was completly
>>straightforward, and should be no problem
>>reading and understand it. Something like that.)
>
>I found Joerg Schilling's manpage readable.
which I have to hold in my head at one time, before
I can totally understand or grok it.
SO many switches. I just don't have enough
background to understand, for most of them,
WHY he had to add them, what problem they solved
(back then), a sentence or two of scenarios in
which you'd need a given one of them.
You guys, unlike me, do now or at least for some
period of time have worked in a group of people,
and by discussions etc you taught each other, or
leaned by osmosis.
Or look at Bell Labs or Berkeley or the AI lab, where
all these guys (geniuses all) taught each other.
Me, ever since I left school, have been pretty much
on my own.
Some people can read a book or man page and instantly
say to themselves, "Cool -- I see exactly how I can
apply this thing (option, say)."
Anyway, that's the situation. I need more handholding,
*repetitive* handholding on the same thing, and
even then (lousy memory since birth) I have to
document it in my own words.
And of course I can't get that on STAR.
----
Thanks for perserving through this long followup,
which I should have retitled and made into TWO
followups, one on zfs send and one on star.
David
David Combs
Aug 11, 2012, 4:24:15 AM8/11/12
to
In article <50259dd4$0$74854$8046...@newsreader.iphouse.net>,
Well, yes, it "works" ok, but my incorrect
mental model of zfs, snapshots, and send
(with -r or -R, for instance) doesn't,
as I misunderstand it, do me any good in
trying to do the equivalent, sort of,
the UFS ufsdump command.
I just don't see how I could possibly make use
of it to do what I need, ie to duplicate
a pool and take it to another machine.
You will see another post here from me that
details what I don't really understand
about zfs.
Perhaps you could give a try at explaning to me
the *value* of send, if you want to be able
to use it's output on a DIFFERENT machine.
---
Would clones be of any use here?
Do note that I have read about them,
but have never been able to understand
what they are actually used for.
Thanks!
David
PS: oh, what about rsync? Might that work better
than either sun or gnu tar?
mental model of zfs, snapshots, and send
(with -r or -R, for instance) doesn't,
as I misunderstand it, do me any good in
trying to do the equivalent, sort of,
the UFS ufsdump command.
I just don't see how I could possibly make use
of it to do what I need, ie to duplicate
a pool and take it to another machine.
You will see another post here from me that
details what I don't really understand
about zfs.
Perhaps you could give a try at explaning to me
the *value* of send, if you want to be able
to use it's output on a DIFFERENT machine.
---
Would clones be of any use here?
Do note that I have read about them,
but have never been able to understand
what they are actually used for.
Thanks!
David
PS: oh, what about rsync? Might that work better
than either sun or gnu tar?
John D Groenveld
Aug 11, 2012, 11:39:24 AM8/11/12
to
In article <k054re$9vg$1...@reader1.panix.com>,
like backup?
What is the outputs of zpool(1M) list and zfs(1M) list?
John
groe...@acm.org
David Combs <dkc...@panix.com> wrote:
>I just don't see how I could possibly make use
>of it to do what I need, ie to duplicate
>a pool and take it to another machine.
What's the ZFS configuration of your system you would
>I just don't see how I could possibly make use
>of it to do what I need, ie to duplicate
>a pool and take it to another machine.
like backup?
What is the outputs of zpool(1M) list and zfs(1M) list?
John
groe...@acm.org
John D Groenveld
Aug 11, 2012, 12:34:16 PM8/11/12
to
In article <k04g76$o6t$1...@reader1.panix.com>,
star?
What device will you be archiving to?
How is the device connected to your SunBlade 2500?
John
groe...@acm.org
David Combs <dkc...@panix.com> wrote:
>For my brain, there's just way too much stuff all of
>which I have to hold in my head at one time, before
>I can totally understand or grok it.
What filesystems do wish to archive with Joerg Schilling's
>For my brain, there's just way too much stuff all of
>which I have to hold in my head at one time, before
>I can totally understand or grok it.
star?
What device will you be archiving to?
How is the device connected to your SunBlade 2500?
John
groe...@acm.org
David Combs
Aug 11, 2012, 10:20:16 PM8/11/12
to
In article <k061i8$dg68$1...@tr22n12.aset.psu.edu>,
----------------------------------------- MY REPLY:
(First, in my post, which yours is a followup to (and this
to that), there is a pretty obvious missing "not". But being
I am in followup-mode in vi, I can't see that right now.)
(1) >What filesystems do wish to archive with Joerg Schilling's
>star?
-- Here's yet another chance for me to prove how
few of zfs-concepts I truly understand:
Stupidly, when a friend of mine installed solaris-10, and chose
the zfs-option, not only did the entire OS (bin, etc, ...) but
also all my data, ended up in the same zfs filesystem.
The same one and only zfs filesystem on the computer.
However, last night I belatedly discovered that zfs list
has a -t ("type") option, 3 possible values:
filesystem, snapshot, and volume.
So in answer to your question, here's a zfs list -t filesystem:
>
> zfs list -t filesystem
NAME USED AVAIL REFER MOUNTPOINT
dkc_rpool 95.5G 38.4G 96K /dkc_rpool
dkc_rpool/ROOT 51.9G 38.4G 18K legacy
dkc_rpool/ROOT/s10s_u7wos_08 51.9G 38.4G 50.3G /
dkc_rpool/export 24.8G 38.4G 22K /export
dkc_rpool/export/home 24.8G 38.4G 23.2G /export/home
>
>
As far as I know, all the directories that *I* know of, ie
the OS (/bin, /etc, /opt, /whatever) plus all the others (my data)
that I loaded on -- it's ALL in dkc_rpool.
Which the zfs list says is mounted at /dkc_rpool.
Here is a somewhat off-topic question that is very
subsidiary to what my (this) thread is asking:
(When I'm on the 2500, root is at "/", of course. Not
at /dkc_rpool/. But again, in the zfs list, it lists
filesystem "dkc_rpool" being mounted "at" /dkc_rpool.
Question: the first slash in this paragraph is what
I know as root. Now, the slash at the left of the
MOUNTPOINT /dkc_rpool -- just what is THAT slash?
And when you answer that, please tell me where or how you
*learned* it: what manual or blog or whatever did you
find it explained? THANKS! )
So as to "which filesystem do I want to archive (by ANY method
that works, which does NOT include sun tar or gtar v26, because
they loop, but MIGHT include star, rsync, or even "cp -p -r"),
the filesystem to archive is dkc_rpool.
(Of course, the REAL problem might be a cycle within the
zfs directory "tree", which might not actually a tree anymore,
due to some bug-caused cycle or loop. (symlinks when traversed
might cycle, but tar says as default it does NOT "follow"
symlinks, just records as a text string it's target. Thus
a loop couldn't come from there).
Subsidiary question: how does one debug or verify a
zfs structure?)
2: >What device will you be archiving to?
An NAS (Net-Attached Storage, something I never heard
of until maybe five days ago) DLINK box now containing
TWO 2 terabyte disks, mirrored by the box.
The box (refurbished, ok because no moving parts, $100) came
from TigerDirect, and the two disks from Amazon.
The box is via ethernet-cable on our little household LAN.
(FYI: what's amazing to me is that on my DELL $600 desktop,
in (windows) gnu emacs I can dired that box and look at the files
that are in it! Maybe obvious to you, but a nice
surprise to me.)
Anyway, that is the device I want to archive into.
>How is the device connected to your SunBlade 2500?
This question got answered just above -- via ethernet
cable plugged into the ethernet plug on it, which
finally ends up at the router.
As does the Sunblade 2500 also end up there, same
mechanism.
Ditto for this Dell desktop I'm now typing on, in
a putty (wonderful, wonderful program!) window to
panix.
FYI: A 50-ft DB-9 null-modem cable connects this Dell
to the 2500 upstairs.
Meaning that via the logmein helpdesk service,
a friend up in
Calgary can share my Dell with me, including
mouse, keyboard, etc, and via the cable
plugged into the sun upstairs (keyboard and
monitor up there UNPLUGGED), a putty to its address
lets him (or me) run it from the Dell.
(Even
using the emacs on it, working in vt100 or
similar mode), just the way I do on panix.)
That possibility I had never heard of until maybe
two weeks ago, amazingly cool this logmein
AND null-modem cable (then homebrew cable
last used 30 years ago)!
Subsidiary trailing question:
About rsync, the wikipedia page on it
seems pretty instructive to me. Also
contains a wiki link to all the programs
that are *based on* rsync, a whole bunch
of them!
"cp -r" has been suggested. Compared to
tar, gtar, star, and rsync, does that make
any sense?
Thanks so much for all the effort you (and others)
are putting into helping out. I really
appreciate it!
David
John D Groenveld <groe...@cse.psu.edu> wrote:
(First, in my post, which yours is a followup to (and this
to that), there is a pretty obvious missing "not". But being
I am in followup-mode in vi, I can't see that right now.)
(1) >What filesystems do wish to archive with Joerg Schilling's
>star?
-- Here's yet another chance for me to prove how
few of zfs-concepts I truly understand:
Stupidly, when a friend of mine installed solaris-10, and chose
the zfs-option, not only did the entire OS (bin, etc, ...) but
also all my data, ended up in the same zfs filesystem.
The same one and only zfs filesystem on the computer.
However, last night I belatedly discovered that zfs list
has a -t ("type") option, 3 possible values:
filesystem, snapshot, and volume.
So in answer to your question, here's a zfs list -t filesystem:
>
> zfs list -t filesystem
NAME USED AVAIL REFER MOUNTPOINT
dkc_rpool 95.5G 38.4G 96K /dkc_rpool
dkc_rpool/ROOT 51.9G 38.4G 18K legacy
dkc_rpool/ROOT/s10s_u7wos_08 51.9G 38.4G 50.3G /
dkc_rpool/export 24.8G 38.4G 22K /export
dkc_rpool/export/home 24.8G 38.4G 23.2G /export/home
>
>
As far as I know, all the directories that *I* know of, ie
the OS (/bin, /etc, /opt, /whatever) plus all the others (my data)
that I loaded on -- it's ALL in dkc_rpool.
Which the zfs list says is mounted at /dkc_rpool.
Here is a somewhat off-topic question that is very
subsidiary to what my (this) thread is asking:
(When I'm on the 2500, root is at "/", of course. Not
at /dkc_rpool/. But again, in the zfs list, it lists
filesystem "dkc_rpool" being mounted "at" /dkc_rpool.
Question: the first slash in this paragraph is what
I know as root. Now, the slash at the left of the
MOUNTPOINT /dkc_rpool -- just what is THAT slash?
And when you answer that, please tell me where or how you
*learned* it: what manual or blog or whatever did you
find it explained? THANKS! )
So as to "which filesystem do I want to archive (by ANY method
that works, which does NOT include sun tar or gtar v26, because
they loop, but MIGHT include star, rsync, or even "cp -p -r"),
the filesystem to archive is dkc_rpool.
(Of course, the REAL problem might be a cycle within the
zfs directory "tree", which might not actually a tree anymore,
due to some bug-caused cycle or loop. (symlinks when traversed
might cycle, but tar says as default it does NOT "follow"
symlinks, just records as a text string it's target. Thus
a loop couldn't come from there).
Subsidiary question: how does one debug or verify a
zfs structure?)
2: >What device will you be archiving to?
An NAS (Net-Attached Storage, something I never heard
of until maybe five days ago) DLINK box now containing
TWO 2 terabyte disks, mirrored by the box.
The box (refurbished, ok because no moving parts, $100) came
from TigerDirect, and the two disks from Amazon.
The box is via ethernet-cable on our little household LAN.
(FYI: what's amazing to me is that on my DELL $600 desktop,
in (windows) gnu emacs I can dired that box and look at the files
that are in it! Maybe obvious to you, but a nice
surprise to me.)
Anyway, that is the device I want to archive into.
>How is the device connected to your SunBlade 2500?
cable plugged into the ethernet plug on it, which
finally ends up at the router.
As does the Sunblade 2500 also end up there, same
mechanism.
Ditto for this Dell desktop I'm now typing on, in
a putty (wonderful, wonderful program!) window to
panix.
FYI: A 50-ft DB-9 null-modem cable connects this Dell
to the 2500 upstairs.
Meaning that via the logmein helpdesk service,
a friend up in
Calgary can share my Dell with me, including
mouse, keyboard, etc, and via the cable
plugged into the sun upstairs (keyboard and
monitor up there UNPLUGGED), a putty to its address
lets him (or me) run it from the Dell.
(Even
using the emacs on it, working in vt100 or
similar mode), just the way I do on panix.)
That possibility I had never heard of until maybe
two weeks ago, amazingly cool this logmein
AND null-modem cable (then homebrew cable
last used 30 years ago)!
Subsidiary trailing question:
About rsync, the wikipedia page on it
seems pretty instructive to me. Also
contains a wiki link to all the programs
that are *based on* rsync, a whole bunch
of them!
"cp -r" has been suggested. Compared to
tar, gtar, star, and rsync, does that make
any sense?
Thanks so much for all the effort you (and others)
are putting into helping out. I really
appreciate it!
David
David Combs
Aug 11, 2012, 10:38:28 PM8/11/12
to
In article <k05ubb$ok6u$1...@tr22n12.aset.psu.edu>,
Solaris 10 and did the configuring.
I will let him answer that one, which answer I'll
"followup" with here.
>What is the outputs of zpool(1M) list and zfs(1M) list?
I think I showed the zfs list elsewhere in this thread
or in a prior thread, but I'll do it again now:
>
> zfs list -t filesystem
NAME USED AVAIL REFER MOUNTPOINT
dkc_rpool 95.5G 38.4G 96K /dkc_rpool
dkc_rpool/ROOT 51.9G 38.4G 18K legacy
dkc_rpool/ROOT/s10s_u7wos_08 51.9G 38.4G 50.3G /
dkc_rpool/export 24.8G 38.4G 22K /export
dkc_rpool/export/home 24.8G 38.4G 23.2G /export/home
>
> zfs list -t snapshot
dkc_rpool@8pm-2oct11 0 - 94K -
dkc_rpool@9oct11 0 - 94K -
dkc_rpool@23oct11 0 - 94K -
dkc_rpool@26oct11-145am 0 - 94K -
dkc_rpool@28oct11-125am 0 - 94K -
dkc_rpool@1nov11-219am 0 - 94K -
dkc_rpool@15jan2012 0 - 96K -
dkc_rpool@snap-sat11feb12 0 - 96K -
dkc_rpool@snap-mon23apr12 0 - 96K -
dkc_rpool@snap-mon29apr12 0 - 96K -
dkc_rpool@snap-tue30apr12 0 - 96K -
dkc_rpool@snap-sat12may12 0 - 96K -
dkc_rpool@snap-tue29may12 0 - 96K -
dkc_rpool@snap-mon18june12 0 - 96K -
dkc_rpool@snap-to-send-to-dlink-NAS--9aug12 0 - 96K -
dkc_rpool/ROOT@27aug11-snap 0 - 18K -
dkc_rpool/ROOT@8pm-2oct11 0 - 18K -
dkc_rpool/ROOT@9oct11 0 - 18K -
dkc_rpool/ROOT@23oct11 0 - 18K -
dkc_rpool/ROOT@26oct11-145am 0 - 18K -
dkc_rpool/ROOT@28oct11-125am 0 - 18K -
dkc_rpool/ROOT@1nov11-219am 0 - 18K -
dkc_rpool/ROOT@15jan2012 0 - 18K -
dkc_rpool/ROOT@1feb12-snap 0 - 18K -
dkc_rpool/ROOT@snap-to-send-to-dlink-NAS--9aug12 0 - 18K -
dkc_rpool/ROOT/s10s_u7wos_08@27aug11-snap 132M - 49.2G -
dkc_rpool/ROOT/s10s_u7wos_08@8pm-2oct11 11.4M - 50.4G -
dkc_rpool/ROOT/s10s_u7wos_08@9oct11 992K - 50.4G -
dkc_rpool/ROOT/s10s_u7wos_08@23oct11 826K - 50.4G -
dkc_rpool/ROOT/s10s_u7wos_08@26oct11-145am 708K - 50.4G -
dkc_rpool/ROOT/s10s_u7wos_08@28oct11-125am 770K - 50.4G -
dkc_rpool/ROOT/s10s_u7wos_08@1nov11-219am 1.03M - 50.4G -
dkc_rpool/ROOT/s10s_u7wos_08@15jan2012 113M - 51.2G -
dkc_rpool/ROOT/s10s_u7wos_08@snap-to-send-to-dlink-NAS--9aug12 626K - 50.3G -
dkc_rpool/dump@27aug11-snap 16K - 4.00G -
dkc_rpool/dump@8pm-2oct11 0 - 4.00G -
dkc_rpool/dump@9oct11 0 - 4.00G -
dkc_rpool/dump@23oct11 0 - 4.00G -
dkc_rpool/dump@26oct11-145am 0 - 4.00G -
dkc_rpool/dump@28oct11-125am 0 - 4.00G -
dkc_rpool/dump@1nov11-219am 0 - 4.00G -
dkc_rpool/dump@15jan2012 16K - 4.00G -
dkc_rpool/dump@snap-to-send-to-dlink-NAS--9aug12 0 - 4.00G -
dkc_rpool/export@27aug11-snap 16K - 20K -
dkc_rpool/export@8pm-2oct11 0 - 20K -
dkc_rpool/export@9oct11 0 - 20K -
dkc_rpool/export@23oct11 0 - 20K -
dkc_rpool/export@26oct11-145am 0 - 20K -
dkc_rpool/export@28oct11-125am 0 - 20K -
dkc_rpool/export@1nov11-219am 0 - 20K -
dkc_rpool/export@15jan2012 16K - 22K -
dkc_rpool/export@snap-to-send-to-dlink-NAS--9aug12 0 - 22K -
dkc_rpool/export/home@27aug11-snap 342M - 22.3G -
dkc_rpool/export/home@8pm-2oct11 11.9M - 23.5G -
dkc_rpool/export/home@9oct11 28.1M - 23.5G -
dkc_rpool/export/home@23oct11 2.65M - 23.5G -
dkc_rpool/export/home@26oct11-145am 694K - 23.5G -
dkc_rpool/export/home@28oct11-125am 1.04M - 23.5G -
dkc_rpool/export/home@1nov11-219am 809K - 23.5G -
dkc_rpool/export/home@15jan2012 75.2M - 23.9G -
dkc_rpool/export/home@snap-to-send-to-dlink-NAS--9aug12 41.5K - 23.2G -
dkc_rpool/swap@27aug11-snap 2.34G - 4.05G -
dkc_rpool/swap@8pm-2oct11 48K - 4.05G -
dkc_rpool/swap@9oct11 46K - 4.05G -
dkc_rpool/swap@23oct11 0 - 4.05G -
dkc_rpool/swap@26oct11-145am 0 - 4.05G -
dkc_rpool/swap@28oct11-125am 0 - 4.05G -
dkc_rpool/swap@1nov11-219am 20K - 4.05G -
dkc_rpool/swap@15jan2012 257M - 4.05G -
dkc_rpool/swap@snap-to-send-to-dlink-NAS--9aug12 0 - 4.05G -
>
> zfs list -t volume
dkc_rpool/swap 14.8G 42.4G 4.05G -
>
The rpool list I cannot get right now, since the putty
to the sun came down when I rebooted this PC last
night, and I don't have documented how to putty
into the sun and then log in. But let me try
right now.
...
Nope, I don't have its net address, not yet documented
from my friend.
Will get the zpool list in a few hours.
David
>
>John
>groe...@acm.org
John D Groenveld <groe...@cse.psu.edu> wrote:
>In article <k054re$9vg$1...@reader1.panix.com>,
>David Combs <dkc...@panix.com> wrote:
>>I just don't see how I could possibly make use
>>of it to do what I need, ie to duplicate
>>a pool and take it to another machine.
>
>What's the ZFS configuration of your system you would
>like backup?
"Configuration" I know nothing about. Someone else installed
>David Combs <dkc...@panix.com> wrote:
>>I just don't see how I could possibly make use
>>of it to do what I need, ie to duplicate
>>a pool and take it to another machine.
>
>What's the ZFS configuration of your system you would
>like backup?
Solaris 10 and did the configuring.
I will let him answer that one, which answer I'll
"followup" with here.
>What is the outputs of zpool(1M) list and zfs(1M) list?
or in a prior thread, but I'll do it again now:
>
> zfs list -t filesystem
NAME USED AVAIL REFER MOUNTPOINT
dkc_rpool 95.5G 38.4G 96K /dkc_rpool
dkc_rpool/ROOT 51.9G 38.4G 18K legacy
dkc_rpool/ROOT/s10s_u7wos_08 51.9G 38.4G 50.3G /
dkc_rpool/export 24.8G 38.4G 22K /export
dkc_rpool/export/home 24.8G 38.4G 23.2G /export/home
>
NAME USED AVAIL REFER MOUNTPOINT
dkc_rpool@27aug11-snap 17K - 94K -
dkc_rpool@8pm-2oct11 0 - 94K -
dkc_rpool@9oct11 0 - 94K -
dkc_rpool@23oct11 0 - 94K -
dkc_rpool@26oct11-145am 0 - 94K -
dkc_rpool@28oct11-125am 0 - 94K -
dkc_rpool@1nov11-219am 0 - 94K -
dkc_rpool@15jan2012 0 - 96K -
dkc_rpool@snap-sat11feb12 0 - 96K -
dkc_rpool@snap-mon23apr12 0 - 96K -
dkc_rpool@snap-mon29apr12 0 - 96K -
dkc_rpool@snap-tue30apr12 0 - 96K -
dkc_rpool@snap-sat12may12 0 - 96K -
dkc_rpool@snap-tue29may12 0 - 96K -
dkc_rpool@snap-mon18june12 0 - 96K -
dkc_rpool@snap-to-send-to-dlink-NAS--9aug12 0 - 96K -
dkc_rpool/ROOT@27aug11-snap 0 - 18K -
dkc_rpool/ROOT@8pm-2oct11 0 - 18K -
dkc_rpool/ROOT@9oct11 0 - 18K -
dkc_rpool/ROOT@23oct11 0 - 18K -
dkc_rpool/ROOT@26oct11-145am 0 - 18K -
dkc_rpool/ROOT@28oct11-125am 0 - 18K -
dkc_rpool/ROOT@1nov11-219am 0 - 18K -
dkc_rpool/ROOT@15jan2012 0 - 18K -
dkc_rpool/ROOT@1feb12-snap 0 - 18K -
dkc_rpool/ROOT@snap-to-send-to-dlink-NAS--9aug12 0 - 18K -
dkc_rpool/ROOT/s10s_u7wos_08@27aug11-snap 132M - 49.2G -
dkc_rpool/ROOT/s10s_u7wos_08@8pm-2oct11 11.4M - 50.4G -
dkc_rpool/ROOT/s10s_u7wos_08@9oct11 992K - 50.4G -
dkc_rpool/ROOT/s10s_u7wos_08@23oct11 826K - 50.4G -
dkc_rpool/ROOT/s10s_u7wos_08@26oct11-145am 708K - 50.4G -
dkc_rpool/ROOT/s10s_u7wos_08@28oct11-125am 770K - 50.4G -
dkc_rpool/ROOT/s10s_u7wos_08@1nov11-219am 1.03M - 50.4G -
dkc_rpool/ROOT/s10s_u7wos_08@15jan2012 113M - 51.2G -
dkc_rpool/ROOT/s10s_u7wos_08@snap-to-send-to-dlink-NAS--9aug12 626K - 50.3G -
dkc_rpool/dump@27aug11-snap 16K - 4.00G -
dkc_rpool/dump@8pm-2oct11 0 - 4.00G -
dkc_rpool/dump@9oct11 0 - 4.00G -
dkc_rpool/dump@23oct11 0 - 4.00G -
dkc_rpool/dump@26oct11-145am 0 - 4.00G -
dkc_rpool/dump@28oct11-125am 0 - 4.00G -
dkc_rpool/dump@1nov11-219am 0 - 4.00G -
dkc_rpool/dump@15jan2012 16K - 4.00G -
dkc_rpool/dump@snap-to-send-to-dlink-NAS--9aug12 0 - 4.00G -
dkc_rpool/export@27aug11-snap 16K - 20K -
dkc_rpool/export@8pm-2oct11 0 - 20K -
dkc_rpool/export@9oct11 0 - 20K -
dkc_rpool/export@23oct11 0 - 20K -
dkc_rpool/export@26oct11-145am 0 - 20K -
dkc_rpool/export@28oct11-125am 0 - 20K -
dkc_rpool/export@1nov11-219am 0 - 20K -
dkc_rpool/export@15jan2012 16K - 22K -
dkc_rpool/export@snap-to-send-to-dlink-NAS--9aug12 0 - 22K -
dkc_rpool/export/home@27aug11-snap 342M - 22.3G -
dkc_rpool/export/home@8pm-2oct11 11.9M - 23.5G -
dkc_rpool/export/home@9oct11 28.1M - 23.5G -
dkc_rpool/export/home@23oct11 2.65M - 23.5G -
dkc_rpool/export/home@26oct11-145am 694K - 23.5G -
dkc_rpool/export/home@28oct11-125am 1.04M - 23.5G -
dkc_rpool/export/home@1nov11-219am 809K - 23.5G -
dkc_rpool/export/home@15jan2012 75.2M - 23.9G -
dkc_rpool/export/home@snap-to-send-to-dlink-NAS--9aug12 41.5K - 23.2G -
dkc_rpool/swap@27aug11-snap 2.34G - 4.05G -
dkc_rpool/swap@8pm-2oct11 48K - 4.05G -
dkc_rpool/swap@9oct11 46K - 4.05G -
dkc_rpool/swap@23oct11 0 - 4.05G -
dkc_rpool/swap@26oct11-145am 0 - 4.05G -
dkc_rpool/swap@28oct11-125am 0 - 4.05G -
dkc_rpool/swap@1nov11-219am 20K - 4.05G -
dkc_rpool/swap@15jan2012 257M - 4.05G -
dkc_rpool/swap@snap-to-send-to-dlink-NAS--9aug12 0 - 4.05G -
>
> zfs list -t volume
NAME USED AVAIL REFER MOUNTPOINT
dkc_rpool/dump 4.00G 38.4G 4.00G -
dkc_rpool/swap 14.8G 42.4G 4.05G -
>
The rpool list I cannot get right now, since the putty
to the sun came down when I rebooted this PC last
night, and I don't have documented how to putty
into the sun and then log in. But let me try
right now.
...
Nope, I don't have its net address, not yet documented
from my friend.
Will get the zpool list in a few hours.
David
>
>John
>groe...@acm.org
John D Groenveld
Aug 11, 2012, 11:02:00 PM8/11/12
to
In article <k074v4$p8d$1...@reader1.panix.com>,
Assuming your Dlink NAS filesystem is mounted on /mnt
# zfs send -R dkc_rpool@snap-to-send-to-dlink-NAS--9aug12 >/mnt/dkc_rpool.snapshot
# zfs send -R dkc_rpool/ROOT@snap-to-send-to-dlink-NAS--9aug12 >/mnt/dkc_rpool_ROOT.snapshot
# zfs send -R dkc_rpool/ROOT/s10s_u7wos_08@snap-to-send-to-dlink-NAS--9aug12 >/mnt/dkc_rpool_ROOT_s10s_u7wos_08.snapshot
# zfs send -R dkc_rpool/export@snap-to-send-to-dlink-NAS--9aug12 >/mnt/dkc_rpool_export.snapshot
# zfs send -R dkc_rpool/export/home@snap-to-send-to-dlink-NAS--9aug12 >/mnt/dkc_rpool_export_home.snapshot
Mount you Dlink NAS filesystem on your failover box and
confirm you can zfs(1M) receive those snapshots.
John
groe...@acm.org
# zfs send -R dkc_rpool@snap-to-send-to-dlink-NAS--9aug12 >/mnt/dkc_rpool.snapshot
# zfs send -R dkc_rpool/ROOT@snap-to-send-to-dlink-NAS--9aug12 >/mnt/dkc_rpool_ROOT.snapshot
# zfs send -R dkc_rpool/ROOT/s10s_u7wos_08@snap-to-send-to-dlink-NAS--9aug12 >/mnt/dkc_rpool_ROOT_s10s_u7wos_08.snapshot
# zfs send -R dkc_rpool/export@snap-to-send-to-dlink-NAS--9aug12 >/mnt/dkc_rpool_export.snapshot
# zfs send -R dkc_rpool/export/home@snap-to-send-to-dlink-NAS--9aug12 >/mnt/dkc_rpool_export_home.snapshot
Mount you Dlink NAS filesystem on your failover box and
confirm you can zfs(1M) receive those snapshots.
John
groe...@acm.org
David Combs
Aug 12, 2012, 6:32:12 AM8/12/12
to
In article <k076b8$lk2c$1...@tr22n12.aset.psu.edu>,
So, you got those from:
>
> zfs list -t filesystem
NAME USED AVAIL REFER MOUNTPOINT
dkc_rpool 95.5G 38.4G 96K /dkc_rpool
dkc_rpool/ROOT 51.9G 38.4G 18K legacy
dkc_rpool/ROOT/s10s_u7wos_08 51.9G 38.4G 50.3G /
dkc_rpool/export 24.8G 38.4G 22K /export
dkc_rpool/export/home 24.8G 38.4G 23.2G /export/home
Until I saw that -t filesystem option and did the
zfs list -t filesystem, I had no idea I had all
those filesystems.
And have no idea why they exist.
I thought that if I did a tar from "/", in dkc_rpool,
I think, that I had everything covered, and the output
tar file would be of size 95g.
Now, does tar, if starting at "/" in dkc_rpool,
grab those other four filesystems too.
I see in that zfs list -t filesystem this
line that REALLY confuses me:
dkc_rpool/ROOT/s10s_u7wos_08 51.9G 38.4G 50.3G /
It's mountpoint, it says, is "/". Is that the
same "/" that I refer to as "ROOT" and
cd to before giving that tar cf /dlink/tarfile.tar cmd?
And yet there is another "filesystem" in that list
with mountpoint ROOT.
Please, John, what can I read to maybe comprehend
these to-me weird goings on? Something that
explains in an understandable way the BASE
CONCEPTS
(of how zfs WORKS "inside", maybe,
some the internal mechanisms and more important
data-structures, good for someone like me
who unfortunately has always thought and
best understood things "bottom up"!).
Or can you or anyone else reading my ignorant and
idiotic responses perhaps explain some of this that way,
bottom up?
(There MUST be other people who, like I, don't understand
zfs either, but are, like in a high-school classroom,
afraid to open their mouths, but need to approach
it from HOW IT WORKS. Otherwise it's just a "black box"
with only the interfaces described, and poorly at that.
Some of us have to know what's IN the black box.)
>Mount you Dlink NAS filesystem on your failover box and
>confirm you can zfs(1M) receive those snapshots.
I'm confused -- the "failover box" would be a new sparc
computer, with solaris 10 (and zfs filesystem already
set up on it, but VERY LITTLE DATA in it.
What would be the RESULT of receiving those "send"
outputs?
QUESTION: Please, what would a zfs list look like after
that?
And how much of the old disk would now
be "in" the new machine's zfs's and pools.
And what would a zpool list look like -- probably
the same as before.
Unfortunately, very unfortunately, the tar jobs that we've run,
rooted at /
via: cd / then "tar cf /dlink/tar-output-of-root.tar .",
where the total size was some 90gig, produced that
output .tar-file that was HUGE, 200gig -- at which
point I killed the tar, figuring it was somehow
looping.
>
>John
>groe...@acm.org
Here, in this dired of /, is the mount point, /dlink:
/:
total 163848
drwxr-xr-x 37 root root 94 Aug 9 16:17 .
drwxr-xr-x 37 root root 94 Aug 9 16:17 ..
drwx------ 3 root root 3 Jun 16 2009 .sunw
-rw-r--r-- 1 10101 staff 629 Sep 11 2011 .tcshrc
lrwxrwxrwx 1 root root 24 Aug 17 2011 4msnew -> /taperestore/hdkc/4msnew
...
...
drwxrwxrwx 3 501 501 4096 Aug 10 06:09 dlink
And here is the dired of that:
/dlink:
total 547955001
drwxrwxrwx 3 501 501 4096 Aug 10 06:09 .
drwxr-xr-x 37 root root 94 Aug 9 16:17 ..
drwxr-xr-x 10 501 501 4096 Aug 9 07:01 cpbackup
-rwxrwxrwx 1 501 501 211683016704 Aug 10 15:51 dkc-huge-via-gnu-tar--608am-10aug12.tar
-rwxrwxrwx 1 501 501 68595936768 Aug 9 05:52 mainbackup.tar
And here, finally, is the zpool list you wanted:
> pwd
/export/home/dkc
>
> zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
dkc_rpool 136G 91.7G 44.3G 67% ONLINE -
>
That's it, just that one line.
John, my friend keeps saying that I should be
using rsync. (I did a wikipedia on it; looks
pretty amazing, what it does, plus there's
a link to a page of all the products/programs
that either make use of rsync, or are variants
of it.)
Could you say something about rsync for backup,
compared to either sun or gnu tar. (Or even Star).
Then I can pass that on to him.
I have already emailed to him your post that this one
is a followup to.
Well, it is now 6:30am, and as you can see my mind
is totally trashed. Off to bed!
Thanks!
David
John D Groenveld <groe...@cse.psu.edu> wrote:
>
> zfs list -t filesystem
NAME USED AVAIL REFER MOUNTPOINT
dkc_rpool 95.5G 38.4G 96K /dkc_rpool
dkc_rpool/ROOT 51.9G 38.4G 18K legacy
dkc_rpool/ROOT/s10s_u7wos_08 51.9G 38.4G 50.3G /
dkc_rpool/export 24.8G 38.4G 22K /export
dkc_rpool/export/home 24.8G 38.4G 23.2G /export/home
zfs list -t filesystem, I had no idea I had all
those filesystems.
And have no idea why they exist.
I thought that if I did a tar from "/", in dkc_rpool,
I think, that I had everything covered, and the output
tar file would be of size 95g.
Now, does tar, if starting at "/" in dkc_rpool,
grab those other four filesystems too.
I see in that zfs list -t filesystem this
line that REALLY confuses me:
dkc_rpool/ROOT/s10s_u7wos_08 51.9G 38.4G 50.3G /
same "/" that I refer to as "ROOT" and
cd to before giving that tar cf /dlink/tarfile.tar cmd?
And yet there is another "filesystem" in that list
with mountpoint ROOT.
Please, John, what can I read to maybe comprehend
these to-me weird goings on? Something that
explains in an understandable way the BASE
CONCEPTS
(of how zfs WORKS "inside", maybe,
some the internal mechanisms and more important
data-structures, good for someone like me
who unfortunately has always thought and
best understood things "bottom up"!).
Or can you or anyone else reading my ignorant and
idiotic responses perhaps explain some of this that way,
bottom up?
(There MUST be other people who, like I, don't understand
zfs either, but are, like in a high-school classroom,
afraid to open their mouths, but need to approach
it from HOW IT WORKS. Otherwise it's just a "black box"
with only the interfaces described, and poorly at that.
Some of us have to know what's IN the black box.)
>Mount you Dlink NAS filesystem on your failover box and
>confirm you can zfs(1M) receive those snapshots.
computer, with solaris 10 (and zfs filesystem already
set up on it, but VERY LITTLE DATA in it.
What would be the RESULT of receiving those "send"
outputs?
QUESTION: Please, what would a zfs list look like after
that?
And how much of the old disk would now
be "in" the new machine's zfs's and pools.
And what would a zpool list look like -- probably
the same as before.
Unfortunately, very unfortunately, the tar jobs that we've run,
rooted at /
via: cd / then "tar cf /dlink/tar-output-of-root.tar .",
where the total size was some 90gig, produced that
output .tar-file that was HUGE, 200gig -- at which
point I killed the tar, figuring it was somehow
looping.
>
>John
>groe...@acm.org
Here, in this dired of /, is the mount point, /dlink:
/:
total 163848
drwxr-xr-x 37 root root 94 Aug 9 16:17 .
drwxr-xr-x 37 root root 94 Aug 9 16:17 ..
drwx------ 3 root root 3 Jun 16 2009 .sunw
-rw-r--r-- 1 10101 staff 629 Sep 11 2011 .tcshrc
lrwxrwxrwx 1 root root 24 Aug 17 2011 4msnew -> /taperestore/hdkc/4msnew
...
...
drwxrwxrwx 3 501 501 4096 Aug 10 06:09 dlink
And here is the dired of that:
/dlink:
total 547955001
drwxrwxrwx 3 501 501 4096 Aug 10 06:09 .
drwxr-xr-x 37 root root 94 Aug 9 16:17 ..
drwxr-xr-x 10 501 501 4096 Aug 9 07:01 cpbackup
-rwxrwxrwx 1 501 501 211683016704 Aug 10 15:51 dkc-huge-via-gnu-tar--608am-10aug12.tar
-rwxrwxrwx 1 501 501 68595936768 Aug 9 05:52 mainbackup.tar
And here, finally, is the zpool list you wanted:
> pwd
/export/home/dkc
>
> zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
dkc_rpool 136G 91.7G 44.3G 67% ONLINE -
>
That's it, just that one line.
John, my friend keeps saying that I should be
using rsync. (I did a wikipedia on it; looks
pretty amazing, what it does, plus there's
a link to a page of all the products/programs
that either make use of rsync, or are variants
of it.)
Could you say something about rsync for backup,
compared to either sun or gnu tar. (Or even Star).
Then I can pass that on to him.
I have already emailed to him your post that this one
is a followup to.
Well, it is now 6:30am, and as you can see my mind
is totally trashed. Off to bed!
Thanks!
David
oscar.d...@gmail.com
Aug 12, 2012, 10:49:03 AM8/12/12
to
On Sunday, 12 August 2012 06:32:12 UTC-4, David Combs wrote:
> Unfortunately, very unfortunately, the tar jobs that we've run,
> rooted at /
>
> via: cd / then "tar cf /dlink/tar-output-of-root.tar .",
>
> where the total size was some 90gig, produced that
> output .tar-file that was HUGE, 200gig -- at which
> point I killed the tar, figuring it was somehow
> looping.
> Unfortunately, very unfortunately, the tar jobs that we've run,
> rooted at /
>
> via: cd / then "tar cf /dlink/tar-output-of-root.tar .",
>
> where the total size was some 90gig, produced that
> output .tar-file that was HUGE, 200gig -- at which
> point I killed the tar, figuring it was somehow
> looping.
> Here, in this dired of /, is the mount point, /dlink:
> drwxrwxrwx 3 501 501 4096 Aug 10 06:09 dlink
>
> /dlink:
>
>
> total 547955001
> -rwxrwxrwx 1 501 501 211683016704 Aug 10 15:51 dkc-huge-via-gnu-tar--608am-10aug12.tar
You would need to tell tar to "eXclude" /dlink
For example create a text file /dlink/exclude.txt with 2 lines (one with the absolute path and another with the relative path to be safe)
/dlink
./dlink
Then use the X option of tar (and the v option to show what it's doing)
cd /
tar cvXf /dlink/exclude.txt /dlink/backup.tar .
see "man tar" for details about the X option.
You might also need to add /proc and maybe other special file systems to the exclude file...
David Combs
Aug 12, 2012, 3:34:02 PM8/12/12
to
In article <d9e31303-0d31-4088...@googlegroups.com>,
WOW! THANK YOU!
Obvious, too. And we sure didn't see it!
Here's the email I just sent to my friend:
subj line: SOLVED! *WE* caused loop, OBVIOUS. Try to figure it out BEFORE opening this email
*WE* (not just you) already KNEW that if we (you) set things up the
*way you did, and in fact the way you HAD to (no other choice), the
*results we got trying to backup were, had WE had our thinking hats on
*and pointed in a certain (but not esoteric) direction, it would have
*been obvious to us too. Each of us already KNEW the why to the
*problem observed. :-)
And, without changing anything in your setup, there was an also
obvious work-around, that each of us already knew, but also, like the
above, didn't rise to the surface, not when it was 3am, not when our
real worry was about mother-boards and disks and dlinks and ethernets
and sun tar vs gnu tar vs Star.
For fun, BEFORE reading the answer down below (and then slapping your
forehead HARD) :-), try to figure it out.
Again, a hint: it was something we (actually you, for me) did.
Have fun. :-)
David
PS: I want to see your forehead's red skin after you've slapped it so
hard!
(Sorry, when I said M-x fill-individual-paragraphs (email-lines WAY too long
for news group format), emacs saw that first (for emphasis) asterisk,
and decided I wanted it to be replicated to the left of every line. Again,
as above, something I already "knew" would happen!, but didn't think of it.)
I'll follow-up again after studying tar options, excludes, etc.
Quick question: WHICH tar to use, sun tar or gnu tar?
And do YOU know anything about STAR, ie s-tar (schilly-tar)?
Thanks again!
David
Obvious, too. And we sure didn't see it!
Here's the email I just sent to my friend:
subj line: SOLVED! *WE* caused loop, OBVIOUS. Try to figure it out BEFORE opening this email
*WE* (not just you) already KNEW that if we (you) set things up the
*way you did, and in fact the way you HAD to (no other choice), the
*results we got trying to backup were, had WE had our thinking hats on
*and pointed in a certain (but not esoteric) direction, it would have
*been obvious to us too. Each of us already KNEW the why to the
*problem observed. :-)
And, without changing anything in your setup, there was an also
obvious work-around, that each of us already knew, but also, like the
above, didn't rise to the surface, not when it was 3am, not when our
real worry was about mother-boards and disks and dlinks and ethernets
and sun tar vs gnu tar vs Star.
For fun, BEFORE reading the answer down below (and then slapping your
forehead HARD) :-), try to figure it out.
Again, a hint: it was something we (actually you, for me) did.
Have fun. :-)
David
PS: I want to see your forehead's red skin after you've slapped it so
hard!
(Sorry, when I said M-x fill-individual-paragraphs (email-lines WAY too long
for news group format), emacs saw that first (for emphasis) asterisk,
and decided I wanted it to be replicated to the left of every line. Again,
as above, something I already "knew" would happen!, but didn't think of it.)
I'll follow-up again after studying tar options, excludes, etc.
Quick question: WHICH tar to use, sun tar or gnu tar?
And do YOU know anything about STAR, ie s-tar (schilly-tar)?
Thanks again!
David
John D Groenveld
Aug 12, 2012, 6:34:17 PM8/12/12
to
In article <k073t0$oc5$1...@reader1.panix.com>,
# /opt/schily/bin/star -v -cM -xdev -sparse -acl -link-dirs \
level=0 -wtardumps errctl=/etc/tarerrctl fs=512m bs=63k \
f=/mnt/dkc_rpool.tar -C /dkc_rpool .
# /opt/schily/bin/star -v -cM -xdev -sparse -acl -link-dirs \
level=0 -wtardumps errctl=/etc/tarerrctl fs=512m bs=63k \
f=/mnt/root.tar -C / .
# /opt/schily/bin/star -v -cM -xdev -sparse -acl -link-dirs \
level=0 -wtardumps errctl=/etc/tarerrctl fs=512m bs=63k \
f=/mnt/export.tar -C /export .
# /opt/schily/bin/star -v -cM -xdev -sparse -acl -link-dirs \
level=0 -wtardumps errctl=/etc/tarerrctl fs=512m bs=63k \
f=/mnt/export_home.tar -C /export/home .
John
groe...@acm.org
David Combs <dkc...@panix.com> wrote:
>> zfs list -t filesystem
>NAME USED AVAIL REFER MOUNTPOINT
>dkc_rpool 95.5G 38.4G 96K /dkc_rpool
>dkc_rpool/ROOT 51.9G 38.4G 18K legacy
>dkc_rpool/ROOT/s10s_u7wos_08 51.9G 38.4G 50.3G /
>dkc_rpool/export 24.8G 38.4G 22K /export
>dkc_rpool/export/home 24.8G 38.4G 23.2G /export/home
<URL:http://cdrecord.berlios.de/old/private/man/star/star.1.html>
>> zfs list -t filesystem
>NAME USED AVAIL REFER MOUNTPOINT
>dkc_rpool 95.5G 38.4G 96K /dkc_rpool
>dkc_rpool/ROOT 51.9G 38.4G 18K legacy
>dkc_rpool/ROOT/s10s_u7wos_08 51.9G 38.4G 50.3G /
>dkc_rpool/export 24.8G 38.4G 22K /export
>dkc_rpool/export/home 24.8G 38.4G 23.2G /export/home
# /opt/schily/bin/star -v -cM -xdev -sparse -acl -link-dirs \
level=0 -wtardumps errctl=/etc/tarerrctl fs=512m bs=63k \
f=/mnt/dkc_rpool.tar -C /dkc_rpool .
# /opt/schily/bin/star -v -cM -xdev -sparse -acl -link-dirs \
level=0 -wtardumps errctl=/etc/tarerrctl fs=512m bs=63k \
f=/mnt/root.tar -C / .
# /opt/schily/bin/star -v -cM -xdev -sparse -acl -link-dirs \
level=0 -wtardumps errctl=/etc/tarerrctl fs=512m bs=63k \
f=/mnt/export.tar -C /export .
# /opt/schily/bin/star -v -cM -xdev -sparse -acl -link-dirs \
level=0 -wtardumps errctl=/etc/tarerrctl fs=512m bs=63k \
f=/mnt/export_home.tar -C /export/home .
John
groe...@acm.org
David Combs
Aug 12, 2012, 10:44:57 PM8/12/12
to
In article <k09b19$q030$1...@tr22n12.aset.psu.edu>,
THANK YOU VERY VERY MUCH.
Someday maybe I'll under all those star options!
Question 1: you did leave out the -X option (THE SOLUTION!),
yes?
Question 2: you suggested a couple of other dirs to exclude;
any more good ideas along that line?
(Via this .tar-file I create, there is no use for any
of the OS? /bin, etc. Since I can't really use it
to restore the OS itself -- is that correct.
Probably, however, it's not worth messing around like
that, because I'm sure to mess up and exclude something
I REALLY want!
You said /procs. What else totally epheremal like that?
Question 3: I've heard that star is a far better tar
than any other. Is that what you believe too?
QUESTION 4: that star command above is NOT going
to FOLLOW symlinks, correct? (Just thought I'd ask!)
Question 5: you have 4 star command-lines.
(I expected to see only ONE command-line.)
How do they differ, and which should I use, or
do use ALL FOUR.
Sorry for not doing more studying of it right now,
but my wife wants me to leave NOW -- and you probably
being in california 3hrs different from me, I might
get a response by when I get back tonight.
Can I not wait til tomorrow. Well, that 2500 is
hanging by a thread, something serious is wrong
with it (system board?) -- we tried to get it up
for several hours, my friend trying every trick
he knew, and somehow, 15 minutes when not expecting
it, it came up. Likely for the FINAL time --
once it goes down, we might NEVER get it up again.
So it is a bit of a rush. Thunderstorms in the
area -- power could go out, and it's likely
goodbye 2500, rip.
Thanks for putting up with my not so well
thought out posts!
THANKS SO VERY MUCH!
David
---
Will actually try it later tonight.
John D Groenveld <groe...@cse.psu.edu> wrote:
Someday maybe I'll under all those star options!
Question 1: you did leave out the -X option (THE SOLUTION!),
yes?
Question 2: you suggested a couple of other dirs to exclude;
any more good ideas along that line?
(Via this .tar-file I create, there is no use for any
of the OS? /bin, etc. Since I can't really use it
to restore the OS itself -- is that correct.
Probably, however, it's not worth messing around like
that, because I'm sure to mess up and exclude something
I REALLY want!
You said /procs. What else totally epheremal like that?
Question 3: I've heard that star is a far better tar
than any other. Is that what you believe too?
QUESTION 4: that star command above is NOT going
to FOLLOW symlinks, correct? (Just thought I'd ask!)
Question 5: you have 4 star command-lines.
(I expected to see only ONE command-line.)
How do they differ, and which should I use, or
do use ALL FOUR.
Sorry for not doing more studying of it right now,
but my wife wants me to leave NOW -- and you probably
being in california 3hrs different from me, I might
get a response by when I get back tonight.
Can I not wait til tomorrow. Well, that 2500 is
hanging by a thread, something serious is wrong
with it (system board?) -- we tried to get it up
for several hours, my friend trying every trick
he knew, and somehow, 15 minutes when not expecting
it, it came up. Likely for the FINAL time --
once it goes down, we might NEVER get it up again.
So it is a bit of a rush. Thunderstorms in the
area -- power could go out, and it's likely
goodbye 2500, rip.
Thanks for putting up with my not so well
thought out posts!
THANKS SO VERY MUCH!
David
---
Will actually try it later tonight.
oscar.d...@gmail.com
Aug 13, 2012, 10:17:22 AM8/13/12
to
On Sunday, 12 August 2012 15:34:02 UTC-4, David Combs wrote:
> Quick question: WHICH tar to use, sun tar or gnu tar?
Whichever works and will be available when you need to restore the data.
> Quick question: WHICH tar to use, sun tar or gnu tar?
I tend to use gtar for some of the extra options that sun-tar doesn't have and because gtar is included in recent versions of Solaris (/usr/sfw/bin/gtar in Solaris 9/10; /usr/bin/gtar in OpenSolaris/OpenIndiana/Solaris11)
I have never tried "star" but it might work for you...
David Combs
Aug 13, 2012, 11:00:23 AM8/13/12
to
THANK YOU! THANK YOU! You "SAVED MY BACON"! Well, maybe not ...
I thought we had it solved, by using the -X (exclude) option.
----------------- OOPS, MAYBE NOT!
I decided to try the gtar command-line first,
and then when that finished, try the star-command line.
------------------------- GTAR:
OK, here's the tar (gtar) command I gave:
gtar cvXf /exclude-from-tar.txt /dlink/gtar-backup-excluding-slash-dlink--230am-13aug12-2.tar . > /dlink/gtar-backup-excluding-slash-dlink--230am-13aug12-2.tar.log
(Or, split up into separate lines:
gtar cvXf /exclude-from-tar.txt \
/dlink/gtar-backup-excluding-slash-dlink--230am-13aug12-2.tar . \
> /dlink/gtar-backup-excluding-slash-dlink--230am-13aug12-2.tar.log
)
Which is running RIGHT NOW:
/usr/ucb/ps -auxwww
USER PID %CPU %MEM SZ RSS TT S START TIME COMMAND
root 27958 4.0 0.2 3648 2144 pts/2 R 02:37:14 40:49 gtar cvXf /exclude-from-tar.txt /dlink/gtar-backup-excluding-slash-dlink--230am
dkc 27488 0.3 1.41829614336 pts/1 S Aug 12 0:16 /opt/csw/bin/emacs
dkc 28099 0.2 0.4 3864 3248 pts/3 O 10:04:09 0:00 /usr/ucb/ps -auxwww
root 3 0.1 0.0 0 0 ? S Aug 04 96:04 fsflush
----------- THIS is what's being gtarred, right?:
>> zfs list -t filesystem
>NAME USED AVAIL REFER MOUNTPOINT
>dkc_rpool 95.5G 38.4G 96K /dkc_rpool
>dkc_rpool/ROOT 51.9G 38.4G 18K legacy
>dkc_rpool/ROOT/s10s_u7wos_08 51.9G 38.4G 50.3G /
>dkc_rpool/export 24.8G 38.4G 22K /export
>dkc_rpool/export/home 24.8G 38.4G 23.2G /export/home
c:\dkc>ls -lsAth //dlink-0a5035/Volume_1/Backup
ls -lsAth //dlink-0a5035/Volume_1/Backup
total 421G
159G -rw-r--r-- 1 DKC mkpasswd 159G Aug 13 10:15 gtar-backup-excluding-slash-dlink--230am-13aug12-2.tar
13M -rw-r--r-- 1 DKC mkpasswd 13M Aug 13 06:59 gtar-backup-excluding-slash-dlink--230am-13aug12-2.tar.log
396M -rw-r--r-- 1 DKC mkpasswd 395M Aug 13 02:32 gtar-backup-excluding-slash-dlink--230am-13aug12.tar
198G -rw-r--r-- 1 DKC mkpasswd 198G Aug 10 15:51 dkc-huge-via-gnu-tar--608am-10aug12.tar
0 drwxr-xr-x 9 DKC mkpasswd 0 Aug 9 07:01 cpbackup
64G -rw-r--r-- 1 DKC mkpasswd 64G Aug 9 05:52 mainbackup.tar
Look, a 159G tar file, compared to "only" 95.5G in /dkc_rpool.
WHAT IS WRONG?
COULD THERE BE A LOOP?
Well, let's check:
c:\dkc>C:\cygwin\bin\tail -5 //dlink-0a5035/Volume_1/Backup/gtar-backup-excluding-slash-dlink--230am-13aug12-2.tar.log
C:\cygwin\bin\tail //dlink-0a5035/Volume_1/Backup/gtar-backup-excluding-slash-dlink--230am-13aug12-2.tar.log
./mnt/cpbackup/dir2/t.ps
./mnt/cpbackup/dir2/noslash.out
./mnt/cpbackup/dir2/t1
./mnt/mainbackup.tar
./mnt/dkc-huge-via-gnu-tar--608am-10aug12.tar
The most recently tarred-up file is:
./mnt/dkc-huge-via-gnu-tar--608am-10aug12.tar (on the DLINK, NOT the sun!)
So I egrep for it in that same log-file, to see if there's
more than one of them:
c:\dkc>egrep -i dkc-huge-via-gnu-tar--608am-10aug12.tar //dlink-0a5035/Volume_1/Backup/gtar-backup-excluding-slash-dlink--230am-13aug12-2.tar.log
egrep -i dkc-huge-via-gnu-tar--608am-10aug12.tar //dlink-0a5035/Volume_1/Backup/gtar-backup-excluding-slash-dlink--230am-13aug12-2.tar.log
./mnt/dkc-huge-via-gnu-tar--608am-10aug12.tar
c:\dkc>
Whew, only one of them! Thus, no looping?
So, again, why has that tar file gotten SO HUGE, way, WAY
larger than:
>dkc_rpool 95.5G 38.4G 96K /dkc_rpool
What time is it right now? 10:30am
When did it start? at 2:41am this morning.
So, it's already been running EIGHT HOURS.
----------- HERE'S PROOF OF EXACTLY WHEN MY GTAR JOB STARTED:
> ls -l /dlink/gtar-backup-excluding-slash-dlink--230am-13aug12-2.tar{,.log}
-rw-r--r-- 1 501 501 2598799360 Aug 13 02:41 /dlink/gtar-backup-excluding-slash-dlink--230am-13aug12-2.tar
-rw-r--r-- 1 501 501 223644 Aug 13 02:41 /dlink/gtar-backup-excluding-slash-dlink--230am-13aug12-2.tar.log
ie it started at 2:41am this morning.
Any ideas?
Thank you, guys.
Like I say, you've sure "saved my bacon"!
David
---
(Thanks again for all the perservence you've had in
keeping to this thread, to my problem, to my obvious
lack of concept of zfs snapsnots (to say NOTHING about
CLONES, about which I haven't a clue, nor about why
in the world they could actually be USEFUL!)
Really, without you guys I'd be totally lost, and
losing all the data too!
What a wonderful bunch of perope here at comp.unix.solaris!
)
oscar.d...@gmail.com
Aug 13, 2012, 4:36:41 PM8/13/12
to
On Monday, 13 August 2012 11:00:23 UTC-4, David Combs wrote:
> gtar cvXf /exclude-from-tar.txt /dlink/gtar-backup-excluding-slash-dlink--230am-13aug12-2.tar . > /dlink/gtar-backup-excluding-slash-dlink--230am-13aug12-2.tar.log
> gtar cvXf /exclude-from-tar.txt /dlink/gtar-backup-excluding-slash-dlink--230am-13aug12-2.tar . > /dlink/gtar-backup-excluding-slash-dlink--230am-13aug12-2.tar.log
> C:\cygwin\bin\tail //dlink-0a5035/Volume_1/Backup/gtar-backup-excluding-slash-dlink--230am-13aug12-2.tar.log
> ./mnt/dkc-huge-via-gnu-tar--608am-10aug12.tar
Same problem as before, taring the tar file itself as it grows! But this time in /mnt instead of /dlink. Do you have the dlink mounted in /mnt as well as in /dlink???
Do a "df -k" in Solaris to see what's mounted. Add /mnt to the exclude file (and/or unmount /mnt)
David Combs
Aug 13, 2012, 8:18:54 PM8/13/12
to
In article <3322fe41-30b0-4302...@googlegroups.com>,
God, what a bitch this task has turned out to be.
That's what I did, add /mnt to the exclude file.
Then my friend said no, better to simply
umount -f /mnt
OK, I did that, and removed /mnt from the exclude file.
(the DLINK was gotten to via a separate mount point, luckily.)
So I ran the gtar job, and it got into a loop again!
How, we'd fixed everything. WRONG.
That /mnt I was told to and did umount -f /mnt it --
IT CAME BACK!
So I put /mnt back into the exclude file, VERIFIED THAT
/mnt STILL EXISTED (
WARNING: My belief is, from extremely recent
experience, is that if something is in that
exclude file, IT BETTER DAMN WELL EXIST, or you
get horrible errors flying out of gtar to the
.log file).
Errors like these:
gtar: ./system/contract/process/40/ctl: Cannot open: Permission denied
gtar: ./system/contract/process/41/ctl: Cannot open: Permission denied
gtar: ./system/contract/process/42/ctl: Cannot open: Permission denied
gtar: ./system/contract/process/43/ctl: Cannot open: Permission denied
...
...
gtar: ./system/object/unix/object: file changed as we read it
gtar: ./system/object/unix: file changed as we read it
gtar: ./system/object/genunix/object: file changed as we read it
gtar: ./system/object/genunix: file changed as we read it
gtar: ./system/object/platmod/object: file changed as we read it
gtar: ./system/object/platmod: file changed as we read it
gtar: ./system/object/SUNW,UltraSPARC-IIIi/object: file changed as we read it
gtar: ./system/object/SUNW,UltraSPARC-IIIi: file changed as we read it
gtar: ./system/object/specfs/object: file changed as we read it
gtar: ./system/object/specfs: file changed as we read it
gtar: ./system/object/fifofs/object: file changed as we read it
gtar: ./system/object/fifofs: file changed as we read it
gtar: ./system/object/dtrace/object: file changed as we read it
gtar: ./system/object/dtrace: file changed as we read it
gtar: ./system/object/devfs/object: file changed as we read it
gtar: ./system/object/devfs: file changed as we read it
...
gtar: ./var/samba/locks/winbindd_privileged/pipe: socket ignored
gtar: ./var/run/kcfd_door: door ignored
gtar: ./var/run/name_service_door: door ignored
gtar: ./var/run/sysevent_channels/syseventd_channel/reg_door: door ignored
gtar: ./var/run/sysevent_channels/syseventd_channel/1: door ignored
gtar: ./var/run/sysevent_channels/syseventd_channel/2: door ignored
gtar: ./var/run/picld_door: door ignored
gtar: ./var/run/rpc_door/rpc_100169.1: door ignored
gtar: ./var/run/.inetd.uds: socket ignored
gtar: ./var/run/fpsdiagd_door: door ignored
gtar: ./var/run/syslog_door: door ignored
gtar: ./var/tmp/orbit-dkc-28282828/linc-4f7-0-4e5987c318dae: socket ignored
gtar: ./var/tmp/orbit-dkc-28282828/linc-28aa-0-4f55f2276b824: socket ignored
gtar: ./var/tmp/orbit-dkc-28282828/linc-5b6b-0-4fb1dd967871: socket ignored
gtar: ./var/tmp/orbit-dkc-28282828/linc-3b4-0-4e6615daa1f3c: socket ignored
gtar: ./var/tmp/orbit-dkc-28282828/linc-3d1c-0-4fa9eeb5dab25: socket ignored
gtar: ./var/tmp/orbit-dkc-28282828/linc-28aa-0-4f55cba6142b5: socket ignored
gtar: ./var/tmp/orbit-dkc-28282828/linc-445d-0-4fab487b9bcc0: socket ignored
gtar: ./var/tmp/orbit-dkc-28282828/linc-51b-0-4e5992d23d182: socket ignored
gtar: ./var/tmp/orbit-dkc-28282828/linc-4e2-0-4e599a9ab1591: socket ignored
...
---------------------------------------------- Here, I finally kill it:
gtar: ./system/contract/process/10/ctl: Cannot open: Permission denied
Anyway, it's running again; let's see what happens.
Big problem: I don't know gtar (or any tar?) sequences itself
through the disk files to be tarred-up -- DFS, BFS, inode, who
knows. But it might take HOURS for it to get to a file
that causes a loop.
So this stuff sure takes time!
Anyway, you so incredibly helpful guys, that's where
I am so far.
Wish me luck!
If this works, gtar, then I'll do it again using star,
naming the tar file "star-produced.tar" or the like.
Again, thanks for putting up with me!
David
That's what I did, add /mnt to the exclude file.
Then my friend said no, better to simply
umount -f /mnt
OK, I did that, and removed /mnt from the exclude file.
(the DLINK was gotten to via a separate mount point, luckily.)
So I ran the gtar job, and it got into a loop again!
How, we'd fixed everything. WRONG.
That /mnt I was told to and did umount -f /mnt it --
IT CAME BACK!
So I put /mnt back into the exclude file, VERIFIED THAT
/mnt STILL EXISTED (
WARNING: My belief is, from extremely recent
experience, is that if something is in that
exclude file, IT BETTER DAMN WELL EXIST, or you
get horrible errors flying out of gtar to the
.log file).
Errors like these:
gtar: ./system/contract/process/40/ctl: Cannot open: Permission denied
gtar: ./system/contract/process/41/ctl: Cannot open: Permission denied
gtar: ./system/contract/process/42/ctl: Cannot open: Permission denied
gtar: ./system/contract/process/43/ctl: Cannot open: Permission denied
...
...
gtar: ./system/object/unix/object: file changed as we read it
gtar: ./system/object/unix: file changed as we read it
gtar: ./system/object/genunix/object: file changed as we read it
gtar: ./system/object/genunix: file changed as we read it
gtar: ./system/object/platmod/object: file changed as we read it
gtar: ./system/object/platmod: file changed as we read it
gtar: ./system/object/SUNW,UltraSPARC-IIIi/object: file changed as we read it
gtar: ./system/object/SUNW,UltraSPARC-IIIi: file changed as we read it
gtar: ./system/object/specfs/object: file changed as we read it
gtar: ./system/object/specfs: file changed as we read it
gtar: ./system/object/fifofs/object: file changed as we read it
gtar: ./system/object/fifofs: file changed as we read it
gtar: ./system/object/dtrace/object: file changed as we read it
gtar: ./system/object/dtrace: file changed as we read it
gtar: ./system/object/devfs/object: file changed as we read it
gtar: ./system/object/devfs: file changed as we read it
...
gtar: ./var/samba/locks/winbindd_privileged/pipe: socket ignored
gtar: ./var/run/kcfd_door: door ignored
gtar: ./var/run/name_service_door: door ignored
gtar: ./var/run/sysevent_channels/syseventd_channel/reg_door: door ignored
gtar: ./var/run/sysevent_channels/syseventd_channel/1: door ignored
gtar: ./var/run/sysevent_channels/syseventd_channel/2: door ignored
gtar: ./var/run/picld_door: door ignored
gtar: ./var/run/rpc_door/rpc_100169.1: door ignored
gtar: ./var/run/.inetd.uds: socket ignored
gtar: ./var/run/fpsdiagd_door: door ignored
gtar: ./var/run/syslog_door: door ignored
gtar: ./var/tmp/orbit-dkc-28282828/linc-4f7-0-4e5987c318dae: socket ignored
gtar: ./var/tmp/orbit-dkc-28282828/linc-28aa-0-4f55f2276b824: socket ignored
gtar: ./var/tmp/orbit-dkc-28282828/linc-5b6b-0-4fb1dd967871: socket ignored
gtar: ./var/tmp/orbit-dkc-28282828/linc-3b4-0-4e6615daa1f3c: socket ignored
gtar: ./var/tmp/orbit-dkc-28282828/linc-3d1c-0-4fa9eeb5dab25: socket ignored
gtar: ./var/tmp/orbit-dkc-28282828/linc-28aa-0-4f55cba6142b5: socket ignored
gtar: ./var/tmp/orbit-dkc-28282828/linc-445d-0-4fab487b9bcc0: socket ignored
gtar: ./var/tmp/orbit-dkc-28282828/linc-51b-0-4e5992d23d182: socket ignored
gtar: ./var/tmp/orbit-dkc-28282828/linc-4e2-0-4e599a9ab1591: socket ignored
...
---------------------------------------------- Here, I finally kill it:
gtar: ./system/contract/process/10/ctl: Cannot open: Permission denied
Anyway, it's running again; let's see what happens.
Big problem: I don't know gtar (or any tar?) sequences itself
through the disk files to be tarred-up -- DFS, BFS, inode, who
knows. But it might take HOURS for it to get to a file
that causes a loop.
So this stuff sure takes time!
Anyway, you so incredibly helpful guys, that's where
I am so far.
Wish me luck!
If this works, gtar, then I'll do it again using star,
naming the tar file "star-produced.tar" or the like.
Again, thanks for putting up with me!
David
David Combs
Aug 13, 2012, 8:59:54 PM8/13/12
to
I've given huge thanks to all you wonderful people
here on comp.unix solaris.
Without you guys, I, working totally alone, only books to look
at, would be nowhere -- for years (decades, actually -- first
sun was 3/160 in 1986). Am really grateful for this group
and you guys on it and that the group even exists!
Now, I've got to give one more huge thank you -- to my Canadian
friend (used to work for Sun) who has been aiding
me for a couple or three years now.
He's even been down here to modernize the whole
setup, adding a print-server, getting the LAN to
work right, install new versions of solaris (10)
with zfs, etc. And by phone two weeks got me to
order the DLINK -- which he then set up as an NAS (
which term I had never even heard of!).
And he's is always available by phone.
And now, from where he works way up there,
maybe 2,000 miles away,
he can use his workplace's "logmein rescue"
to join me in
running this Dell PC xp, and even more wonderful,
via a 50ft null-modem cable, can run the sun
upstairs!
(Hell, I can and do run emacs on it, from my Dell xp pc,
tnanks to that null modem (totally his idea.).)
So he's been a real lifesaver.
---
Yes, there is one more guy. Put together a used 2500
for me, added needed hardware, installed new solaris
and all kinds of software (blastwave), and then shipped
it down to me.
Unfortunately that once very good relationship has
ended, via him, on a pretty sour note, because his
wife complained to him that I left a nasty message
on their phone complaining that I'd been trying
for maybe a week to get him, and couldn't get
him to call back or pick up (admittedly, he's
a VERY busy guy). Too bad; that was several
years ago. Very, very smart guy, just like
my other friend up there.
Everyone reads this group, so I wanted to
give credit where credit was due.
Thanks, wonderful people!
David
here on comp.unix solaris.
Without you guys, I, working totally alone, only books to look
at, would be nowhere -- for years (decades, actually -- first
sun was 3/160 in 1986). Am really grateful for this group
and you guys on it and that the group even exists!
Now, I've got to give one more huge thank you -- to my Canadian
friend (used to work for Sun) who has been aiding
me for a couple or three years now.
He's even been down here to modernize the whole
setup, adding a print-server, getting the LAN to
work right, install new versions of solaris (10)
with zfs, etc. And by phone two weeks got me to
order the DLINK -- which he then set up as an NAS (
which term I had never even heard of!).
And he's is always available by phone.
And now, from where he works way up there,
maybe 2,000 miles away,
he can use his workplace's "logmein rescue"
to join me in
running this Dell PC xp, and even more wonderful,
via a 50ft null-modem cable, can run the sun
upstairs!
(Hell, I can and do run emacs on it, from my Dell xp pc,
tnanks to that null modem (totally his idea.).)
So he's been a real lifesaver.
---
Yes, there is one more guy. Put together a used 2500
for me, added needed hardware, installed new solaris
and all kinds of software (blastwave), and then shipped
it down to me.
Unfortunately that once very good relationship has
ended, via him, on a pretty sour note, because his
wife complained to him that I left a nasty message
on their phone complaining that I'd been trying
for maybe a week to get him, and couldn't get
him to call back or pick up (admittedly, he's
a VERY busy guy). Too bad; that was several
years ago. Very, very smart guy, just like
my other friend up there.
Everyone reads this group, so I wanted to
give credit where credit was due.
Thanks, wonderful people!
David
Joerg.S...@fokus.fraunhofer.de
Mar 28, 2013, 9:43:50 AM3/28/13
to
In article <k03nd3$fn2$1...@panix1.panix.com>,
Did you try star?
>The gnu-tar man page, I recall, says that, by default,
>it does NOT actually *follow* symlinks.
This is what a tar implementation in general should do.
>QUESTION: any switches (options) I should have used,
>in either sun or gnu tar?
Did you find out why sun tar loops?
If this is because of a directory loop (via hard link) in the filesystem, you
could tell star to use libfind to traverse the directory tree. Libfind uses a
method to avoid looping over things already visited.
>(General Question: which is generally better of those
>two tars?)
What is your intention?
Sun tar is not very maintained and GNU tar is non-standard and full of bugs - in
special if you use it to do backups.
>Please, dear god, could this NEXT tar be a solution?:
Do you believe that star is the "next tar"?
Star exists since more than 30 years, so it is the second tar implementation.
It appeared only a short time after the initial UNIX tar implementation and
5 years before GNU tar.
>Some people here swear by STAR (ess-tar, Schilly's tar).
>
>It is supposed to be truly *far* superior to any other tar.
>
>Problem is, there's *so many* options (man page is 50 pages
>long, printed!), with many maybe from way back when, when all
>tars (except his) had bugs galore, but are no longer
>so useful with newer tars abounding, but back then
>he had to be compatible. (Got to be *some* reason for
>all those options!)
>
>I read it, and those 50 printed pages blows my 70 years old mind!
>
>It's *way* over my head. (I've communicated with him,
>and his response was that (his) star man-page was completly
>straightforward, and should be no problem
>reading and understand it. Something like that.)
If you have problems with the man page and can express them, I could try to
make it better. Just complaining about it does not help.
>So, please:
>
>DOES ANYONE KNOW THAT 100-option PROGRAM, "STAR"?
It has 185 options (not counting libfind) and these options are easier to
learn than the options from GNU tar, as there is a system in the star options
that makes the options more powerful.
--
EMail:jo...@schily.net (home) J�rg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.s...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Did you try star?
>The gnu-tar man page, I recall, says that, by default,
>it does NOT actually *follow* symlinks.
>QUESTION: any switches (options) I should have used,
>in either sun or gnu tar?
If this is because of a directory loop (via hard link) in the filesystem, you
could tell star to use libfind to traverse the directory tree. Libfind uses a
method to avoid looping over things already visited.
>(General Question: which is generally better of those
>two tars?)
Sun tar is not very maintained and GNU tar is non-standard and full of bugs - in
special if you use it to do backups.
>Please, dear god, could this NEXT tar be a solution?:
Star exists since more than 30 years, so it is the second tar implementation.
It appeared only a short time after the initial UNIX tar implementation and
5 years before GNU tar.
>Some people here swear by STAR (ess-tar, Schilly's tar).
>
>It is supposed to be truly *far* superior to any other tar.
>
>Problem is, there's *so many* options (man page is 50 pages
>long, printed!), with many maybe from way back when, when all
>tars (except his) had bugs galore, but are no longer
>so useful with newer tars abounding, but back then
>he had to be compatible. (Got to be *some* reason for
>all those options!)
>
>I read it, and those 50 printed pages blows my 70 years old mind!
>
>It's *way* over my head. (I've communicated with him,
>and his response was that (his) star man-page was completly
>straightforward, and should be no problem
>reading and understand it. Something like that.)
make it better. Just complaining about it does not help.
>So, please:
>
>DOES ANYONE KNOW THAT 100-option PROGRAM, "STAR"?
learn than the options from GNU tar, as there is a system in the star options
that makes the options more powerful.
--
EMail:jo...@schily.net (home) J�rg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.s...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Joerg.S...@fokus.fraunhofer.de
Mar 28, 2013, 9:47:50 AM3/28/13
to
In article <k04g76$o6t$1...@reader1.panix.com>,
different tar later. Star has many features that other tar implementation don't
have and you need to understand the concept before you can use them.
On the other side: if you just like to use the features of the historic tar,
there is no way to prevent you from doing this.
David Combs <dkc...@panix.com> wrote:
>>I found Joerg Schilling's manpage readable.
>
>For my brain, there's just way too much stuff all of
>which I have to hold in my head at one time, before
>I can totally understand or grok it.
>
>SO many switches. I just don't have enough
>background to understand, for most of them,
>WHY he had to add them, what problem they solved
>(back then), a sentence or two of scenarios in
>which you'd need a given one of them.
>
>You guys, unlike me, do now or at least for some
>period of time have worked in a group of people,
>and by discussions etc you taught each other, or
>leaned by osmosis.
I know of many people that took a day to read the man page and who never used a
>>I found Joerg Schilling's manpage readable.
>
>For my brain, there's just way too much stuff all of
>which I have to hold in my head at one time, before
>I can totally understand or grok it.
>
>SO many switches. I just don't have enough
>background to understand, for most of them,
>WHY he had to add them, what problem they solved
>(back then), a sentence or two of scenarios in
>which you'd need a given one of them.
>
>You guys, unlike me, do now or at least for some
>period of time have worked in a group of people,
>and by discussions etc you taught each other, or
>leaned by osmosis.
different tar later. Star has many features that other tar implementation don't
have and you need to understand the concept before you can use them.
On the other side: if you just like to use the features of the historic tar,
there is no way to prevent you from doing this.
Joerg.S...@fokus.fraunhofer.de
Mar 28, 2013, 9:50:19 AM3/28/13
to
>> drwxrwxrwx 3 501 501 4096 Aug 10 06:09 dlink
>>
>
>> /dlink:
>>
>> total 547955001
>
>> -rwxrwxrwx 1 501 501 211683016704 Aug 10 15:51 dkc-huge-via-gnu-tar--608am-10aug12.tar
>
>That is the problem: You are including /dlink in the TAR command! TAR (regardless of version) is taring everything in /dlink including the tar file
>itself, ad-infinitum!
Star and GNU tar don't include the archive iif it was found while traverding
>>
>
>> /dlink:
>>
>> total 547955001
>
>> -rwxrwxrwx 1 501 501 211683016704 Aug 10 15:51 dkc-huge-via-gnu-tar--608am-10aug12.tar
>
>That is the problem: You are including /dlink in the TAR command! TAR (regardless of version) is taring everything in /dlink including the tar file
>itself, ad-infinitum!
the tree.
Your claim is only true for a historic tar implementation.
David Combs
May 4, 2013, 10:17:03 PM5/4/13
to
In article <kj1hem$am1$1...@news.albasani.net>,
Yes, had to use the -X switch, to exclude something.
That was thanks to a suggestion from someone in
this newsgroup.
Or because of symlinks used as short abbreviations
and so there are parallel paths to the same file?
>
>
>>(General Question: which is generally better of those
>>two tars?)
>
>What is your intention?
You imply that depending on what I want
to do, I'd use this tar over that one.
That would make life even more complicated
than it is now!
What one hopes for is that one tar "DOMINATES"
the others, in that once you fully understand
how to use the single BEST one, you'd NEVER AGAIN
use one of the lesser ones, at least not
for any task you were totally in charge of (ie
not having to obey anyone else).
That none of the lesser tars has ANY useful
feature that the best one doesn't have.
Sorry for the insanely long delay.
About the documentation for STAR:
It's only one document, an extremely long man-page,
consisting of roughly 50 printed pages.
And because it's done as a man-page, you're somewhat
limited to the official man-page format.
(Note: I say that without having the STAR man-page
in front of me, and not having even looked at
for several months. So I could be way off.)
Now, let's look at gtar (gnu tar):
It has at least TWO pieces of documentation:
1: the manpage.
2: the .info document (over 220 pages long)
Whoever wrote the .info must have thought that
gnu tar and the concepts were complex enough
to *require* that kind of documentation.
Were Star and gtar actually identical programs,
one way of looking at the star 50-pages vs the
gtar 220+ pages would be that star had tried
to stuff 220 pages of information, tutorial,
etc, into just 50 pages.
But of course gtar and star are nothing like
identical. As I recall, star had not only
many more features, but those features
were more difficult (for me) to understand (and
more difficult to understand WHY they had been
added).
BEGIN ASIDE:
Plus (and this might be true of gtar too),
probably some of the star options were
added to combat OS deficiencies that existed
"way back when" (30, 40 years ago?) but which
no longer exist.
If such features/options exist, perhaps they
could be not retired but at least moved
to a "not needed any more" section.
So that someone approaching star doesn't even
have to know that these things even exist!
END ASIDE
Joerg, please have a look at the gtar info-doc,
at the tutorial part (well, the whole thing is
really a tutorial), at how its features are grouped,
at how the options (switches) pretty much everyone
needs are discussed earlier than the less-often
needed ones.
---
Jeorg, I believe you when you tell us that
star is far better than any other tar-like
program.
But I know from questions (including this one)
that I've posted here, when I ask about one tar
versus another, only very few (other than
you, should you notice the thread) say anything
about star. Even when directly asked,
"what about star?"
Now, except for the likes of me, the people
using this newsgroup are mostly very, very
bright, and equally skilled at computer science,
solaris, etc.
Presumably, if star was so much superior to
the other tars, these people would recognize it.
(Again, I'm not just assuming that star is far
and away the best of these programs, I'm actually
BELIEVING it -- based on what you say, and especially
on the quality of all the other programs you've
contributed to the (unix) world!)
So, why don't they seem to recognize it?
Perhaps even THEY find the documentation lacking
in one way or another. Maybe not enough explanationi
of the "why" for the various options.
Certainly the star doc can hardly be called "tutorial".
Also, the various options are listed one after another,
even if they are broken down into a few groups.
The only way to read the existing star doc (ie the man-page)
is to start at the top and read all the way down to the
bottom.
It's (to me, anyway) like "drinking from a fire hose".
What do they say the average human can hold in his
short-term memory at one time? Something like
SEVEN different things?
Now, if it were 500 things one could keep in
short term memory, then the firehose method
would, I suppose, be fine.
--
Jeorg, I just hate to see a truly superior program
not being used by those experts who SHOULD have
been using it (for maybe decades!), and for
their own benefit, but aren't, simply because
the doc is too, well, man-pageish.
--
None of us are getting any younger, including
you, nor we as energetic as we once were.
It's completely understandable if you
decide to not add a separate, tutorial
to star. But it sure would be nice
if you could find the time, interest,
and energy to, bit by bit, produce
something like the gtar info-doc.
The best result would be if due to
that effort, most people frequenting
this news group would soon switch
to star!
After which word would get around, and
it would REALLY spread.
Best of all, *I* would know how
to use it!
David
PS: Again, it would be a real help if for
any star option that was the least bit
advanced, you "motivated" it by somewhere
stating WHY you had to implement it: what
situation it fixed, and how it fixed it.
Also, for those whose names aren't 100%
obvious, WHY you chose that name for it.
A little history of a feature, the pros
and cons of having it or not, and the
pros and cons of one name versus another --
all that surrounding context makes it easier
to glue it into ones brain, into a NETWORK
of related things (eg star options)
into the brain.
PS: Note, when looking at the gtar doc,
how it says it has a way to facilitate
"incremental" tars -- like, I suppose,
the solaris "ufsdump" program. (Unfortunately
missing from zfs.)
<Joerg.S...@fokus.fraunhofer.de> wrote:
>In article <k03nd3$fn2$1...@panix1.panix.com>,
>David Combs <dkc...@panix.com> wrote:
>
>>Tried sun tar. Looped, HUGE output before had to kill it.
>
>Did you try star?
>
>>The gnu-tar man page, I recall, says that, by default,
>>it does NOT actually *follow* symlinks.
>
>This is what a tar implementation in general should do.
>
>>QUESTION: any switches (options) I should have used,
>>in either sun or gnu tar?
>
>Did you find out why sun tar loops?
Yes, although I forget what I did to fix it. Hmmm.
>In article <k03nd3$fn2$1...@panix1.panix.com>,
>David Combs <dkc...@panix.com> wrote:
>
>>Tried sun tar. Looped, HUGE output before had to kill it.
>
>Did you try star?
>
>>The gnu-tar man page, I recall, says that, by default,
>>it does NOT actually *follow* symlinks.
>
>This is what a tar implementation in general should do.
>
>>QUESTION: any switches (options) I should have used,
>>in either sun or gnu tar?
>
>Did you find out why sun tar loops?
Yes, had to use the -X switch, to exclude something.
That was thanks to a suggestion from someone in
this newsgroup.
>
>If this is because of a directory loop (via hard link) in the filesystem, you
>could tell star to use libfind to traverse the directory tree. Libfind uses a
>method to avoid looping over things already visited.
You mean with the same absolute pathname?
>If this is because of a directory loop (via hard link) in the filesystem, you
>could tell star to use libfind to traverse the directory tree. Libfind uses a
>method to avoid looping over things already visited.
Or because of symlinks used as short abbreviations
and so there are parallel paths to the same file?
>
>
>>(General Question: which is generally better of those
>>two tars?)
>
>What is your intention?
to do, I'd use this tar over that one.
That would make life even more complicated
than it is now!
What one hopes for is that one tar "DOMINATES"
the others, in that once you fully understand
how to use the single BEST one, you'd NEVER AGAIN
use one of the lesser ones, at least not
for any task you were totally in charge of (ie
not having to obey anyone else).
That none of the lesser tars has ANY useful
feature that the best one doesn't have.
About the documentation for STAR:
It's only one document, an extremely long man-page,
consisting of roughly 50 printed pages.
And because it's done as a man-page, you're somewhat
limited to the official man-page format.
(Note: I say that without having the STAR man-page
in front of me, and not having even looked at
for several months. So I could be way off.)
Now, let's look at gtar (gnu tar):
It has at least TWO pieces of documentation:
1: the manpage.
2: the .info document (over 220 pages long)
Whoever wrote the .info must have thought that
gnu tar and the concepts were complex enough
to *require* that kind of documentation.
Were Star and gtar actually identical programs,
one way of looking at the star 50-pages vs the
gtar 220+ pages would be that star had tried
to stuff 220 pages of information, tutorial,
etc, into just 50 pages.
But of course gtar and star are nothing like
identical. As I recall, star had not only
many more features, but those features
were more difficult (for me) to understand (and
more difficult to understand WHY they had been
added).
BEGIN ASIDE:
Plus (and this might be true of gtar too),
probably some of the star options were
added to combat OS deficiencies that existed
"way back when" (30, 40 years ago?) but which
no longer exist.
If such features/options exist, perhaps they
could be not retired but at least moved
to a "not needed any more" section.
So that someone approaching star doesn't even
have to know that these things even exist!
END ASIDE
Joerg, please have a look at the gtar info-doc,
at the tutorial part (well, the whole thing is
really a tutorial), at how its features are grouped,
at how the options (switches) pretty much everyone
needs are discussed earlier than the less-often
needed ones.
---
Jeorg, I believe you when you tell us that
star is far better than any other tar-like
program.
But I know from questions (including this one)
that I've posted here, when I ask about one tar
versus another, only very few (other than
you, should you notice the thread) say anything
about star. Even when directly asked,
"what about star?"
Now, except for the likes of me, the people
using this newsgroup are mostly very, very
bright, and equally skilled at computer science,
solaris, etc.
Presumably, if star was so much superior to
the other tars, these people would recognize it.
(Again, I'm not just assuming that star is far
and away the best of these programs, I'm actually
BELIEVING it -- based on what you say, and especially
on the quality of all the other programs you've
contributed to the (unix) world!)
So, why don't they seem to recognize it?
Perhaps even THEY find the documentation lacking
in one way or another. Maybe not enough explanationi
of the "why" for the various options.
Certainly the star doc can hardly be called "tutorial".
Also, the various options are listed one after another,
even if they are broken down into a few groups.
The only way to read the existing star doc (ie the man-page)
is to start at the top and read all the way down to the
bottom.
It's (to me, anyway) like "drinking from a fire hose".
What do they say the average human can hold in his
short-term memory at one time? Something like
SEVEN different things?
Now, if it were 500 things one could keep in
short term memory, then the firehose method
would, I suppose, be fine.
--
Jeorg, I just hate to see a truly superior program
not being used by those experts who SHOULD have
been using it (for maybe decades!), and for
their own benefit, but aren't, simply because
the doc is too, well, man-pageish.
--
None of us are getting any younger, including
you, nor we as energetic as we once were.
It's completely understandable if you
decide to not add a separate, tutorial
to star. But it sure would be nice
if you could find the time, interest,
and energy to, bit by bit, produce
something like the gtar info-doc.
The best result would be if due to
that effort, most people frequenting
this news group would soon switch
to star!
After which word would get around, and
it would REALLY spread.
Best of all, *I* would know how
to use it!
David
PS: Again, it would be a real help if for
any star option that was the least bit
advanced, you "motivated" it by somewhere
stating WHY you had to implement it: what
situation it fixed, and how it fixed it.
Also, for those whose names aren't 100%
obvious, WHY you chose that name for it.
A little history of a feature, the pros
and cons of having it or not, and the
pros and cons of one name versus another --
all that surrounding context makes it easier
to glue it into ones brain, into a NETWORK
of related things (eg star options)
into the brain.
PS: Note, when looking at the gtar doc,
how it says it has a way to facilitate
"incremental" tars -- like, I suppose,
the solaris "ufsdump" program. (Unfortunately
missing from zfs.)
David Combs
May 4, 2013, 10:40:30 PM5/4/13
to
In article <kj1hm6$am1$2...@news.albasani.net>,
people who could and maybe did get Phd's in nuclear
physics or c.s., people FAR brighter than I am,
who are just plain more capable of grasping complex
things with little or no handholding.
Me, I too can learn some complicated things, but
only with a lot of handholding. And best when
I can learn it from some other human, not only
from a book (or manpage).
And, I imagine, there are others out there like
me, who can learn things, but require a bit
of handholding, either from a human, or from
something written from a tutorial point of view.
I suppose the extreme is shown in the O'Reilly
"Head First" series, but of course that would
be way overkill for something like star.
>On the other side: if you just like to use the features of the historic tar,
>there is no way to prevent you from doing this.
No. If you say there are bugs in those programs,
including gtar, and that yours is not just
faster but *better* and thus *safer*,
OF COURSE yours is what I want to use!
And I would, if I could understand
the let's say 50% I really needed
of the options. But which ones are they?
Anyway, thanks for the super program,
even if I can't seem to master it (due
to not being able to "drink from that
firehose" of a man page).
(question: how DO you spell "man page"
as a single or compound noun?)
David
<Joerg.S...@fokus.fraunhofer.de> wrote:
>In article <k04g76$o6t$1...@reader1.panix.com>,
>David Combs <dkc...@panix.com> wrote:
>
>>>I found Joerg Schilling's manpage readable.
>>
>>For my brain, there's just way too much stuff all of
>>which I have to hold in my head at one time, before
>>I can totally understand or grok it.
>>
>>SO many switches. I just don't have enough
>>background to understand, for most of them,
>>WHY he had to add them, what problem they solved
>>(back then), a sentence or two of scenarios in
>>which you'd need a given one of them.
>>
>>You guys, unlike me, do now or at least for some
>>period of time have worked in a group of people,
>>and by discussions etc you taught each other, or
>>leaned by osmosis.
>
>I know of many people that took a day to read the man page and who never used a
>different tar later. Star has many features that other tar implementation don't
>have and you need to understand the concept before you can use them.
>
There are so many REALLY smart people in this field,
>In article <k04g76$o6t$1...@reader1.panix.com>,
>David Combs <dkc...@panix.com> wrote:
>
>>>I found Joerg Schilling's manpage readable.
>>
>>For my brain, there's just way too much stuff all of
>>which I have to hold in my head at one time, before
>>I can totally understand or grok it.
>>
>>SO many switches. I just don't have enough
>>background to understand, for most of them,
>>WHY he had to add them, what problem they solved
>>(back then), a sentence or two of scenarios in
>>which you'd need a given one of them.
>>
>>You guys, unlike me, do now or at least for some
>>period of time have worked in a group of people,
>>and by discussions etc you taught each other, or
>>leaned by osmosis.
>
>I know of many people that took a day to read the man page and who never used a
>different tar later. Star has many features that other tar implementation don't
>have and you need to understand the concept before you can use them.
>
people who could and maybe did get Phd's in nuclear
physics or c.s., people FAR brighter than I am,
who are just plain more capable of grasping complex
things with little or no handholding.
Me, I too can learn some complicated things, but
only with a lot of handholding. And best when
I can learn it from some other human, not only
from a book (or manpage).
And, I imagine, there are others out there like
me, who can learn things, but require a bit
of handholding, either from a human, or from
something written from a tutorial point of view.
I suppose the extreme is shown in the O'Reilly
"Head First" series, but of course that would
be way overkill for something like star.
>On the other side: if you just like to use the features of the historic tar,
>there is no way to prevent you from doing this.
including gtar, and that yours is not just
faster but *better* and thus *safer*,
OF COURSE yours is what I want to use!
And I would, if I could understand
the let's say 50% I really needed
of the options. But which ones are they?
Anyway, thanks for the super program,
even if I can't seem to master it (due
to not being able to "drink from that
firehose" of a man page).
(question: how DO you spell "man page"
as a single or compound noun?)
David
0 new messages