Date: Tue, 5 Apr 2011 17:58:25 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Mark Blackman <mark@exonetric.com> Cc: freebsd-fs@freebsd.org Subject: Re: Knob to turn off _POSIX_NO_TRUNC Message-ID: <20110405145825.GC78089@deviant.kiev.zoral.com.ua> In-Reply-To: <7696AAE3-E04B-492F-9D96-3B526CFDFEE6@exonetric.com> References: <20110405141631.GA78089@deviant.kiev.zoral.com.ua> <7696AAE3-E04B-492F-9D96-3B526CFDFEE6@exonetric.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--b0HMt6CF7yv0Ir1M
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Apr 05, 2011 at 03:35:49PM +0100, Mark Blackman wrote:
>=20
> On 5 Apr 2011, at 15:16, Kostik Belousov wrote:
>=20
> > From very old and gloomy SysV times I remembered filesystem behaviour
> > that silently truncated the file name components to the NAME_MAX limit,
> > that was, AFAIR, 14. To much of my dismay, I met some usermode software
> > recently that blindly tried to create the file from externally provided
> > name, and sometimes failed with ENAMETOOLONG in similar situation.
> > The authors are not cooperative.
> >=20
> > I ended up with the following hack, which almost turns off the
> > _POSIX_NO_TRUNC behaviour, globally on the system. Patch allowed me
> > to proceed. The cost in the default case is a single check, which is
> > performed only on ENAMETOOLONG path.
>=20
> If this is global, it might deal with a failing test when building Perl
> on a ZFS-only system which also tests this property.
>=20
> In particular, I believe ZFS neither truncates nor returns an error for a=
ny=20
> pathname length, so I'm not sure what the right test result should be.
>=20
> Building perl produces something like..
>=20
> Only one test fails:
> ok 25 - calling pathconf("/tmp", _PC_NO_TRUNC)
> not ok 26 - checking that the returned value is defined (it isn't)
> or that errno is clear (it isn't, it's Invalid argument)
> # Failed test ' checking that the returned value is defined
> # (it isn't) or that errno is clear (it isn't, it's Invalid argument)'
> # at t/sysconf.t line 63.
>=20
> This thread..
>=20
> http://lists.freebsd.org/pipermail/freebsd-fs/2010-November/010069.html
>=20
> talked about the NO_TRUNC behaviour in the context of ZFS.
>=20
Reporting _PC_NO_TRUNC from zfs is easy, I think Pawel just had no time
to care about this detail. Anyway, it is not directly relevant to what
the posted patch did.
Patch below incorporates zfs change, and also reporting of the
vfs.lookup_trim from pathconf(2), just in case.
diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c b/s=
ys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c
index 17eedee..9985716 100644
--- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c
+++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c
@@ -5127,6 +5130,10 @@ zfs_pathconf(vnode_t *vp, int cmd, ulong_t *valp, cr=
ed_t *cr,
*valp =3D ACL_MAX_ENTRIES;
return (0);
=20
+ case _PC_NO_TRUNC:
+ *valp =3D 1;
+ return (0);
+
default:
return (EOPNOTSUPP);
}
diff --git a/sys/kern/vfs_lookup.c b/sys/kern/vfs_lookup.c
index 50a2570..9ecf4e0 100644
--- a/sys/kern/vfs_lookup.c
+++ b/sys/kern/vfs_lookup.c
@@ -99,6 +99,11 @@ SYSCTL_INT(_vfs, OID_AUTO, lookup_shared, CTLFLAG_RW, &l=
ookup_shared, 0,
"Enables/Disables shared locks for path name translation");
TUNABLE_INT("vfs.lookup_shared", &lookup_shared);
=20
+int lookup_trim;
+SYSCTL_INT(_vfs, OID_AUTO, lookup_trim, CTLFLAG_RW, &lookup_trim, 0,
+ "Enables/Disables trim of the long path component instead of ENAMETOOL=
ONG");
+TUNABLE_INT("vfs.lookup_trim", &lookup_trim);
+
/*
* Convert a pathname into a pointer to a locked vnode.
*
@@ -514,8 +519,14 @@ dirloop:
continue;
cnp->cn_namelen =3D cp - cnp->cn_nameptr;
if (cnp->cn_namelen > NAME_MAX) {
- error =3D ENAMETOOLONG;
- goto bad;
+ if (!lookup_trim) {
+ error =3D ENAMETOOLONG;
+ goto bad;
+ }
+ ndp->ni_pathlen -=3D cnp->cn_namelen - NAME_MAX;
+ cnp->cn_namelen =3D NAME_MAX;
+ strcpy(cnp->cn_nameptr + cnp->cn_namelen, cp);
+ cp =3D cnp->cn_nameptr + cnp->cn_namelen;
}
#ifdef NAMEI_DIAGNOSTIC
{ char c =3D *cp;
diff --git a/sys/kern/vfs_syscalls.c b/sys/kern/vfs_syscalls.c
index 4fc198e..9020223 100644
--- a/sys/kern/vfs_syscalls.c
+++ b/sys/kern/vfs_syscalls.c
@@ -2528,6 +2528,8 @@ lpathconf(td, uap)
return (kern_pathconf(td, uap->path, UIO_USERSPACE, uap->name, NOFOLLOW));
}
=20
+extern int lookup_trim;
+
int
kern_pathconf(struct thread *td, char *path, enum uio_seg pathseg, int nam=
e,
u_long flags)
@@ -2549,6 +2551,8 @@ kern_pathconf(struct thread *td, char *path, enum uio=
_seg pathseg, int name,
error =3D VOP_PATHCONF(nd.ni_vp, name, td->td_retval);
vput(nd.ni_vp);
VFS_UNLOCK_GIANT(vfslocked);
+ if (name =3D=3D _PC_NO_TRUNC && error =3D=3D 0 && td->td_retval !=3D 0)
+ td->td_retval[0] =3D !lookup_trim;
return (error);
}
=20
--b0HMt6CF7yv0Ir1M
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)
iEYEARECAAYFAk2bLhEACgkQC3+MBN1Mb4gyNACfQFQbxY7udUrWpRvVKSw7r8FS
vg8AoLGN2Vq2Hlar8Vr8Egc+clwzZ+TG
=3hom
-----END PGP SIGNATURE-----
--b0HMt6CF7yv0Ir1M--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110405145825.GC78089>