Date: Sun, 14 Feb 1999 00:35:50 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jal@stage1.thirdage.com (Jamie Lawrence) Cc: mjacob@feral.com, freebsd-hackers@FreeBSD.ORG Subject: Re: softupdates Message-ID: <199902140035.RAA29410@usr06.primenet.com> In-Reply-To: <4.1.19990213000333.0765d230@204.74.82.151> from "Jamie Lawrence" at Feb 13, 99 00:41:01 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Sure. That's why we spent a (frankly) ridiculous amount of money on > a Netapp. Support would have saved us a bundle, maybe. Real world, > right-here-right-now-we're-doing-it-today applications tend to have > nontechnical restraints imposed on them, which hurt; having technical > (non)-assurances layered on top create a barrier that no zealot can > honestly penetrate, FreeBSD or no. The current implementation of soft updates is incapable of having a transactioning stacking layer stacked on top of it, since it's a UFS/FFS specific soloution instead of a general soloution. This is a big issue for competing with NetApp's implementation. > I hate (will become hated) to say this, but if taking on Netapp is > a goal, there's a huge hardware requirement for the port, and then > there's probably a steep performance curve. > > They do support "common" protocols, which work most anywhere. At a price. I spent last night hacking code with Jeremy Allison (SAMBA/SGI); we had a nice discussion about some of the benchmarks posted on the samba.org site. In general, the NetApp stuff is hindered by its architecture. On a single processor box, they beat SAMBA with their SMB implementation. This is primarily due to their NetWare-like use of non-preemptive multitasking and threading: they don't have the normal context switch thrash, and tasks run to completion. [Note: this is why kernel threads or threaded implementations other than an async call gate will always fall behind NetApp and NetWare, in a uniprocessor benchmark]. At the same time, this means that the NetApp nad NetWare server implementations can not take advantage of symmetric multiprocessing. Given the assumption that threads will run to completion (or to an explicit yield), they do not implement much resource locking, at all, only that needed for interrupt and fault processing. As a result, they are low overhead on UP, but impossible to implement in an SMP CPU architecture due to lacking the necessary locking. They can not even take "the cowards way out" of a Big Giant Lock(tm), like Linux and FreeBSD have done, since they don't have a concurrency barrier for tasks which may be competing for system resources. On a four processor Xeon box, SAMBA seriously outperforms anything that NetApp can field. Finally, it's true that NetApp has a number of pieces of low hanging fruit that they can acquire at some small cost: o They could use character-count prefixes on strings internally (SAMBA can do tis as well; apparently the current profiling bottleneck is strlen calls). o They could avoid the Unicode/non-Unicode codepage based conversions. This would require FS changes to support [NB: SAMBA doesn't currently do Unicode in their release branch]. o They could go to pure Unicode in the FS, instead of doing multibyte encoding and decoding. o etc. These are, in of themselves, insufficient (IMO) for what appears to be the coming widespread use of 4 processor Xeon boxes. This concludes our mini technical analysis; we now return you to your regularly scheduled cat herding. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902140035.RAA29410>