[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