Re: [Bug-tar] [BULK] Re: Question on the one-filesystem option

[Gene Heskett]

On Monday 28 July 2014 11:00:25 Joi L. Ellis did opine
And Gene did reply:
> I've been doing some googling, and the rpc_pipefs is a
> feature/function/product of nfs4.  It's used for communicating between
> nfs4 servers and clients and doesn't contain anything you need to back
> up, it's all dynamically generated as part of client/server
> interactions.  I'd just put that --one-file-system parameter back on
> your tar command and ignore the whole tree.  I wouldn't attempt
> restoring any of that data into a client filesystem, you'd just muck
> up your existing nfs mounts.

I can do that, but how else can I kill about 60 lines of amdump/amreport 
mewling about the skipped links?
> 
> --
> Joi Owen
> System Administrator
> Pavlov Media, Inc
> 
> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On Behalf Of Gene Heskett Sent:
> Monday, July 28, 2014 4:09 AM
> To: address@hidden
> Cc: address@hidden; address@hidden
> Subject: [BULK] Re: Question on the one-filesystem option
> 
> On Monday 28 July 2014 04:53:47 address@hidden did opine And Gene 
did reply:
> > On Mon, 28 Jul 2014, Gene Heskett wrote:
> > > However, in one failure path it quoted, there are no softlinks. It
> > > simply did not like /var/lib/nfs/rpc_pipefs, which actually goes 2
> > > or 3 levels deeper, encountering no softlinks as it goes.
> > > 
> > > So I'm still standing here on my stump and proclaiming that tars
> > > "--one- file-system" implementation is broken.  And has been since
> > > somewhere post 1.22.
> > 
> > Hi Gene,
> > 
> > There is a simple explanation for that: /var/lib/nfs/rpc_pipefs IS a
> > separate file system. On my system I have:
> > 
> > $ df  /var/lib/nfs/rpc_pipefs
> > Filesystem     1K-blocks  Used Available Use% Mounted on
> > rpc_pipefs             0     0         0    - /var/lib/nfs/rpc_pipefs
> > 
> > $ mount | grep pipe
> > rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
> > 
> > So /var/lib/nfs/rpc_pipefs is a mountpoint for a file system of type
> > "rpc_pipefs" (whatever that might be). I'm pretty sure it is volatile
> > and will be recreated automatically at start-up, so no need to back
> > it up.
> > 
> > Bob
> 
> Crazy.  There is no evidence of that shown by an ls -l being executed
> anyplace in that tree.
> 
> I'll do a similar df check on the other failure points.  When I am
> fully awake. No one would accuse me of that at 5am local.
> 
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page <http://geneslinuxbox.net:6309/gene>
> US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS