[lxc-devel] Change rootfs pinning mechnism

Serge Hallyn serge.hallyn at ubuntu.com
Fri Sep 13 15:28:25 UTC 2013


Quoting Michael H. Warfield (mhw at WittsEnd.com):
> On Fri, 2013-09-13 at 07:56 -0500, Serge Hallyn wrote: 
> > Quoting Jäkel, Guido (G.Jaekel at dnb.de):
> > > Hello,
> > > 
> > > I'm late but I just want to mention that I expect that all this kind
> > of "unlinking" on a NFS will show up as a stale NFS handle, i.e. a
> > still visible hidden directory entry (.nfs00??????????????????????).
> > Therefore, one have to take care of this (i.e. exclude) if he make a
> > copy of such (for the purpose of cloning or even for backups). This
> > isn't a LXC-, but a NFS-caveat. An NFS-aware will (should) know about
> > to deal with this but there he should have to know (by the
> > documentation) that LXC will use this unlinking mechanism to correlate
> > this stale handle.
> 
> > Will it use the same name every time?  Will it eventually go away?
> 
> > I really don't want a new switch for this.  If we have to do something
> > I'd rather detect nfs and do something different.
> 
> Jäkel beat me to the punch on that one but he's absolutely right.  The
> whole delete a file with the file handle still open is known to NOT work
> properly over NFS.

So are a lot of other things :)

> In the back of my mind, I seem to recall some
> discussion over whether NFS v3 would handle that case properly or not.
> I could be wrong there but earlier versions would definitely NOT behave
> as intended.  I have no clue if it works over AFS or SMB but I
> definitely would not trust it over any network file system.  The results
> could be unpredictable.

I don't mind reverting that patch, but we're not putting in a config
switch for it.  My preference is for lxc to detect a netfs and behave
differently there.




More information about the lxc-devel mailing list