From owner-freebsd-fs Wed Oct 27 9:59: 5 1999 Delivered-To: freebsd-fs@freebsd.org Received: from calis.blacksun.org (Calis.blacksun.org [168.100.186.40]) by hub.freebsd.org (Postfix) with ESMTP id 082F514A24 for ; Wed, 27 Oct 1999 09:59:01 -0700 (PDT) (envelope-from don@calis.blacksun.org) Received: from localhost (don@localhost) by calis.blacksun.org (8.9.3/8.9.2) with ESMTP id NAA35386; Wed, 27 Oct 1999 13:00:21 -0400 (EDT) (envelope-from don@calis.blacksun.org) Date: Wed, 27 Oct 1999 13:00:21 -0400 (EDT) From: Don To: David Wolfskill Cc: bright@wintelcom.net, freebsd-fs@FreeBSD.ORG Subject: Re: Journaling In-Reply-To: <199910271440.HAA31103@pau-amma.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > 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.) Excellent. Thank you. > >starting a new project was basically to once and for all get rid of UFS. > ? UFS is not flexible enough and I would prefer not to start adding a million features to UFS if I am still stuck without a journaled core. > With all due respect, that assertion mkes about as much sense as saying > that its bits are the wrong color. How a device is carved into separate > areas, any one of which may hold some kind of file system, has little (if > anything) to do with how one of those file systems happens to be designed. UFS on top of FFS has a limit of 7 slices per partition. This is an issue with FFS rather than UFS however it is still a problem. I would like to see all of these limitations removed. > That would be something that I would welcome. I expect that many others > would, as well. There has been a fair amount already written on the > topic, both in FreeBSD lists and at USENIX-sponsored conferences. Absolutely. The purpose of this thread is really to gather ideas from people so that I know what everyone is looking for from a file system. This way the proper features can be designed in right from the start. > It is, however, still somewhat of a work in progress (from what I > understand). I agree that it is a work in progress although others have stated that it is completed. > As such, its current limitations are unlikely to match > either the design point or the limitations that will be in effect (say) > several months from now. If soft updates is used within its current > limitations (ref. the earlier comment about write failures), it seems to > work well enough that I've been enabling it on the Engineers' desktops > here. And except for deliberate attempts to stress things to the > breaking point (some of which I have perpetrated), I've not been informed > of any breakage. I have no issues with soft-updates. I think it performs admirably. I think however that it could be faster and unless the license has changed I dont agree with it. I would like to have a file system that could actually be delivered with the OS instead of having to be enabled as an add-on. (I am going to check the license now as I could be completely off and the license could have been changed) -don To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message