You haven't been bitten by the storage layer or filesystem hackery
bits which has caused filesystem corruption. :)
That said, FFS+SUJ has made recover-from-kernel-panic so much less
painful. Thankyou Jeffr and others!
What I tend to do is either run current on a VM or organise some
dedicated
On 3/6/2012 2:12 AM, Adrian Chadd wrote:
You haven't been bitten by the storage layer or filesystem hackery
bits which has caused filesystem corruption. :)
Ummm, I have, actually. I was one of the early adopters of SU+J and
complained loudly when it ate my /var/ for lunch. I also use a lot of
On 3/4/2012 2:04 PM, Adrian Chadd wrote:
2012/3/3 Doug Barton do...@freebsd.org:
On 03/02/2012 16:05, Adrian Chadd wrote:
Try breaking that cycle.
... one of the things I've been asking for years. :)
Julian's right though, I think PC-BSD will help, but I still think that
committers should
2012/3/3 Doug Barton do...@freebsd.org:
On 03/02/2012 16:05, Adrian Chadd wrote:
Try breaking that cycle.
... one of the things I've been asking for years. :)
Julian's right though, I think PC-BSD will help, but I still think that
committers should run -current. I've asked privately for our
On 03/03/12 07:44, H wrote:
Doug Barton wrote:
[...] Sure,
our strength is servers, and that is not going to change.
I agree and disagree. Based upon the struggle with desktop usage and
focus on development, FreeBSD is de facto more server oriented. But in
comparison to several other non-BSD
on 03/03/2012 13:44 O. Hartmann said the following:
Back to the topic of the initial posting:
Where can I find documentation for the idiot about flowtable? I can
switch this to ON in the kernel config on FreeBSD 9.0-STABLE as well as
in FreeBSD 10.0-CURRENT. But I can not find any hint
2012/3/2 Julian Elischer jul...@freebsd.org:
On 3/2/12 10:21 AM, Doug Barton wrote:
On 03/02/2012 03:44, K. Macy wrote:
not sure who wrote:
Correct. However, I'm not sure the analogy is flawed. I am, to some
degree, guilty of the same sin. I now run Ubuntu and have never had a
single
as a representative instance of a behaviour which
bothers me, and, taken over time, is detrimental to the whole.
Back to the initial subject line: flowtable usable or not
It is possible to re-structure the routing code to have a smaller
cache footprint / shorter lookup time / and eliminate all
I'm re-sending this portion of another mail as it will inevitably not
be read by most readers by virtue of having been part of a long and
digressive thread.
subject line: flowtable usable or not
It is possible to re-structure the routing code to have a smaller
cache footprint / shorter lookup
On 03/03/2012 08:53, K. Macy wrote:
a) We as a members of the community are collectively responsible for
the state of FreeBSD. Simply disabling features or removing
functionality that doesn't work or doesn't work optimally and / or
filing bug reports but not being able or willing to respond to
On 03/02/2012 16:05, Adrian Chadd wrote:
Try breaking that cycle.
... one of the things I've been asking for years. :)
Julian's right though, I think PC-BSD will help, but I still think that
committers should run -current. I've asked privately for our committers
to go back to -current and then
On Sat, Mar 3, 2012 at 9:54 PM, Doug Barton do...@freebsd.org wrote:
On 03/03/2012 08:53, K. Macy wrote:
a) We as a members of the community are collectively responsible for
the state of FreeBSD. Simply disabling features or removing
functionality that doesn't work or doesn't work optimally
On 03/03/2012 13:03, K. Macy wrote:
On Sat, Mar 3, 2012 at 9:54 PM, Doug Barton do...@freebsd.org wrote:
On 03/03/2012 08:53, K. Macy wrote:
a) We as a members of the community are collectively responsible for
the state of FreeBSD. Simply disabling features or removing
functionality that
On Sat, Mar 3, 2012 at 10:09 PM, Doug Barton do...@freebsd.org wrote:
On 03/03/2012 13:03, K. Macy wrote:
On Sat, Mar 3, 2012 at 9:54 PM, Doug Barton do...@freebsd.org wrote:
On 03/03/2012 08:53, K. Macy wrote:
a) We as a members of the community are collectively responsible for
the state of
On 03/01/2012 16:03, K. Macy wrote:
I understand the switch. Uptime is important in any production
network. However, it seems like it may have been too easy to turn it
off because no one has made any effort to help me debug the issues. By
analogy your guidance for ports usability problems
Apparently you've missed all the times that I've given that exact advice. :)
But your analogy is severely flawed. Flowtable was an experimental
feature that theoretically might have increased performance for some
work flows, but turned out to be fatally flawed. The ports system is an
On 03/02/2012 03:44, K. Macy wrote:
Apparently you've missed all the times that I've given that exact advice. :)
But your analogy is severely flawed. Flowtable was an experimental
feature that theoretically might have increased performance for some
work flows, but turned out to be fatally
... and here is the crux of the problem. The vast majority of our
developers don't use FreeBSD as their regular workstation. So it has
increasingly become an OS where changes are being lobbed over the wall
by developers who don't run systems that those changes affect. That's no
way to run a
On 03/02/2012 10:46, K. Macy wrote:
You understand my point but then fail to or choose not to see how it
applies to you when it creates problems for you personally.
No, I already pointed out the distinction between new, experimental
features; and essential components of the FreeBSD operating
No, I already pointed out the distinction between new, experimental
features; and essential components of the FreeBSD operating system.
It's Ok for you to disagree with that distinction, or with its
importance. But what you're suggesting is that if users don't help
developers debug cool new
Doug Barton wrote:
... and here is the crux of the problem. The vast majority of our
developers don't use FreeBSD as their regular workstation. So it has
increasingly become an OS where changes are being lobbed over the wall
by developers who don't run systems that those changes affect. That's
on 02/03/2012 20:21 Doug Barton said the following:
... and here is the crux of the problem. The vast majority of our
developers don't use FreeBSD as their regular workstation.
Do you care to back this up with facts?
Or are you going beyond constructive in your [self-]criticism of FreeBSD [OS,
On 3/2/2012 1:27 PM, Andriy Gapon wrote:
on 02/03/2012 20:21 Doug Barton said the following:
... and here is the crux of the problem. The vast majority of our
developers don't use FreeBSD as their regular workstation.
Do you care to back this up with facts?
You mean other than the very few
on 03/03/2012 00:24 Doug Barton said the following:
On 3/2/2012 1:27 PM, Andriy Gapon wrote:
on 02/03/2012 20:21 Doug Barton said the following:
... and here is the crux of the problem. The vast majority of our
developers don't use FreeBSD as their regular workstation.
Do you care to back
I've had the same problem with wireless.
For some users, wireless works flawlessly.
For other users, it's completely unusable.
Trying to get any kind of useful feedback from people has been
impossible at best. I've even had FreeBSD developers, sitting in the
developers IRC channel, say wifi is
On 3/2/12 10:21 AM, Doug Barton wrote:
On 03/02/2012 03:44, K. Macy wrote:
not sure who wrote:
Correct. However, I'm not sure the analogy is flawed. I am, to some
degree, guilty of the same sin. I now run Ubuntu and have never had a
single problem keeping my package system up date, in stark
On 2/29/2012 6:01 PM, Steve Wills wrote:
On 02/29/12 13:17, K. Macy wrote:
.
I tried it, on both FreeBSD routers, web systems, and database
servers; all on 8.2+. It still causes massive instability.
Disabling the sysctl, and/or removing it from the kernel solved
the problems.
Routing I
Yes, that was part of it. On the web and db systems we had what I can
only describe as general wackiness with systems suddenly becoming
unreachable, etc. This was with a moderately complex network setup with
a combination of different VLANs, multiple interfaces, etc. The FreeBSD
routers would
.
I tried it, on both FreeBSD routers, web systems, and database
servers; all on 8.2+. It still causes massive instability. Disabling
the sysctl, and/or removing it from the kernel solved the problems.
Routing I can believe, but I'm wondering how close attention you paid
to the workload.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/29/12 13:17, K. Macy wrote:
.
I tried it, on both FreeBSD routers, web systems, and database
servers; all on 8.2+. It still causes massive instability.
Disabling the sysctl, and/or removing it from the kernel solved
the problems.
Inviato da iPad
Il giorno 01/mar/2012, alle ore 03:01, Steve Wills swi...@freebsd.org ha
scritto:
The failure I experienced was with web servers running 8.0 behind a F5
load balancer in an HA setup. Whenever the failover happened, the web
servers would continue sending to the wrong MAC
On 28.02.12 23:14, Doug Barton wrote:
On 2/28/2012 10:48 AM, Arnaud Lacombe wrote:
You will sure go really far with this kind of It is broken ? Let's
not fix it and disable it instead mentality, even more when coming
from a committer.
As long as there will be these kind of comments around
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/28/2012 15:08, Florian Smeets wrote:
I talked to Kip Macy, who implemented flowtable, about this. He
thinks that the problem was caused by inappropriate default setting
of net.inet.ip.output_flowtable_size. This should have been fixed
by
33 matches
Mail list logo
