--a0hUfxJ20zFHaLM9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Jun 23, 2011 at 09:31:09AM -0700, David O'Brien wrote:
> Does anyone object to this patch?
>=20
> David Wolfskill and I have run TMPFS on a number of machines for two
> years with no problems.
>=20
> I may have missed something, but I'm not aware of any serious PRs on
> TMPFS either.
>=20
>=20
> Index: tmpfs_vfsops.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- tmpfs_vfsops.c (revision 221113)
> +++ tmpfs_vfsops.c (working copy)
> @@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp)
> return EOPNOTSUPP;
> }
> =20
> - printf("WARNING: TMPFS is considered to be a highly experimental "
> - "feature in FreeBSD.\n");
> -
> vn_lock(mp->mnt_vnodecovered, LK_SHARED | LK_RETRY);
> error =3D 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.
Removing the warning will not make the issues coming away.
--a0hUfxJ20zFHaLM9
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)
iEYEARECAAYFAk4DoGEACgkQC3+MBN1Mb4j9wwCg0V37VuQUw5heAl/Z/iAlO+h0
SmAAoJf/+BF533SS0hUjGsscsSAqUApX
=5GKO
-----END PGP SIGNATURE-----
--a0hUfxJ20zFHaLM9--