2.4.7-ac4 disk thrashing

2.4.7-ac4 disk thrashing

[Tom Vier]

switching from 2.4.7-ac3 to -ac4, disk access seems to be much more
synchronis. running a ./configure script causes all kinds of trashing, as
does installing .debs. i'm using reiserfs on top of software raid 0 on an
alpha.

-- 
Tom Vier <tmv5@home.com>
DSA Key id 0x27371A2C

Re: 2.4.7-ac4 disk thrashing

[Matthew Gardiner]

Tom Vier wrote:

>switching from 2.4.7-ac3 to -ac4, disk access seems to be much more
>synchronis. running a ./configure script causes all kinds of trashing, as
>does installing .debs. i'm using reiserfs on top of software raid 0 on an
>alpha.
>
Apparently, in ac5 (which I am running), there was a bug on non-x86 
cpu's using reiserfs. Download and install the new patch and try.

Matthew Gardiner



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: 2.4.7-ac4 disk thrashing

[Tom Vier]

On Sun, Aug 05, 2001 at 11:04:59AM +1200, Matthew Gardiner wrote:
> Tom Vier wrote:
> >switching from 2.4.7-ac3 to -ac4, disk access seems to be much more
> >synchronis. running a ./configure script causes all kinds of trashing, as
> >does installing .debs. i'm using reiserfs on top of software raid 0 on an
> >alpha.

> Apparently, in ac5 (which I am running), there was a bug on non-x86 
> cpu's using reiserfs. Download and install the new patch and try.

that's just a signedness fix. i've tried ac5 and it has the same problem as
ac4.

-- 
Tom Vier <tmv5@home.com>
DSA Key id 0x27371A2C

ip_conntrack bigger, better and yellow ;) !!!

[Mircea Ciocan]

	Ok, the pressure for a netflow like stuff in kernel is big, examining
the the netflow structure at:

 http://sgi.rdscv.ro/~ionuts/netflowv5.h

it seem that ip_conntrak has allmost everything that is needed to
emulate Cisco netflow EXCEPT ( a big except :) the information about
data bytes/packets that flow via that connexion and the question is how
could be added with minimum damages, for example at the end of the
existing ip_conntrack structure, so a nice little userspace daemon could
parse the /proc/net/ip_conntrack and generate the damned netflow packets
that everybody seem to want now :( !!!
	Me and a couple of friends are ready to cut our teeth in kernel
programing and have available some machines to crash test and debug the
damned thing and while not aiming for inclusion in stable series maybe
it will mature enough for inclusion in 2.6 series or it will remain a
forever unofficial pach :).
	While we think that we know enough C and we can dig throu kernel
sources we need some mentoring, kickstart and stuff from you network
gurus to tell us where is the best this code to be inserted ( is your
stack after all ;) and some best design ideeas.
	We promise to do the grunt work and keep the "bothering level" at a
minimum :).
	So Alexey, DaveM, Alan and the other network gurus, please help us to
put our name somewhere in the CREDITS file ;).

		Thank you,

		Mircea C.

Re: ip_conntrack bigger, better and yellow ;) !!!

[Sven Koch]

On Sun, 5 Aug 2001, Mircea Ciocan wrote:

> 	Ok, the pressure for a netflow like stuff in kernel is big, examining
> the the netflow structure at:
>
>  http://sgi.rdscv.ro/~ionuts/netflowv5.h
>
> it seem that ip_conntrak has allmost everything that is needed to
> emulate Cisco netflow EXCEPT ( a big except :) the information about
> data bytes/packets that flow via that connexion and the question is how
> could be added with minimum damages, for example at the end of the
> existing ip_conntrack structure, so a nice little userspace daemon could
> parse the /proc/net/ip_conntrack and generate the damned netflow packets
> that everybody seem to want now :( !!!

I think you should get in contact with the netfilter-coreteam about this
and subscribe to the netfilter-devel-mailinglist - see
http://netfilter.samba.org/ for subscribe-information.

c'ya
sven

-- 

The Internet treats censorship as a routing problem, and routes around it.
(John Gilmore on http://www.cygnus.com/~gnu/)