[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

umce linux meeting minutes 2/23 3p b3 2501

Tony Winkler typed these up and deserves all thanks.
I proof-read this, randomly reformatted & editted this for content
and completeness; you can blame me for any mistakes that remain.

present: wes, ainman, marcus, drh, amw
	(a number of folks were ill or had other meetings)

 hardware update: Andrew
	white sands is the 1u evaluation hardware
	there are kernel issues with sata drives requireing
	some kernel changes
	(this is for low end di infrostructure)

	[ mdw: I think that Andrew said that white sands seemed to
	have hardware problems and got sent back and is due to be returned? ]

	[ mdw: area51 is the high end 1u machine.  It's not ready
	for disk testing because the SATA controller does DMA
	and the "standard" umce linux kernel has incomplete
	IDE support which doesn't include the necessary DMA bits. ]

	large raid purchase is out for RFP; quotes expected next week

	3u machine with sata drives is on the way, similar to imap
	backends, might be a lot cheaper than current stuff (also
	available as a 1u that might be a nice small DB server - 4 sata

	SATA raid bottleneck is likely the controller.  Card in new
	machine is supposed to be 320 sustained, 64 bit channel pci

discussion of the new base:

Envoy to meeting at Gavin's request:
	discussion of the needs for an envoy to the
	spam/spyware/badness group no one volunteers to be an envoy to
	this and we may already have folks there for other purposes.
	Marcus will find out how much of a committment is involved here

Rieser FS:
	there is a rieserfs3  machine that Wes's group has run fail tests
	on (frankenstien) and are finding it to be very robust.
	Performance based on filesize, estimate of 2 hours to do reiser
	fsck for current data load.  [ mdw: I believe normally one only has
	to play back the log - the check utility is probably only something
	you'd run by hand if there are suspected hardware or software problems. ]

	[ mdw: reiserfs4 is still "unstable" but has interesting new
	transaction semantics not brought out to the application
	layer. ]
	AFS could use a transaction log [ mdw because many AFS operations
	are not atomic at the kernel filesystem layer and hence
	there are times between syscalls where the afs file structure
	is not in fact consistent ]
	[ mdw: there's been some discussion in the openafs community
	about a transaction based filesystem something like dfs,
	but nothing formal. ]

	New ACNC raids do not appear to lose firmware during power
	interrupts even when Allen and Martin try really hard to make
	it so.  Replaceing the firmware losing units is on
	Kitty/Gavin's list of service hardening bulletpoints.  Also
	possibly funding an AFS developer for a year to improve
	backup/snapshots and other.

tracking user exploits:
	who is tracking these and how?  Albert and Allen are doing this
	but not in a systematic way.  Wes is looking at a gentoo
	cyrus/imap exploit that does not seem to be discussed on the
	imap lists themselves for example

	should each group be tracking exploits for its own services?
	(pretty much yes)

sharing command files:

Next meeting (march 23):  Katarina to facilitate