Re: kern/184154: [cam] QUIRK: SYNC_CACHE not supported on IBM ServeRAID 8k
The following reply was made to PR kern/184154; it has been noted by GNATS. From: Matthew Jacob To: bug-follo...@freebsd.org, i...@itsmexpert.eu Cc: Subject: Re: kern/184154: [cam] QUIRK: SYNC_CACHE not supported on IBM ServeRAID 8k Date: Wed, 27 Nov 2013 14:09:41 -0800 Why do you think this is a serious error? All that the lack of this command support does is cause the driver to be noisy. The device still functions correctly, doesn't it? 10.X is frozen and won't be changed until after release. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/184340: PATH_MAX not interoperable with Linux
>Number: 184340 >Category: misc >Synopsis: PATH_MAX not interoperable with Linux >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Wed Nov 27 23:10:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: David Cundiff >Release:9.2-RELEASE >Organization: A2hosting >Environment: FreeBSD rsync6.a2hosting.com 9.2-STABLE FreeBSD 9.2-STABLE #0: Thu Oct 31 22:09:39 UTC 2013 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 >Description: PATH_MAX in is not interoperable with Linux when transferring files with Rsync. Since file paths can be much longer on Linux(4096 bytes) Rsync will crash as it sets up a buffer based on PATH_MAX. Also as unicode use increases a PATH_MAX of 1024 would limit paths to 256 32-bit unicode characters. Using 4096 bytes unicode paths could be 1024 characters. Sure Rsync could change the value in their source, however, there could be other programs that are used between FreeBSD and Linux that use the value and will have trouble. This is defined in the kernel headers /usr/src/sys/sys/syslimits.h:#define PATH_MAX 1024 /* max bytes in pathname */ >How-To-Repeat: Copy a file from a Linux machine to a FreeBSD machine where the pathname is greater than 1024 characters. >Fix: Change PATH_MAX in kernel to 4096 from 1024. Should be harmless and will fix the issue in any program that uses PATH_MAX from the kernel headers. Also would allow longer 32-bit unicode paths. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: misc/184340: PATH_MAX not interoperable with Linux
The following reply was made to PR misc/184340; it has been noted by GNATS. From: Brooks Davis To: David Cundiff Cc: freebsd-gnats-sub...@freebsd.org Subject: Re: misc/184340: PATH_MAX not interoperable with Linux Date: Wed, 27 Nov 2013 17:26:17 -0600 On Wed, Nov 27, 2013 at 11:03:31PM +, David Cundiff wrote: > Change PATH_MAX in kernel to 4096 from 1024. Should be harmless and will fix > the issue in any program that uses PATH_MAX from the kernel headers. Also > would allow longer 32-bit unicode paths. Blindly changing PATH_MAX would be far from harmless. It would bloat many internal structures and break ABIs and thus could not be done on a stable branch without quite a bit of work. This is probalby worth fixing for 11.0, ideally by removing the limit entierly as suggested by POSIX. -- Brooks ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/184154: [cam] QUIRK: SYNC_CACHE not supported on IBM ServeRAID 8k
The following reply was made to PR kern/184154; it has been noted by GNATS. From: i...@itsmexpert.eu To: mja...@freebsd.org, bug-follo...@freebsd.org Cc: Subject: Re: kern/184154: [cam] QUIRK: SYNC_CACHE not supported on IBM ServeRAID 8k Date: Thu, 28 Nov 2013 00:29:26 +0100 Just attempt to mount a ZFS pool on six RDM disks caused writing 13 error messages for each disk (78 error messages together, five line in dmesg each). The mount WAS NOT successful. ZFS uses SYNC_CACHE quite often (because of its principle), it can lead into significant performance degradation (if mounted). I can not tolerate such behaviour in production environment handling terabytes of archive data. I need to upgrade to 10.0 as soon as the STABLE version will be released. It seems I will have to patch and recompile kernel first. :-( On 27/11/2013 23:09, Matthew Jacob wrote: > Why do you think this is a serious error? All that the lack of this > command support does is cause the driver to be noisy. The device still > functions correctly, doesn't it? > > 10.X is frozen and won't be changed until after release. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: misc/184340: PATH_MAX not interoperable with Linux
On Wed, 27 Nov 2013, Brooks Davis wrote: On Wed, Nov 27, 2013 at 11:03:31PM +, David Cundiff wrote: > Change PATH_MAX in kernel to 4096 from 1024. Should be harmless and will fix the issue in any program that uses PATH_MAX from the kernel headers. Also would allow longer 32-bit unicode paths. Gak. Blindly changing PATH_MAX would be far from harmless. It would bloat many internal structures and break ABIs and thus could not be done on a stable branch without quite a bit of work. This is probalby worth fixing for 11.0, ideally by removing the limit entierly as suggested by POSIX. Should be almost as easy as changing NGROUPS_MAX :-). There is an interesting problem for the Linux (or any) compatibility layer. It cannot emulate a larger PATH_MAX than the native one. The emulated sysconf(__SC_PATH_MAX) returns the native PATH_MAX, but that might be incompatible with the emulated system's PATH_MAX. I don't see how this can work unless applications only use sysconf(__SC_PATH_MAX), but few applications are that portable. Similarly with all limits. There is obviously a problem if the host limit is smaller. There might even be be a problem if the host limit is larger, if the compatibility layer doesn't deal with it. But the compatibility layer doesn't even deal with security-related things like uid truncation in linux_getuid16(). Larger uids on the host are an example of where the host limit (UID_MAX here) being larger causes problems. The compatibility layer can't quite deal with this since getuid() is broken as designed and can't fail (and no one checks for it failing). The best it can do is return an unprivileged 16-bit id. nobody = 65534 is OK. Sysadmins can deal with this by never using uids above 65535, except there are a couple of reserved uids (one for nfs) near UINT32_MAX. sysconf() and pathconf() doesn't seem to be emulated. Bruce ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: misc/184340: PATH_MAX not interoperable with Linux
The following reply was made to PR misc/184340; it has been noted by GNATS. From: David Cundiff To: Brooks Davis Cc: freebsd-gnats-sub...@freebsd.org Subject: Re: misc/184340: PATH_MAX not interoperable with Linux Date: Wed, 27 Nov 2013 20:21:40 -0500 On 11/27/2013 6:26 PM, Brooks Davis wrote: > On Wed, Nov 27, 2013 at 11:03:31PM +, David Cundiff wrote: >> Change PATH_MAX in kernel to 4096 from 1024. Should be harmless and will >> fix the issue in any program that uses PATH_MAX from the kernel headers. >> Also would allow longer 32-bit unicode paths. > Blindly changing PATH_MAX would be far from harmless. It would bloat > many internal structures and break ABIs and thus could not be done on > a stable branch without quite a bit of work. This is probalby worth > fixing for 11.0, ideally by removing the limit entierly as suggested by > POSIX. > > -- Brooks Now that you mention it both of those would be an issue(I am not much of a programmer). We did just adjust it in the kernel source and several structs needed to be made larger as well. We tested it, everything seems to work, but who knows what other things we don't use broke. The ABI change seems safe enough for my use of the OS as a backup system, probably not for others. I figured I'd mention it as Linux went to 4096. I imagine their reasoning was for allowing larger unicode paths. While 1024 characters for a path seems pretty excessive, 256(with 4 byte characters) seems a bit short. Dave ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
