2.4.7-ac4 disk thrashing
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.
Signature · 2 lines
Tom Vier <[email protected]> DSA Key id 0x27371A2C
Quoted 5 lines · 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.
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
Quoted 8 lines · Matthew Gardiner
Quoted 4 lines · 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.
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.
Signature · 2 lines
Tom Vier <[email protected]> DSA Key id 0x27371A2C
ip_conntrack bigger, better and yellow ;) !!!
In reply to Tom Vier 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 ;) !!!
Quoted 5 lines · Mircea Ciocan
Ok, the pressure for a netflow like stuff in kernel is big, examining
the the netflow structure at:
Quoted 7 lines
it seem that
ip_conntrakhas 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 existingip_conntrackstructure, so a nice little userspace daemon could parse the/proc/net/ip_conntrackand 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
Signature · 2 lines
The Internet treats censorship as a routing problem, and routes around it. (John Gilmore on http://www.cygnus.com/~gnu/)