Re: old bug: mount_nfs path/name is limited to 88 chars
On Tue, Jan 20, 2015 at 12:45:32PM +0100, Willem Jan Withagen wrote: | On 2015-01-20 2:05, Xin Li wrote: | >>Doing it in 11 makes sense since there is a compat layer for 10 | >>now? if I knew all of the steps I would happily do them as annoys | >>me from time to time as well with the path length issue. | > | >Compat layer may break applications in other funny ways and we | >probably have to return e.g. ENAMETOOLONG for legacy applications if | >the names are too long to fit into the buffer, but I don't see any | >easy solution either: I wish we have bumped it in 2003 when the struct | >receives its first big revamp by bumping all statistic fields to 64-bit. | | On 2015-01-20 1:23, Allan Jude wrote:> On 2015-01-19 16:20, Garrett > | > Especially with ZFS, I find I have a lot more mounts now, under longer | > and longer path names, and then I have | > .zfs/snapshots/snapshotnamehere/path/to/file | > | > etc. | > | > Definitely a +1 for "this is something we need for 11" | | +1 | | Well to be honest: Things are already broken for me ATM. | I do have paths that are too long, and tools trip over it. | | Things like building the locate database just don't have everything. | Which is a pain, especially for finding things fast in backups of ZFS, | where the path is even more convoluted that what Allan suggests | | So whether being bitten by the cat of the dog: it still hurts. | | Perhaps it is an intermediate solution to add new settings which are | going to be used for userspace programs, like USER_MNAMELEN and | USER_PATH_MAX. It will certainly give ENAMETOOLONG back when it involves | systemcalls. But then a lot of the other tool stuff would just function. I have a patch at: http://www.ambrisko.com/doug/mount/latest.patch for -current (Nov). It should work with most file systems, that is I tried to cover them all. I haven't tested with ZFS but it should work. I left some debug "HELLO's" in there just to make sure mounting looked right. They can be safely deleted. If someone wants to test it and report issues (with a simple test case) I can fix it and add it to my test script. This code won't be going into FreeBSD now since the 64 bit inode will negate the need for it since the size will be a lot larger. Thanks, Doug A. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: old bug: mount_nfs path/name is limited to 88 chars
On 2015-01-20 2:05, Xin Li wrote: Doing it in 11 makes sense since there is a compat layer for 10 now… if I knew all of the steps I would happily do them as annoys me from time to time as well with the path length issue. Compat layer may break applications in other funny ways and we probably have to return e.g. ENAMETOOLONG for legacy applications if the names are too long to fit into the buffer, but I don't see any easy solution either: I wish we have bumped it in 2003 when the struct receives its first big revamp by bumping all statistic fields to 64-bit. On 2015-01-20 1:23, Allan Jude wrote:> On 2015-01-19 16:20, Garrett > > Especially with ZFS, I find I have a lot more mounts now, under longer > and longer path names, and then I have > .zfs/snapshots/snapshotnamehere/path/to/file > > etc. > > Definitely a +1 for "this is something we need for 11" +1 Well to be honest: Things are already broken for me ATM. I do have paths that are too long, and tools trip over it. Things like building the locate database just don't have everything. Which is a pain, especially for finding things fast in backups of ZFS, where the path is even more convoluted that what Allan suggests So whether being bitten by the cat of the dog: it still hurts. Perhaps it is an intermediate solution to add new settings which are going to be used for userspace programs, like USER_MNAMELEN and USER_PATH_MAX. It will certainly give ENAMETOOLONG back when it involves systemcalls. But then a lot of the other tool stuff would just function. --WjW ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: old bug: mount_nfs path/name is limited to 88 chars
Xin Li wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 01/19/15 13:20, Garrett Cooper wrote: > > On Jan 19, 2015, at 8:46, Brandon Allbery > > wrote: > > > >> On Mon, Jan 19, 2015 at 10:44 AM, Anton Shterenlikht > >> wrote: > >> > >>> So perhaps changing MNAMELEN will break statfs(2) on -stable > >>> too? > >>> > >> > >> I believe the context there is not so much "-current is special", > >> as "changing it for everyone is bad news" (and this would > >> necessarily need to originate in -current). > > > > A compat layer needs to be created for all of the affected > > syscalls, and the change needs to be made. That’s it in a > > nutshell. > > > > Doing it in 11 makes sense since there is a compat layer for 10 > > now… if I knew all of the steps I would happily do them as annoys > > me from time to time as well with the path length issue. > > Compat layer may break applications in other funny ways and we > probably have to return e.g. ENAMETOOLONG for legacy applications if > the names are too long to fit into the buffer, but I don't see any > easy solution either: I wish we have bumped it in 2003 when the > struct > receives its first big revamp by bumping all statistic fields to > 64-bit. > > I personally think we probably better create a new API and keep the > existing one for (limited) compatibility. For instance, it may be > sensible to make f_mntfromname and f_mntonname fields variable length > and have the caller pass a pointer and their length. If we set an > arbitrary limit, no matter it's 88, 256 or 4096, one will hit it some > time. > > BTW. If someone wants to change statfs(2), please make sure to create > reverse-compatibility shims at the same time (see > lib/libc/sys/fcntl.c > for an example). The statfs(2) API is used in a lot of places, > especially fts(3), and breaking it either way (running new world with > old kernel, or running old world with new kernel) would be a big pain > to recover from. > Solaris has statvfs(), which might be a starting point for a new API. statfs(2) would have to be retained for compatibility with older binaries and I think there would still be some breakage for cases where the mount path does exceed MNAMELEN. All I can think of is that the mount path would have to be truncated for the compatibility code. (I don't know what kind of truncation would be preferred? Just chop it at 88 or do something like /sub1/.../mnt or 0 length?) I think a lot of things will bump up against PATH_MAX, so making the length that might be ok, although I like the new API having the buffer and its length being passed in as arguments, so at least the syscall API doesn't need to change again. Some variant of doing all this is in projects/ino64 I think, since it ends up changing assorted syscalls like stat(2) as well, along with versioning the libc functions affected by the syscall changes. (I'd guess fts(3) is one of them, but haven't looked.) I doubt these changes could be MFC'd (others mention doing this for FreeBSD11). What could be done and maybe MFC'd is to simply allow mounts with paths greater than 88, but truncate it to 88 for statfs(2). { I think this truncation will end up happening for the compatibility syscall code anyhow, even if a new statfs(2) is added, so maybe just let it happen, even if no new syscall is available. } There was a patch floating around for this and doing this would only impact mounts with paths > MNAMELEN. (mount_nfs could print a warning for paths > MNAMELEN instead of failing the mount.) Does this sound reasonable as a stop gap (and could it be MFC'd?)? rick > Cheers, > - -- > Xin LI https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.1.1 (FreeBSD) > > iQIcBAEBCgAGBQJUvanaAAoJEJW2GBstM+nsgoQP/0+Ulfmmmj9n9cWA0h1NxD3O > a59aZXxbFtRu2SkIZprzFOL4TLnmyKEthFGmUgRSm7SH3GuaWVPBsgHTjSddYA/f > vD3fBei780akT/higazmSENKR0eWqL0zENG8HJndQ0XLLcv8eeHZEFFhbUlYA4JU > 4ArzoKEwsxiQ4jKB+KSFRU4QR4Raarljx6m4gQyXO6QAPEcyO035YH+bJlMSPjYg > wcJZiZXmsRYsjZMhKDGeO5tIiD8R/UwOcMKsaQ/O+bwCgWtHFe5gLDKxGjMlLc9c > NuhXE2/xlyBdAf3OHTlgr61dPmArQl0pyLXDUfd8K0s05FQ22bGHaSCT0FyNNG0J > 55rnr30iDczVjQV1rTk9AwvsTJzACyaRrCV3zXGpxr86XwGFRta4ebMYZNuRXhdZ > sLsTZWpIc3gnvOH4CiZHPmr1mbHoAY1RN9G23T5ENu2zYNJVozXhJ4NkoZkKzxUj > b19qox4aKtG9QT7h5HU7R7Q64Sz2dYty8VD4OZ/azQrLGjVdI+2KUq6M3SAIRBro > IAmGY62OQyz8aDVhr/Ap/N7GnV4suCZf08kgg3+oREU0a8QAxEHCDnNH4MJ9xz6v > +2GpYWp0AuCFJ77XQC7IB6va1hK+PZnuOZ9yNVKTTadEwSk4GK2fQv6YwLjiyYKM > PiOk31dmRfQB+3mqZ+Oj > =a3fA > -END PGP SIGNATURE- > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: old bug: mount_nfs path/name is limited to 88 chars
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/19/15 13:20, Garrett Cooper wrote: > On Jan 19, 2015, at 8:46, Brandon Allbery > wrote: > >> On Mon, Jan 19, 2015 at 10:44 AM, Anton Shterenlikht >> wrote: >> >>> So perhaps changing MNAMELEN will break statfs(2) on -stable >>> too? >>> >> >> I believe the context there is not so much "-current is special", >> as "changing it for everyone is bad news" (and this would >> necessarily need to originate in -current). > > A compat layer needs to be created for all of the affected > syscalls, and the change needs to be made. That’s it in a > nutshell. > > Doing it in 11 makes sense since there is a compat layer for 10 > now… if I knew all of the steps I would happily do them as annoys > me from time to time as well with the path length issue. Compat layer may break applications in other funny ways and we probably have to return e.g. ENAMETOOLONG for legacy applications if the names are too long to fit into the buffer, but I don't see any easy solution either: I wish we have bumped it in 2003 when the struct receives its first big revamp by bumping all statistic fields to 64-bit. I personally think we probably better create a new API and keep the existing one for (limited) compatibility. For instance, it may be sensible to make f_mntfromname and f_mntonname fields variable length and have the caller pass a pointer and their length. If we set an arbitrary limit, no matter it's 88, 256 or 4096, one will hit it some time. BTW. If someone wants to change statfs(2), please make sure to create reverse-compatibility shims at the same time (see lib/libc/sys/fcntl.c for an example). The statfs(2) API is used in a lot of places, especially fts(3), and breaking it either way (running new world with old kernel, or running old world with new kernel) would be a big pain to recover from. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.1.1 (FreeBSD) iQIcBAEBCgAGBQJUvanaAAoJEJW2GBstM+nsgoQP/0+Ulfmmmj9n9cWA0h1NxD3O a59aZXxbFtRu2SkIZprzFOL4TLnmyKEthFGmUgRSm7SH3GuaWVPBsgHTjSddYA/f vD3fBei780akT/higazmSENKR0eWqL0zENG8HJndQ0XLLcv8eeHZEFFhbUlYA4JU 4ArzoKEwsxiQ4jKB+KSFRU4QR4Raarljx6m4gQyXO6QAPEcyO035YH+bJlMSPjYg wcJZiZXmsRYsjZMhKDGeO5tIiD8R/UwOcMKsaQ/O+bwCgWtHFe5gLDKxGjMlLc9c NuhXE2/xlyBdAf3OHTlgr61dPmArQl0pyLXDUfd8K0s05FQ22bGHaSCT0FyNNG0J 55rnr30iDczVjQV1rTk9AwvsTJzACyaRrCV3zXGpxr86XwGFRta4ebMYZNuRXhdZ sLsTZWpIc3gnvOH4CiZHPmr1mbHoAY1RN9G23T5ENu2zYNJVozXhJ4NkoZkKzxUj b19qox4aKtG9QT7h5HU7R7Q64Sz2dYty8VD4OZ/azQrLGjVdI+2KUq6M3SAIRBro IAmGY62OQyz8aDVhr/Ap/N7GnV4suCZf08kgg3+oREU0a8QAxEHCDnNH4MJ9xz6v +2GpYWp0AuCFJ77XQC7IB6va1hK+PZnuOZ9yNVKTTadEwSk4GK2fQv6YwLjiyYKM PiOk31dmRfQB+3mqZ+Oj =a3fA -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: old bug: mount_nfs path/name is limited to 88 chars
On 2015-01-19 16:20, Garrett Cooper wrote: > On Jan 19, 2015, at 8:46, Brandon Allbery wrote: > >> On Mon, Jan 19, 2015 at 10:44 AM, Anton Shterenlikht >> wrote: >> >>> So perhaps changing MNAMELEN will break statfs(2) on >>> -stable too? >>> >> >> I believe the context there is not so much "-current is special", as >> "changing it for everyone is bad news" (and this would necessarily need to >> originate in -current). > > A compat layer needs to be created for all of the affected syscalls, and the > change needs to be made. That’s it in a nutshell. > > Doing it in 11 makes sense since there is a compat layer for 10 now… if I > knew all of the steps I would happily do them as annoys me from time to time > as well with the path length issue. > > Thanks! > Especially with ZFS, I find I have a lot more mounts now, under longer and longer path names, and then I have .zfs/snapshots/snapshotnamehere/path/to/file etc. Definitely a +1 for "this is something we need for 11" -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: old bug: mount_nfs path/name is limited to 88 chars
On 19-1-2015 22:20, Garrett Cooper wrote: > On Jan 19, 2015, at 8:46, Brandon Allbery > wrote: > >> On Mon, Jan 19, 2015 at 10:44 AM, Anton Shterenlikht >> wrote: >> >>> So perhaps changing MNAMELEN will break statfs(2) on -stable >>> too? >>> >> >> I believe the context there is not so much "-current is special", >> as "changing it for everyone is bad news" (and this would >> necessarily need to originate in -current). > > A compat layer needs to be created for all of the affected syscalls, > and the change needs to be made. That’s it in a nutshell. > > Doing it in 11 makes sense since there is a compat layer for 10 now… > if I knew all of the steps I would happily do them as annoys me from > time to time as well with the path length issue. Well after this the next problem you'll be running into is: #definePATH_MAX 1024 /* max bytes in pathname */ Which I already did inf find(1) because the paths in backups of big filesystems already bit in like 2011. Talked about it with Jilles, and got more or less the same answer: You can up the value, but expect things to break. Which it did when I only fixed the size in find. It would break in the program that got the path fed. Never dared to just up the value, compile kernel/world, install and reboot. And then see what comes of it. So IMHO if possible this would need to be extended as well... --WjW ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: old bug: mount_nfs path/name is limited to 88 chars
On Jan 19, 2015, at 8:46, Brandon Allbery wrote: > On Mon, Jan 19, 2015 at 10:44 AM, Anton Shterenlikht > wrote: > >> So perhaps changing MNAMELEN will break statfs(2) on >> -stable too? >> > > I believe the context there is not so much "-current is special", as > "changing it for everyone is bad news" (and this would necessarily need to > originate in -current). A compat layer needs to be created for all of the affected syscalls, and the change needs to be made. That’s it in a nutshell. Doing it in 11 makes sense since there is a compat layer for 10 now… if I knew all of the steps I would happily do them as annoys me from time to time as well with the path length issue. Thanks! signature.asc Description: Message signed with OpenPGP using GPGMail
Re: old bug: mount_nfs path/name is limited to 88 chars
On Mon, Jan 19, 2015 at 10:44 AM, Anton Shterenlikht wrote: > So perhaps changing MNAMELEN will break statfs(2) on > -stable too? > I believe the context there is not so much "-current is special", as "changing it for everyone is bad news" (and this would necessarily need to originate in -current). -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: old bug: mount_nfs path/name is limited to 88 chars
>From rmack...@uoguelph.ca Mon Jan 19 15:37:25 2015 >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=167105 >> >> is a show stopper for me. The path/name length is >> beyond my control, so I cannot make it shorter. >> >> This discussion seems inconclusive: >> http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038543.html >> >> Is there no easy solution to this PR? >> Or is there no interest in fixing the issue? >> >Well, the "easy" solution is to just increase the value >of NNAMELEN and rebuild everything from sources to use >the modified sys/mount.h. (If you can run a modified >system built entirely from sources, I think you can do >this.) I can do this on several 10.1-stable systems, but I understood from the email trail that there is no guarantee that nothing will be broken by such change. I know there is never a guarantee, but.. >However, this can't be done in -current because it breaks >the statfs(2) syscall API, etc. Even on 10.1-stable I see in statfs(2): #define MNAMELEN88 /* size of on/from name bufs */ So perhaps changing MNAMELEN will break statfs(2) on -stable too? Anton ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: old bug: mount_nfs path/name is limited to 88 chars
Anton Shterenlikht wrote: > This bug: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=167105 > > is a show stopper for me. The path/name length is > beyond my control, so I cannot make it shorter. > > This discussion seems inconclusive: > http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038543.html > > Is there no easy solution to this PR? > Or is there no interest in fixing the issue? > Well, the "easy" solution is to just increase the value of NNAMELEN and rebuild everything from sources to use the modified sys/mount.h. (If you can run a modified system built entirely from sources, I think you can do this.) However, this can't be done in -current because it breaks the statfs(2) syscall API, etc. There is a patch in projects/ino64 to try and change ino_t to 64bits and I think it also included changes for this. - It would need a new statfs(2) syscall and versioned library routines for everything that uses statfs(2) in libc, etc. So, for -current the answer is "it is not easy". There was a patch floating around that truncated the path to 64bits, so that the mounts are allowed but not reported correctly via statfs(2). You can probably find that patch and use it, if a broken statfs(2) isn't a problem for you. rick > Thanks > > Anton > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
old bug: mount_nfs path/name is limited to 88 chars
This bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=167105 is a show stopper for me. The path/name length is beyond my control, so I cannot make it shorter. This discussion seems inconclusive: http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038543.html Is there no easy solution to this PR? Or is there no interest in fixing the issue? Thanks Anton ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"