Date: Mon, 1 Nov 1999 21:19:23 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dhw@whistle.com (David Wolfskill) Cc: bright@wintelcom.net, don@calis.blacksun.org, freebsd-fs@FreeBSD.ORG Subject: Re: Journaling Message-ID: <199911012119.OAA03623@usr02.primenet.com> In-Reply-To: <199910271440.HAA31103@pau-amma.whistle.com> from "David Wolfskill" at Oct 27, 99 07:40:16 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >> Kirk McKusick has been working for the last year or so on > >> a combination of "soft-updates" (complete) and "snapshots" > >> (not released yet), once complete FFS will have the equivelant > >> of logging AND snapshots like the netapp appliance. > > > >I am familiar with softupdates but not with snapshots. > > Take a look at Network Appliance's "WAFL". (They have some white > papers up on their Web site, http://www.netapp.com/. In particular, the > one at http://www.netapp.com/tech_library/3002.html descibes WAFL and > snapshots.) Note that the internal implementation of the Network Appliance embedded OS is a non-preemptive cooperative multitasking model, similar to the internal implementation of NetWare, where threads either run to completion or until an explicit yield (this is also why NetWare never did the SMP thing correctly for Native NetWare, and why NetWare for UNIX is able to beat its performance numbers on identical single processor hardware, but really kicks its butt when it comes to SMP hardware). The upshot of this is that the WAFL implementation make some seriously invalid-for-FreeBSD assumptions about not having to have explicit synchronization primitives anywhere. Short of going to a similar kernel model (kernel threads handling device drivers are a generally bad idea for a lot of reasons, including the one where NT was able to kick Linux's ass with the Microsoft specified four ethernet cards on a 4 processor SMP box in the Netcraft and Ziff Davis labs tests), you would have to add significant overhead to the WAFL design discussed in those documents. It would perform very poorly in a standard UNIX kernel, without some significant organizational changes to eliminate the large number of threads model implied synchronization points from having to be changed to explicit locks. 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-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911012119.OAA03623>