Re: Thoughts on TMPFS no longer being considered "highly experimental"

From: Peter Holm <peter_at_holm.cc>
Date: Fri, 24 Jun 2011 12:30:16 +0200
On Thu, Jun 23, 2011 at 11:21:53PM +0300, Kostik Belousov wrote:
> On Thu, Jun 23, 2011 at 09:31:09AM -0700, David O'Brien wrote:
> > Does anyone object to this patch?
> > 
> > David Wolfskill and I have run TMPFS on a number of machines for two
> > years with no problems.
> > 
> > I may have missed something, but I'm not aware of any serious PRs on
> > TMPFS either.
> > 
> > 
> > Index: tmpfs_vfsops.c
> > ===================================================================
> > --- tmpfs_vfsops.c	(revision 221113)
> > +++ tmpfs_vfsops.c	(working copy)
> > _at__at_ -155,9 +155,6 _at__at_ tmpfs_mount(struct mount *mp)
> >  		return EOPNOTSUPP;
> >  	}
> >  
> > -	printf("WARNING: TMPFS is considered to be a highly experimental "
> > -	    "feature in FreeBSD.\n");
> > -
> >  	vn_lock(mp->mnt_vnodecovered, LK_SHARED | LK_RETRY);
> >  	error = VOP_GETATTR(mp->mnt_vnodecovered, &va, mp->mnt_cred);
> >  	VOP_UNLOCK(mp->mnt_vnodecovered, 0);
> 
> The things I am aware of:
> - there is a races on the lookup. They were papered over in r212305,
> but the bug was not really fixed, AFAIR.
> 
> - the tmpfs does double-buffering for the mapped vnodes. This is quite
> insulting for the memory-backed fs, isn't it ? I have a patch, but it is
> still under review.
> 
> - I believe Peter Holm has more test cases that fails with tmpfs. He
> would have more details. I somewhat remember some panic on execve(2) the
> binary located on tmpfs.
> 

I ran the TMPFS tests I have and so far I only spotted the mmap(2)
problem:

http://people.freebsd.org/~pho/stress/log/tmpfs/

> Removing the warning will not make the issues coming away.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (FreeBSD)
> 
> iEYEARECAAYFAk4DoGEACgkQC3+MBN1Mb4j9wwCg0V37VuQUw5heAl/Z/iAlO+h0
> SmAAoJf/+BF533SS0hUjGsscsSAqUApX
> =5GKO
> -----END PGP SIGNATURE-----


-- 
Peter
Received on Fri Jun 24 2011 - 08:30:19 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:15 UTC