Re: can't change tty speed and buffer size on 8.0
* Mikolaj Golub wrote:
> So 115200/5=23040 would be more then enough for me :-)
Great. I've attached a patch that should allow the buffer size to be
configured. Unfortunately gettytab currently sets the baud rate to
115200, which means we'll always use buffer sizes. I think we'd better
just remove the baud rate assignment and let the kernel decide which
default baud rate for the console is the best.
I'll commit the patch within the next couple of days. Let me know
whether you experience any problems with it.
--
Ed Schouten
WWW: http://80386.nl/
Index: etc/gettytab
===
--- etc/gettytab (revision 197973)
+++ etc/gettytab (working copy)
@@ -162,7 +162,7 @@
:fd@:nd@:cd@:rw:sp#9600:
P|Pc|Pc console:\
- :ht:np:sp#115200:
+ :ht:np:
#
# Wierdo special case for fast crt's with hardcopy devices
Index: sys/kern/tty.c
===
--- sys/kern/tty.c (revision 197973)
+++ sys/kern/tty.c (working copy)
@@ -842,8 +842,19 @@
ttydevsw_defparam(struct tty *tp, struct termios *t)
{
- /* Use a fake baud rate, we're not a real device. */
- t->c_ispeed = t->c_ospeed = TTYDEF_SPEED;
+ /*
+ * Allow the baud rate to be adjusted for pseudo-devices, but at
+ * least restrict it to 115200 to prevent excessive buffer
+ * usage. Also disallow 0, to prevent foot shooting.
+ */
+ if (t->c_ispeed < B50)
+ t->c_ispeed = B50;
+ else if (t->c_ispeed > B115200)
+ t->c_ispeed = B115200;
+ if (t->c_ospeed < B50)
+ t->c_ospeed = B50;
+ else if (t->c_ospeed > B115200)
+ t->c_ospeed = B115200;
return (0);
}
pgp4uX75ig0Jl.pgp
Description: PGP signature
Re: can't change tty speed and buffer size on 8.0
On Mon, 12 Oct 2009 09:08:29 +0200 Ed Schouten wrote: > * Mikolaj Golub wrote: >> So 115200/5=23040 would be more then enough for me :-) > > Great. I've attached a patch that should allow the buffer size to be > configured. Unfortunately gettytab currently sets the baud rate to > 115200, which means we'll always use buffer sizes. I think we'd better > just remove the baud rate assignment and let the kernel decide which > default baud rate for the console is the best. > > I'll commit the patch within the next couple of days. Let me know > whether you experience any problems with it. Applied and it works for me. Thanks. If I notice any issues I will let you know :-) -- Mikolaj Golub ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: openssh concerns
Robert Watson 2009-10-11: > On Thu, 8 Oct 2009, Oliver Fromme wrote: > >Are you sure? The majority of BSD machines in my vicinity > >have multiple accounts. > > > >And even if there's only one account, there is no reason to be > >careless with potential port-takeover risks. > > > >Therefore I advise against running critical daemons on > >unprivileged ports, especially on machines with shell > >accounts. And if you need to bind to a port >= 1024, use > >mac_portacl(4) to protect it. It's easy to use. > >Alternatively you can increase the value of the sysctl > >net.inet.ip.portrange.reservedhigh, but this is less flexible > >and might have unwanted side effects. > > And, for those that haven't already noticed, "options MAC" is > compiled into GENERIC on 8.0, so working with MAC policies no > longer requires a recompile (or in many cases, even a reboot). If your situation allows running pf, then there's an alternative method: bind sshd normally to port 22, but use pf to deny direct connections to port 22, redirecting connections to some high port X to port 22 using a `rdr pass' rule. You can even make exceptions for trusted IP address ranges which are then allowed to SSH in directly on port 22. That way, an unprivileged process will gain nothing by listening on high port X; it won't get to accept() any SSH connections. -- Daniel Roethlisberger http://daniel.roe.ch/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Kernel Build Issues with latest cvsup of both a 7.2 system, and a 6.4 system..
Not sure if I am just having a run of bad luck here, but I have a bunch of various free BSD boxen on both 6.4-STABLE, and on 7.2-STABLE. I try and make it a point to do a cvsup and update the machines every month or so to keep things current and any updates/patches installed. I decided a couple days ago, it was again time to do this again. So I ran cvsup on the machines, and set out to rebuild, first doing a 'make buildworld', then a 'make installworld', and finally a 'mergemaster' on the servers. That all went well, then time for a kernel update, so I performed a 'make buildkernel KERNCONF=GENERIC' to create the new kernel, which is where things went bad. On my 6.4-STABLE x86 machine, I received the following: cc -c -O -pipe -march=pentium4 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/dev/ath -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /usr/src/sys/kern/kern_event.c /usr/src/sys/kern/kern_event.c:408: warning: no previous prototype for 'knote_fork' *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. On my 7.2-STABLE amd64 machine, I received the following: cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=nocona -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/gnu/fs/xfs/FreeBSD -I/usr/src/sys/gnu/fs/xfs/FreeBSD/support -I/usr/src/sys/gnu/fs/xfs -I/usr/src/sys/contrib/opensolaris/compat -I/usr/src/sys/dev/cxgb -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding /usr/src/sys/amd64/amd64/genassym.c In file included from /usr/src/sys/vm/pmap.h:82, from /usr/src/sys/amd64/amd64/genassym.c:61: ./machine/pmap.h:323: error: expected declaration specifiers or '...' before 'vm_memattr_t' *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 I have rebuilt the above servers many times over, and I must say it's worked great, so was really thrown that not only one version on a server would blow up, but two different versions of the OS would pop at the same moment. Needless to say I haven't tried to rebuild any of my other 6.4 or 7.2 boxen yet, as I want to get the above two attempts sorted out first. Has something changed I am forgetting to do that is not biting me in the backside, or has some bug been introduced I am now aware of currently causing issues?? If anyone can help sort this out, or if you need additional info, please let me know.. --- Howard Leadmon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Any recommended Intel server motherboards?
The Intel boards all in all tend to be pretty well supported... we run a number of S3200SHL boards (about to be EOL'd I believe) and older S2000 series in production without any hitches. The basic Intel soft-RAID on the entry level boards should be avoided (use gmirror or similar if need be). If you are looking at any of the boards with onboard SAS, this is usually an LSI Logic based chipset (mfi driver from memory) and is fine as far as RAID reliability goes (at least in our experience, YMMV)... -- Antony On Mon, Oct 12, 2009 at 12:55 PM, Clifton Royston wrote: > A client is asking me to recommend hardware for a mailserver; they're > an OEM and whitebox builder, and would prefer to use an Intel server > board which seems reasonable. Are there any particularly recommended > current models? > > I seem to recall that Intel's RAID hardware is not that reliable, so > I am assuming I should either recommend they use plain SATA or SAS > drives, or steer them to an external RAID system with dedicated > controller. If that's changed, it would be nice to know. > > Parameters: > > The system will not be very high-throughput, primarily fronting and > acting as relay and storage queue for initially about 5000 mailboxes in > 100+ domains. All spam filtering will be handled on another box. > > -- Clifton > > -- > Clifton Royston -- clift...@iandicomputing.com / clift...@lava.net > President - I and I Computing * http://www.iandicomputing.com/ > Custom programming, network design, systems and network consulting services > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: openssh concerns
Daniel Roethlisberger wrote: > If your situation allows running pf, then there's an alternative > method: bind sshd normally to port 22, but use pf to deny direct > connections to port 22, redirecting connections to some high port > X to port 22 using a `rdr pass' rule. You can even make > exceptions for trusted IP address ranges which are then allowed > to SSH in directly on port 22. That way, an unprivileged process > will gain nothing by listening on high port X; it won't get to > accept() any SSH connections. Just for completeness sake, the same can be done easily with IPFW and "fwd" rules, of course. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C++ is to C as Lung Cancer is to Lung." -- Thomas Funke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others)
I'm copying this over from the freebsd-performance list, as I'm looking for a few more opinions - not on the problems *I* am having, but rather to check whether the problem is universal or not, and if not, find a possible common factor. In other words: I want to hear about your experiences, *good or bad*! Here's the original thread (not from the beginning, though): http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html Long story short, my version: when the disk is stressed hard enough, console IO becomes COMPLETELY unbearable. 10+ seconds to switch between windows in screen(1), running (or even typing) simple commands, etc. This happens both via SSH and the serial console. How to reproduce/test: 1) time file /etc/* > /dev/null a few times, or something similar that uses the disk; write down a common/average/median/whatever time. 2) cat /dev/zero > /uncompressed_fs/filename # please make *sure* it's uncompressed, since ZFS with lzjb/gzip enabled will squish this into a kilobyte-sized file, thus creating virtually *no* IO. 3) When cat has been running say 10 seconds, re-time command #1 and do some interactive stuff - run commands, edit files, etc. I couldn't actually reproduce the *completely* horrific increase in latency I posted about below just now (I did update my sources and rebuild, but I'm pretty sure the delta between ~Sep 29 and Oct 6 had no major IO changes in 8-STABLE), and the "time file /etc/*" test "only" jumped by about 3x (compared to 20-60x+ previously), but it's still bad enough: commands such as "ls" and "w" take 2-3 seconds to run, as opposed to 0.005s for ls without the added IO... On Linux, the increase in latency is closer to 4%. A bit better than, oh, 400 times. ;) Oh, and again: this post is not a complaint; this is a post asking for your experiences. I know I'm not alone in having these issues - I just want to know if there are a lot of people that *don't* too, and what could cause them. I can't possibly switch to FreeBSD in production with this behaviour - and I've been looking forward to doing so for quite a while now. Regards, Thomas PS. I'll leave my post to the original discussion below. (I don't usually top post, but I don't consider this a reply, more of a new post with an addition below.) On Oct 5, 2009, at 10:45 AM, Thomas Backman wrote: Hey everyone, I'm having serious trouble with the same thing, and just found this thread while looking for the correct place to post. Looks like I found it. (I wrote most of the post before finding the thread, so some of it will seem a bit odd.) I run 8.0-RC1/amd64 with ZFS on an A64 3200+ with 2GB RAM and an old 80GB 7200rpm disk. My problem is that I get completely unacceptable latency on console IO (both via SSH and serial console) when the system is performing disk IO. The worst case I've noticed yet was when I tried copying a core dump from a lzjb compressed ZFS file system to a gzip-9 compressed one, to compare the file size/compression ratio. screen (1) took at LEAST ten seconds - probably a bit more - I'm not exaggerating here - to switch to another window, and an "ls" in an empty directory also about 5-10 seconds. Doing some silly CPU load with two instances of "yes >/dev/null" (on a single core, remember) doesn't change anything, the system remains very responsive. "cat /dev/zero > /uncompressed_fs/..." however produces the extreme slowdown. (On a gzip-1 FS it doesn't, since the file ends up extremely small - a kilobyte or so - even after a while, thus performing minimal IO). I'm thinking about switching to FreeBSD on my beefier "production" system (dual-core amd64, 4GB RAM, 4x1TB disks, compared to this one, single-core, 2GB RAM, 80GB disk), but unless I feel assured this won't happen there as well, I'm not so sure anymore. I can do any kind of heavy IO/compilation/whatever on that box, currently running Linux, and it's always unnoticable. In this case it's impossible *not* to notice that your key input is lagging behind 5-10 seconds... I thought multiple times that the box must have panicked. I do realize that the hardware isn't the best, especially the disks, but this is far worse than it should be! Here's some of the testing done in this thread (or at least something like it): [r...@chaos ~]# time file /etc/* >/dev/null real0m1.725s user0m0.993s sys 0m0.021s [r...@chaos ~]# time file /etc/* >/dev/null real0m1.008s user0m0.990s sys 0m0.015s [r...@chaos ~]# time file /etc/* >/dev/null real0m1.008s user0m0.967s sys 0m0.038s [r...@chaos ~]# time file /etc/* >/dev/null real0m1.015s user0m0.998s sys 0m0.008s So, pretty much exactly 1 second every time once the cache is warmed up. Now, let's try it 10 seconds after starting heavy disk writing... [r...@chaos ~]# cat /dev/zero > /DELETE_ME & (wait for 10 seconds) [r...@chaos ~]# t
Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others)
We're not running 8 yet but we do have a 7.x box which its under fairly high IO load doing mrtg graphs which has similar behaviour. When typing a command on ssh it will freeze for may seconds. I even went to far as to write a little C app which just prints out the time to screen and even that sees the big delay. Its always been like and I've never managed to get to the bottom of it, there's something in the IO / disk subsystem which can totally lock up the system under high IO load. Regards Steve - Original Message - From: "Thomas Backman" To: "freebsd-stable" Sent: Monday, October 12, 2009 8:48 PM Subject: Extreme console latency during disk IO (8.0-RC1,previous releases also affected according to others) I'm copying this over from the freebsd-performance list, as I'm looking for a few more opinions - not on the problems *I* am having, but rather to check whether the problem is universal or not, and if not, find a possible common factor. In other words: I want to hear about your experiences, *good or bad*! Here's the original thread (not from the beginning, though): http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html Long story short, my version: when the disk is stressed hard enough, console IO becomes COMPLETELY unbearable. 10+ seconds to switch between windows in screen(1), running (or even typing) simple commands, etc. This happens both via SSH and the serial console. How to reproduce/test: 1) time file /etc/* > /dev/null a few times, or something similar that uses the disk; write down a common/average/median/whatever time. 2) cat /dev/zero > /uncompressed_fs/filename # please make *sure* it's uncompressed, since ZFS with lzjb/gzip enabled will squish this into a kilobyte-sized file, thus creating virtually *no* IO. 3) When cat has been running say 10 seconds, re-time command #1 and do some interactive stuff - run commands, edit files, etc. I couldn't actually reproduce the *completely* horrific increase in latency I posted about below just now (I did update my sources and rebuild, but I'm pretty sure the delta between ~Sep 29 and Oct 6 had no major IO changes in 8-STABLE), and the "time file /etc/*" test "only" jumped by about 3x (compared to 20-60x+ previously), but it's still bad enough: commands such as "ls" and "w" take 2-3 seconds to run, as opposed to 0.005s for ls without the added IO... On Linux, the increase in latency is closer to 4%. A bit better than, oh, 400 times. ;) Oh, and again: this post is not a complaint; this is a post asking for your experiences. I know I'm not alone in having these issues - I just want to know if there are a lot of people that *don't* too, and what could cause them. I can't possibly switch to FreeBSD in production with this behaviour - and I've been looking forward to doing so for quite a while now. Regards, Thomas PS. I'll leave my post to the original discussion below. (I don't usually top post, but I don't consider this a reply, more of a new post with an addition below.) On Oct 5, 2009, at 10:45 AM, Thomas Backman wrote: Hey everyone, I'm having serious trouble with the same thing, and just found this thread while looking for the correct place to post. Looks like I found it. (I wrote most of the post before finding the thread, so some of it will seem a bit odd.) I run 8.0-RC1/amd64 with ZFS on an A64 3200+ with 2GB RAM and an old 80GB 7200rpm disk. My problem is that I get completely unacceptable latency on console IO (both via SSH and serial console) when the system is performing disk IO. The worst case I've noticed yet was when I tried copying a core dump from a lzjb compressed ZFS file system to a gzip-9 compressed one, to compare the file size/compression ratio. screen (1) took at LEAST ten seconds - probably a bit more - I'm not exaggerating here - to switch to another window, and an "ls" in an empty directory also about 5-10 seconds. Doing some silly CPU load with two instances of "yes >/dev/null" (on a single core, remember) doesn't change anything, the system remains very responsive. "cat /dev/zero > /uncompressed_fs/..." however produces the extreme slowdown. (On a gzip-1 FS it doesn't, since the file ends up extremely small - a kilobyte or so - even after a while, thus performing minimal IO). I'm thinking about switching to FreeBSD on my beefier "production" system (dual-core amd64, 4GB RAM, 4x1TB disks, compared to this one, single-core, 2GB RAM, 80GB disk), but unless I feel assured this won't happen there as well, I'm not so sure anymore. I can do any kind of heavy IO/compilation/whatever on that box, currently running Linux, and it's always unnoticable. In this case it's impossible *not* to notice that your key input is lagging behind 5-10 seconds... I thought multiple times that the box must have panicked. I do realize that the hardware isn't the best, especially the disks, but this is far wor
Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others)
On Mon, Oct 12, 2009 at 09:48:42PM +0200, Thomas Backman wrote: > I'm copying this over from the freebsd-performance list, as I'm > looking for a few more opinions - not on the problems *I* am having, > but rather to check whether the problem is universal or not, and if > not, find a possible common factor. > In other words: I want to hear about your experiences, *good or bad*! > > Here's the original thread (not from the beginning, though): > http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html > > Long story short, my version: when the disk is stressed hard enough, > console IO becomes COMPLETELY unbearable. 10+ seconds to switch > between windows in screen(1), running (or even typing) simple > commands, etc. This happens both via SSH and the serial console. hi, this issue (not specific to FreeBSD, and not new -- it has been like this forever) is discussed in some detail here http://www.bsdcan.org/2009/schedule/events/122.en.html The following code (a bit outdated) can help http://lists.freebsd.org/pipermail/freebsd-stable/2009-March/048704.html cheers luigi > How to reproduce/test: > 1) time file /etc/* > /dev/null a few times, or something similar that > uses the disk; write down a common/average/median/whatever time. > 2) cat /dev/zero > /uncompressed_fs/filename # please make *sure* it's > uncompressed, since ZFS with lzjb/gzip enabled will squish this into a > kilobyte-sized file, thus creating virtually *no* IO. > 3) When cat has been running say 10 seconds, re-time command #1 and do > some interactive stuff - run commands, edit files, etc. > > I couldn't actually reproduce the *completely* horrific increase in > latency I posted about below just now (I did update my sources and > rebuild, but I'm pretty sure the delta between ~Sep 29 and Oct 6 had > no major IO changes in 8-STABLE), and the "time file /etc/*" test > "only" jumped by about 3x (compared to 20-60x+ previously), but it's > still bad enough: commands such as "ls" and "w" take 2-3 seconds to > run, as opposed to 0.005s for ls without the added IO... On Linux, the > increase in latency is closer to 4%. A bit better than, oh, 400 > times. ;) > > Oh, and again: this post is not a complaint; this is a post asking for > your experiences. I know I'm not alone in having these issues - I just > want to know if there are a lot of people that *don't* too, and what > could cause them. I can't possibly switch to FreeBSD in production > with this behaviour - and I've been looking forward to doing so for > quite a while now. > > Regards, > Thomas > > PS. > > I'll leave my post to the original discussion below. (I don't usually > top post, but I don't consider this a reply, more of a new post with > an addition below.) > > On Oct 5, 2009, at 10:45 AM, Thomas Backman wrote: > > >Hey everyone, > >I'm having serious trouble with the same thing, and just found this > >thread while looking for the correct place to post. Looks like I > >found it. (I wrote most of the post before finding the thread, so > >some of it will seem a bit odd.) > > > >I run 8.0-RC1/amd64 with ZFS on an A64 3200+ with 2GB RAM and an old > >80GB 7200rpm disk. > > > >My problem is that I get completely unacceptable latency on console > >IO (both via SSH and serial console) when the system is performing > >disk IO. The worst case I've noticed yet was when I tried copying a > >core dump from a lzjb compressed ZFS file system to a gzip-9 > >compressed one, to compare the file size/compression ratio. screen > >(1) took at LEAST ten seconds - probably a bit more - I'm not > >exaggerating here - to switch to another window, and an "ls" in an > >empty directory also about 5-10 seconds. > >Doing some silly CPU load with two instances of "yes >/dev/null" (on > >a single core, remember) doesn't change anything, the system remains > >very responsive. "cat /dev/zero > /uncompressed_fs/..." however > >produces the extreme slowdown. (On a gzip-1 FS it doesn't, since the > >file ends up extremely small - a kilobyte or so - even after a > >while, thus performing minimal IO). > > > >I'm thinking about switching to FreeBSD on my beefier "production" > >system (dual-core amd64, 4GB RAM, 4x1TB disks, compared to this one, > >single-core, 2GB RAM, 80GB disk), but unless I feel assured this > >won't happen there as well, I'm not so sure anymore. I can do any > >kind of heavy IO/compilation/whatever on that box, currently running > >Linux, and it's always unnoticable. In this case it's impossible > >*not* to notice that your key input is lagging behind 5-10 > >seconds... I thought multiple times that the box must have panicked. > >I do realize that the hardware isn't the best, especially the disks, > >but this is far worse than it should be! > > > >Here's some of the testing done in this thread (or at least > >something like it): > > > >[r...@chaos ~]# time fi
Re: can't change tty speed and buffer size on 8.0
Mikolaj Golub wrote: > Hi, > > On 8.0-RC1 if you run this command: > > cat > /dev/null > > and try to input a long line, the maximum length you can input is 1920 > characters. > > I have investigated a bit how I can increase a tty buffer as this is a problem > for me (I have logs with very long lines and I used to copy&past a particular > line into input of some script to structure it). I have no useful input on the buffer size issue, but if you wanted to post a bit of your script we may be able to help you find a different solution that doesn't involve cat. :) Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD Status Reports April - September, 2009
On Sun, Oct 11, 2009 at 05:54:29PM +, Daniel Gerzo wrote: > FreeBSD/ZFS > >Contact: Pawel Dawidek > >We believe that the ZFS file system is now production-ready in FreeBSD >8.0. Most (if not all) reported bugs were fixed and ZFS is no longer >tagged as experimental. There is also ongoing work in Perforce to bring >the latest ZFS version (v19) to FreeBSD. That's great news. However, my experience says me not place dot-zero relese under business-critical tasks and load. What about status of ZFS in 7.2? Does 7.2 contain the same ZFS code? Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: can't change tty speed and buffer size on 8.0
On Mon, 12 Oct 2009 16:26:54 -0700 Doug Barton wrote: > Mikolaj Golub wrote: >> Hi, >> >> On 8.0-RC1 if you run this command: >> >> cat > /dev/null >> >> and try to input a long line, the maximum length you can input is 1920 >> characters. >> >> I have investigated a bit how I can increase a tty buffer as this is a >> problem >> for me (I have logs with very long lines and I used to copy&past a particular >> line into input of some script to structure it). > > I have no useful input on the buffer size issue, but if you wanted to > post a bit of your script we may be able to help you find a different > solution that doesn't involve cat. :) Thanks, but cat was taken as a simple example just to illustrate the problem. The real scripts are usually on perl with 'while(<>)' loop or 'perl -ne' one liners. And sure I could find ways to workaround the problem and actually this is what I did until ed@ provided the solution. -- Mikolaj Golub ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
