From owner-freebsd-fs Wed Oct 27 9:52: 1 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 5C71A14C9E for ; Wed, 27 Oct 1999 09:51:57 -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 MAA35362; Wed, 27 Oct 1999 12:53:22 -0400 (EDT) (envelope-from don@calis.blacksun.org) Date: Wed, 27 Oct 1999 12:53:22 -0400 (EDT) From: Don To: Robert Watson Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Journaling In-Reply-To: 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 > I would love to see full journaling/logging for meta-data -- softupdates > is cool, but seems to be a hard-coding of the rules as opposed to a > general journaling fs. Specifically, I'd love to see a journaling fs with > extensible meta-data attributes, such as supported by XFS. This would put > us in a situation where adding new structures to the fs didn't require > understanding the internals of the journalling--this way someone (say me) > could add new meta-data (say ACLs) and not have to deal with the realities > of softupdates, or even fsck. IRIX XFS adds two new vops, a getexattr and > setexattr for named extensions that are also logged. Exactly! I would like to create a more flexible file system. > The Linux people, to add ACL support, are using extra blocks on the file > system. The problem with this is that if the user can coerce a kernel > failure (i.e., crash the system, cut the power, whatever), they can induce > inconsistencies in the ACL and inode versions, meaning that if they time > it right, they can influence the content of the ACLs, or other security > data (MAC tags, etc). With a logged extensible meta-data system, this > could not happen. Agreed. There is actually a thread on freebsd-hackers about this same topic which I would like to bring to this list. > Someone mentioned at one point that they were looking at porting XFS to > FreeBSD. I assume XFS is under some sort of community license and not a > BSD license, but it might be a good place to start. I would prefer not to even bother with XFS other than as a feature reference. There license is not going to be a BSD license and as such I dont want to bother porting it. -Don To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message