Re: Any objections/comments on axing out old ATA stack?
On Sun, Mar 31, 2013 at 03:02:09PM -0600, Scott Long wrote: On Mar 31, 2013, at 7:04 AM, Victor Balada Diaz vic...@bsdes.net wrote: On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: Hi. Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA stack, using only some controller drivers of old ata(4) by having `options ATA_CAM` enabled in all kernels by default. I have a wish to drop non-ATA_CAM ata(4) code, unused since that time from the head branch to allow further ATA code cleanup. Does any one here still uses legacy ATA stack (kernel explicitly built without `options ATA_CAM`) for some reason, for example as workaround for some regression? Does anybody have good ideas why we should not drop it now? Hello, At my previous job we had troubles with NCQ on some controllers. It caused failures and silent data corruption. As old ata code didn't use NCQ we just used it. I reported some of the problems on 8.2[1] but the problem existed with 8.3. I no longer have access to those systems, so i don't know if the problem still exists or have been fixed on newer versions. Regards. Victor. So what I hear you and Matthias saying, I believe, is that it should be easier to force disks to fall back to non-NCQ mode, and/or have a more responsive black-list for problematic controllers. Would this help the situation? It's hard to justify holding back overall forward progress because of some bad controllers; we do several Tbps off of AHCI controllers with NCQ enabled on FreeBSD 9.x, enough to make up a sizable percentage of the internet's traffic, and we see no problems. How can we move forward but also take care of you guys with problematic hardware? Scott Being able to configure quirks from loader.conf for disks AND controllers would be great and is not hard to do. If you want i can do a patch in two weeks and send it to you. That way it's easy to test disabling NCQ and/or other things in case of hitting a bug. Also being able to modify the configuration without a kernel recompile would be a big improvement because we could still use freebsd-update to keep systems updated. Anyway, my comment was not against dropping old ata code, but more on the comments on regresssions on the new one. Regards. Victor. -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. ___ 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: Any objections/comments on axing out old ATA stack?
On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: Hi. Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA stack, using only some controller drivers of old ata(4) by having `options ATA_CAM` enabled in all kernels by default. I have a wish to drop non-ATA_CAM ata(4) code, unused since that time from the head branch to allow further ATA code cleanup. Does any one here still uses legacy ATA stack (kernel explicitly built without `options ATA_CAM`) for some reason, for example as workaround for some regression? Does anybody have good ideas why we should not drop it now? Hello, At my previous job we had troubles with NCQ on some controllers. It caused failures and silent data corruption. As old ata code didn't use NCQ we just used it. I reported some of the problems on 8.2[1] but the problem existed with 8.3. I no longer have access to those systems, so i don't know if the problem still exists or have been fixed on newer versions. Regards. Victor. [1]: https://groups.google.com/forum/#!topic/muc.lists.freebsd.stable/dAMf028CtXM -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. ___ 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: pkg - Shared object libarchive.so.5 not found, required by pkg
On Fri, Nov 23, 2012 at 11:13:39PM +0100, Christer Solskogen wrote: I just upgraded a machine from 9.1-RC3 to 10-CURRENT. pkg was installed on 9.1, but after an upgrade to 10-CURRENT pkg no longer runs due to missing shared library. 10-CURRENT was built (and installed) twice. I guess the library was installed when I was at 9.1-RC3 but was deleted during make delete-old. Rebuilding pkg from src/usr.sbin/pkg did not do the trick. For some reason it was still linking to the old library. Any hints? Hello, You have pkg-static for that kind of problems. You should rebuild pkg port to get pkg working again. Regards. Victor. -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. ___ 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: [HEADSUP] current switched by default to pkgng
On Wed, Oct 10, 2012 at 03:44:21PM +0200, Baptiste Daroussin wrote: Hi all, If you are using the ports tree on a FreeBSD current setup, then you are concerned by the announce. As nvidia-drivers has been fixed and is now properly working with pkgng, the ports tree as been switch by default to use pkgng on FreeBSD Current based on version = 117 which was the version when we tested the switch code. Make sure to read UPDATING (from ports) to correctly migrate your system or find instruction to make your system still running with legacy pkg_install tools. regards, Bapt Hello Baptiste, Thanks a lot for your hard work. I've been using pkgng for a while on 9.0 and it's been a great experience. Right now you can use pointyhat packages[1] if you use old pkg tools. Is there any plan to create binary packages more often than once per release? Regards. Victor. [1]: http://pointyhat.freebsd.org/errorlogs/amd64-10-packages-latest/ -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. ___ 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: [HEADSUP] current switched by default to pkgng
On Wed, Oct 10, 2012 at 06:31:49PM +0200, Baptiste Daroussin wrote: Yes there is http://pkg.FreeBSD.org (no website in there no need to try to there) which will point you to pkgbeta.freebsd.org where some packages resides. Unfortunatly the package building cluster needs some time to get more reliable and thus the packages out there are not updated very often. regards, Bapt Is there anything we can do to help with build cluster reliability? Regards. Victor. -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. ___ 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: Idea for GEOM and policy based file encryption
On Wed, Mar 21, 2012 at 10:47:45AM +0100, Harald Schmalzbauer wrote: Hello, I personally don't have the need to encrypt whole filesystems and if I need to transfer sensitive data I use gpg to encrypt the tarball or whatever. But, I'd like to see some single files encrypted on my systems, eg. wpasupplicant.conf, ipsec.conf aso. Since I recently secured LDAP queries via IPSec, I found this to be the absolute perfect solution. Encryption takes place only where really needed with about no overhead (compared to SSL-LDAP) So would it be imaginable, that there's something like the SPD for network sockets also for files? The idea is that in this fileSPD, there's the entry that /etc/ipsec.conf must be aes encrypted. In a fileSA, there's the info that /etc/ipsec.conf can be read by uid xyz (or only one specific kernel, identified by something new to implement) and with a special key ID. The keys are loadad as modules, optionally symmetric encrypted by passphrase. Was such a policy based file encryption control doable with GEOM? Maybe it's easier to make use of existing tools like gpg with GEOM interaction? I don't want to reinvent any file encryption, I just need some automatic encryption (without _mandatory_ interaction) with lowest possible bypass possibilities. Thanks, Hello Harald, I'm not an expert, but i guess that GEOM is not the place for that kind of encryption. GEOM have no knowledge about files or directories. That is file system specific. You would need to modify UFS, or maybe do something like CFS[1]. CFS works as an NFS server and you could modify it to only cipher the needed files. Also you could write a simple FS on FUSE, but last time i checked, our FUSE support had some problems. I hope it helps. Regards. Victor. [1]: http://www.crypto.com/software/ -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. ___ 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
