>Regarding Solaris 10, my understanding was that the current 32 group limit >could only be changed by modifying internal kernel structures that would >break backwards compatibility, which wouldn't happen because Solaris >guarantees backwards binary compatibility. I could most definitely be >mistaken though.
That's not entirely true; the issue is similar having more than 16 groups as it breaks AUTH_SYS over-the-wire "authentication" but we already have that now. But see: http://opensolaris.org/jive/thread.jspa?threadID=114685 For now, we're aiming for 1024 groups but also make sure that the userland will work without any dependencies. >> What's the bug number? > >There is no bug number :(, as they refuse to classify it as a bug -- they >keep insisting it is an RFE, and pointing towards the existing RFE #'s for >increasing the number of groups supported by Solaris. The "change request", then. It must have a bug id. >The service request is #71547904, although now that I think about it they >haven't been keeping the ticket updated. I'll send you a copy of the thread >I've had with the support engineers directly. > >Here's the patch I submitted. It adds three lines, one of which is blank >8-/. I'm just really confused why they'd rather spend months arguing it >isn't a bug rather than just spending five minutes applying this simple >patch <sigh>. I'd just run the version I compiled locally, but it's fairly >clear that the source code provided is not the same as the source code used >to generate the production binary, so I'd really prefer an official fix. Well, I can understand the sense of that. (Not for OpenSolaris, but for S10) A backport cost a bit so perhaps that's what they want to avoid. Casper _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
