Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Oct 1999 13:00:21 -0400 (EDT)
From:      Don <don@calis.blacksun.org>
To:        David Wolfskill <dhw@whistle.com>
Cc:        bright@wintelcom.net, freebsd-fs@FreeBSD.ORG
Subject:   Re: Journaling
Message-ID:  <Pine.BSF.4.05.9910271253330.35360-100000@calis.blacksun.org>
In-Reply-To: <199910271440.HAA31103@pau-amma.whistle.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9910271253330.35360-100000>