Re: SSH Chroot FreeBSD 10.1 and 10.2
Op zaterdag 22 augustus 2015 heeft Roger Leigh het volgende geschreven: > On 22/08/2015 15:01, Brandon Allbery wrote: > >> On Sat, Aug 22, 2015 at 10:54 AM, Rainer Duffner >> wrote: >> >> I found it’s much easier to have actual chroot’ed ssh users once the users >>> themselves are in an LDAP-directory. >>> Also, for doing anything useful on that shell, it turned out you need a >>> some more devices in /dev than the usual chroot (like a chroot’ed >>> PHP-FPM, >>> that just needs the dev-set of jail(4)). >>> And a couple of symlinks. >>> >>> >> Yep; chroots are always a pain to deal with. I have seen utilities to >> manage them, but only for Linux. >> > > For your information, I'm in the process of porting my schroot chroot > management tool to FreeBSD. > > https://github.com/codelibre-net/schroot > > This was traditionally a Linux (Debian) chroot tool for building source > packages, but it's worked on Debian GNU/kFreeBSD for a good while so it > already supported nullfs filesystem mounts e.g. of home directories and > devices, and now the work to build it on FreeBSD proper is done--I was > blocked on toolchain/linker bugs for the last 18 months until 10.2 came out > (C++11 nullptr_t was broken) > > The master branch is current development work, and I got it all building > on FreeBSD 10.2-RELEASE just yesterday. It's not yet actually *tested* on > FreeBSD other than the unit tests pass. So it might not be > production-ready right now, but it should be fairly soon. Now it's > building, I'll also look at adding some FreeBSD-specific features to it as > well, like ZFS snapshots, jail support, etc. > > While the compiled binaries should be fine, there may be residual > Debianisms/GNU libc-isms in the setup scripts. They are likely trivial to > fix though. > > If anyone wants to give it a try and provide some feedback, or if you have > any suggestions or feature requests, please just let me know either by mail > or at https://github.com/codelibre-net/schroot/issues > Instructions for building on FreeBSD are in the README > https://github.com/codelibre-net/schroot/blob/master/README.md > > > > Kind regards, > Roger > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" Thank you all for your time and contribution. I will look at the suggestions given here in the coming days. Regards Johan ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ix(intel) vs mlxen(mellanox) 10Gb performance
> On 22 Aug 2015, at 14:59, Rick Macklem wrote: > > Daniel Braniss wrote: >> >>> On Aug 22, 2015, at 12:46 AM, Rick Macklem wrote: >>> >>> Yonghyeon PYUN wrote: On Wed, Aug 19, 2015 at 09:00:35AM -0400, Rick Macklem wrote: > Hans Petter Selasky wrote: >> On 08/19/15 09:42, Yonghyeon PYUN wrote: >>> On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter Selasky wrote: On 08/18/15 23:54, Rick Macklem wrote: > Ouch! Yes, I now see that the code that counts the # of mbufs is > before > the > code that adds the tcp/ip header mbuf. > > In my opinion, this should be fixed by setting if_hw_tsomaxsegcount > to > whatever > the driver provides - 1. It is not the driver's responsibility to > know if > a tcp/ip > header mbuf will be added and is a lot less confusing that expecting > the > driver > author to know to subtract one. (I had mistakenly thought that > tcp_output() had > added the tc/ip header mbuf before the loop that counts mbufs in the > list. > Btw, > this tcp/ip header mbuf also has leading space for the MAC layer > header.) > Hi Rick, Your question is good. With the Mellanox hardware we have separate so-called inline data space for the TCP/IP headers, so if the TCP stack subtracts something, then we would need to add something to the limit, because then the scatter gather list is only used for the data part. >>> >>> I think all drivers in tree don't subtract 1 for >>> if_hw_tsomaxsegcount. Probably touching Mellanox driver would be >>> simpler than fixing all other drivers in tree. >>> Maybe it can be controlled by some kind of flag, if all the three TSO limits should include the TCP/IP/ethernet headers too. I'm pretty sure we want both versions. >>> >>> Hmm, I'm afraid it's already complex. Drivers have to tell almost >>> the same information to both bus_dma(9) and network stack. >> >> Don't forget that not all drivers in the tree set the TSO limits before >> if_attach(), so possibly the subtraction of one TSO fragment needs to go >> into ip_output() >> > Ok, I realized that some drivers may not know the answers before > ether_ifattach(), > due to the way they are configured/written (I saw the use of > if_hw_tsomax_update() > in the patch). I was not able to find an interface that configures TSO parameters after if_t conversion. I'm under the impression if_hw_tsomax_update() is not designed to use this way. Probably we need a better one?(CCed to Gleb). > > If it is subtracted as a part of the assignment to if_hw_tsomaxsegcount > in > tcp_output() > at line#791 in tcp_output() like the following, I don't think it should > matter if the > values are set before ether_ifattach()? > /* >* Subtract 1 for the tcp/ip header mbuf that >* will be prepended to the mbuf chain in this >* function in the code below this block. >*/ > if_hw_tsomaxsegcount = tp->t_tsomaxsegcount - 1; > > I don't have a good solution for the case where a driver doesn't plan on > using the > tcp/ip header provided by tcp_output() except to say the driver can add > one > to the > setting to compensate for that (and if they fail to do so, it still > works, > although > somewhat suboptimally). When I now read the comment in sys/net/if_var.h > it > is clear > what it means, but for some reason I didn't read it that way before? (I > think it was > the part that said the driver didn't have to subtract for the headers > that > confused me?) > In any case, we need to try and come up with a clear definition of what > they need to > be set to. > > I can now think of two ways to deal with this: > 1 - Leave tcp_output() as is, but provide a macro for the device driver > authors to use > that sets if_hw_tsomaxsegcount with a flag for "driver uses tcp/ip > header mbuf", > documenting that this flag should normally be true. > OR > 2 - Change tcp_output() as above, noting that this is a workaround for > confusion w.r.t. > whether or not if_hw_tsomaxsegcount should include the tcp/ip header > mbuf and > update the comment in if_var.h to reflect this. Then drivers that > don't > use the > tcp/ip header mbuf can increase their value for if_hw_tsomaxsegcount > by > 1. > (The comment should also mention that a value of 35 or greater is much > preferred to >32 i
Re: ix(intel) vs mlxen(mellanox) 10Gb performance
On Sun, Aug 23, 2015 at 02:08:56PM +0300, Daniel Braniss wrote: > >> send me the patch and I'll test it ASAP. > >>danny > >> > > Patch is attached. The one for head will also include an update to the > > comment > > in sys/net/if_var.h, but that isn't needed for testing. > > > well, the plot thickens. > > Yesterday, before running the new kernel, I decided to re run my test, and to > my surprise > i was getting good numbers, about 300MGB/s with and without TSO. > > this morning, the numbers were again bad, around 70MGB/s,what the ^%$#@! > > so, after some coffee, I run some more tests, and some conclusions: > using a netapp(*) as the nfs client: > - doing > ifconfig ix0 tso or -tso > does some magic and numbers are back to normal - for a while > > using another Fbsd/zfs as client all is nifty, actually a bit faster than the > netapp (not a fair > comparison, since the zfs client is not heavily used) and I can't see any > degradation. > > btw, this is with the patch applied, but was seeing similar numbers before > the patch. > > running with tso, initially I get around 300MGB/s, but after a while(sorry > can't be more scientific) > it drops down to about half, and finally to a pathetic 70MGB/s > > *: while running the tests I monitored the Netapp, and nothing out of the > ordinary there. Can you do this https://lists.freebsd.org/pipermail/freebsd-stable/2015-August/083138.html ? ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ia64 regression from r285809 to 286952: kernel does not boot
I'm not sure if ia64 list is still operational, so post here. ia64 r285809 10-STABLE works fine. I updated to r286952, buildworld, buildkernel, installkernel, reboot, boot -s, and I get stuck with: FreeBSD/ia64 EFI boot, Revision 3.0 (r...@mech-cluster241.men.bris.ac.uk, Thu May 5 11:18:40 BST 2011) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x11107f0 data=0xdfd68+0xa54f8 syms=[0x8+0xc2a78+0x8+0xb7965] - Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Entering /boot/kernel/kernel at 0x9ffc00010500... Have to do a power reset. Thanks Anton ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ia64 regression from r285809 to 286952: kernel does not boot
On Sun, Aug 23, 2015 at 03:51:58PM +0100, Anton Shterenlikht wrote: > I'm not sure if ia64 list is still operational, so > post here. > > ia64 r285809 10-STABLE works fine. > I updated to r286952, buildworld, buildkernel, installkernel, > reboot, boot -s, and I get stuck with: > > FreeBSD/ia64 EFI boot, Revision 3.0 > (r...@mech-cluster241.men.bris.ac.uk, Thu May 5 11:18:40 BST 2011) > Loading /boot/defaults/loader.conf > /boot/kernel/kernel text=0x11107f0 data=0xdfd68+0xa54f8 > syms=[0x8+0xc2a78+0x8+0xb7965] > - > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > Entering /boot/kernel/kernel at 0x9ffc00010500... > > Have to do a power reset. I think the way forward is to bisect. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ia64 regression from r285809 to 286952: kernel does not boot
> On Aug 23, 2015, at 7:51 AM, Anton Shterenlikht wrote: > > I'm not sure if ia64 list is still operational, so > post here. > > ia64 r285809 10-STABLE works fine. > I updated to r286952, buildworld, buildkernel, installkernel, > reboot, boot -s, and I get stuck with: > > FreeBSD/ia64 EFI boot, Revision 3.0 > (r...@mech-cluster241.men.bris.ac.uk, Thu May 5 11:18:40 BST 2011) > Loading /boot/defaults/loader.conf > /boot/kernel/kernel text=0x11107f0 data=0xdfd68+0xa54f8 > syms=[0x8+0xc2a78+0x8+0xb7965] > - > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > Entering /boot/kernel/kernel at 0x9ffc00010500… Do you have options DDB in your kernel configuration? If yes, can you boot without it? -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: ia64 regression from r285809 to 286952: kernel does not boot
>From mar...@xcllnt.net Sun Aug 23 20:40:48 2015 > >> On Aug 23, 2015, at 7:51 AM, Anton Shterenlikht = >wrote: >>=20 >> I'm not sure if ia64 list is still operational, so >> post here. >>=20 >> ia64 r285809 10-STABLE works fine. >> I updated to r286952, buildworld, buildkernel, installkernel, >> reboot, boot -s, and I get stuck with: >>=20 >> FreeBSD/ia64 EFI boot, Revision 3.0 >> (r...@mech-cluster241.men.bris.ac.uk, Thu May 5 11:18:40 BST 2011) >> Loading /boot/defaults/loader.conf >> /boot/kernel/kernel text=3D0x11107f0 data=3D0xdfd68+0xa54f8 = >syms=3D[0x8+0xc2a78+0x8+0xb7965] >> - >> Hit [Enter] to boot immediately, or any other key for command prompt. >> Booting [/boot/kernel/kernel]... >> Entering /boot/kernel/kernel at 0x9ffc00010500=E2=80=A6 > >Do you have options DDB in your kernel configuration? >If yes, can you boot without it? This is a GENERIC kernel, so no. Anton ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ix(intel) vs mlxen(mellanox) 10Gb performance
Daniel Braniss wrote: > > > On 22 Aug 2015, at 14:59, Rick Macklem wrote: > > > > Daniel Braniss wrote: > >> > >>> On Aug 22, 2015, at 12:46 AM, Rick Macklem wrote: > >>> > >>> Yonghyeon PYUN wrote: > On Wed, Aug 19, 2015 at 09:00:35AM -0400, Rick Macklem wrote: > > Hans Petter Selasky wrote: > >> On 08/19/15 09:42, Yonghyeon PYUN wrote: > >>> On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter Selasky wrote: > On 08/18/15 23:54, Rick Macklem wrote: > > Ouch! Yes, I now see that the code that counts the # of mbufs is > > before > > the > > code that adds the tcp/ip header mbuf. > > > > In my opinion, this should be fixed by setting if_hw_tsomaxsegcount > > to > > whatever > > the driver provides - 1. It is not the driver's responsibility to > > know if > > a tcp/ip > > header mbuf will be added and is a lot less confusing that > > expecting > > the > > driver > > author to know to subtract one. (I had mistakenly thought that > > tcp_output() had > > added the tc/ip header mbuf before the loop that counts mbufs in > > the > > list. > > Btw, > > this tcp/ip header mbuf also has leading space for the MAC layer > > header.) > > > > Hi Rick, > > Your question is good. With the Mellanox hardware we have separate > so-called inline data space for the TCP/IP headers, so if the TCP > stack > subtracts something, then we would need to add something to the > limit, > because then the scatter gather list is only used for the data part. > > >>> > >>> I think all drivers in tree don't subtract 1 for > >>> if_hw_tsomaxsegcount. Probably touching Mellanox driver would be > >>> simpler than fixing all other drivers in tree. > >>> > Maybe it can be controlled by some kind of flag, if all the three > TSO > limits should include the TCP/IP/ethernet headers too. I'm pretty > sure > we want both versions. > > >>> > >>> Hmm, I'm afraid it's already complex. Drivers have to tell almost > >>> the same information to both bus_dma(9) and network stack. > >> > >> Don't forget that not all drivers in the tree set the TSO limits > >> before > >> if_attach(), so possibly the subtraction of one TSO fragment needs to > >> go > >> into ip_output() > >> > > Ok, I realized that some drivers may not know the answers before > > ether_ifattach(), > > due to the way they are configured/written (I saw the use of > > if_hw_tsomax_update() > > in the patch). > > I was not able to find an interface that configures TSO parameters > after if_t conversion. I'm under the impression > if_hw_tsomax_update() is not designed to use this way. Probably we > need a better one?(CCed to Gleb). > > > > > If it is subtracted as a part of the assignment to if_hw_tsomaxsegcount > > in > > tcp_output() > > at line#791 in tcp_output() like the following, I don't think it should > > matter if the > > values are set before ether_ifattach()? > > /* > > * Subtract 1 for the tcp/ip header mbuf that > > * will be prepended to the mbuf chain in this > > * function in the code below this block. > > */ > > if_hw_tsomaxsegcount = tp->t_tsomaxsegcount - 1; > > > > I don't have a good solution for the case where a driver doesn't plan > > on > > using the > > tcp/ip header provided by tcp_output() except to say the driver can add > > one > > to the > > setting to compensate for that (and if they fail to do so, it still > > works, > > although > > somewhat suboptimally). When I now read the comment in sys/net/if_var.h > > it > > is clear > > what it means, but for some reason I didn't read it that way before? (I > > think it was > > the part that said the driver didn't have to subtract for the headers > > that > > confused me?) > > In any case, we need to try and come up with a clear definition of what > > they need to > > be set to. > > > > I can now think of two ways to deal with this: > > 1 - Leave tcp_output() as is, but provide a macro for the device driver > > authors to use > > that sets if_hw_tsomaxsegcount with a flag for "driver uses tcp/ip > > header mbuf", > > documenting that this flag should normally be true. > > OR > > 2 - Change tcp_output() as above, noting that this is a workaround for > > confusion w.r.t. > > whether or not if_hw_tsomaxse
