Date: Wed, 27 Oct 1999 07:40:16 -0700 (PDT) From: David Wolfskill <dhw@whistle.com> To: bright@wintelcom.net, don@calis.blacksun.org Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Journaling Message-ID: <199910271440.HAA31103@pau-amma.whistle.com> In-Reply-To: <Pine.BSF.4.05.9910270728390.34993-100000@calis.blacksun.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>Date: Wed, 27 Oct 1999 07:36:38 -0400 (EDT) >From: Don <don@calis.blacksun.org> >> 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.) >The reason for >starting a new project was basically to once and for all get rid of UFS. ? >While there is nothing wrong with UFS it does have some limitations which >I would like to eliminate such as a limit of 7 slices. 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. Indeed, it is quite possible for different slices to be used in different ways -- some as UFS file systems, some as swap spaces (which are not file systems at all), some as some other form of file system. And none of that addresses any "limit of 7 slices." >I would also like to add functionality such as the ability to grow and >shrink partitions etc. 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. >Softupdates is also not recommended for use on the root partition and >it still seems to be just a little flaky. Every once in a while I wind up >with a problem which I have traced to softupdates but which I could >not recreate. (To be fair I have not had a problem in a month or two now) I will grant that I've been able to create certain kinds of problems in a soft updates environment -- for example, getting a bit too aggressive about trying to reclaim recently freed blocks when the file system is nearly full can cause some writes to fail, and applications that don't deal with that very gracefully can easily engender cascade failures. It is, however, still somewhat of a work in progress (from what I understand). 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. Cheers, david -- David Wolfskill dhw@whistle.com UNIX System Administrator voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915 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?199910271440.HAA31103>