From owner-freebsd-fs Sun Sep 24 1:37:45 2000 Delivered-To: freebsd-fs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id E988937B422; Sun, 24 Sep 2000 01:37:41 -0700 (PDT) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id BAA95427; Sun, 24 Sep 2000 01:37:41 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Sun, 24 Sep 2000 01:37:41 -0700 (PDT) From: Kris Kennaway To: Adrian Chadd Cc: Boris Popov , freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Fsck wrappers, revisited In-Reply-To: <20001223114150.A38052@roaming.cacheboy.net> 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 On Sat, 23 Dec 2000, Adrian Chadd wrote: > On Fri, Sep 22, 2000, Boris Popov wrote: > > On Sat, 23 Dec 2000, Adrian Chadd wrote: > > > > > So now is a problem which I'm sure the NetBSD people came up against. > > > The fstypenames are names like 4.2BSD, vinum, ISO9660, etc. NetBSD fixed > > > this by creating a new list 'mountnames[]', which maps the fs type to > > > a string. > > > > Probably a hard link to fsck_ffs will do the job fine and makes it > > clear to see which fs'es are supported: > > > > # ls -ail fsck* > > 6338 -r-xr-xr-x 1 root wheel 66032 22 sen 16:24 fsck > > 6334 -r-xr-xr-x 3 root wheel 290896 22 sen 15:41 fsck_4.2BSD > > 6334 -r-xr-xr-x 3 root wheel 290896 22 sen 15:41 fsck_ffs > > 6334 -r-xr-xr-x 3 root wheel 290896 22 sen 15:41 fsck_ufs > > The trouble is that some of the FS strings have spaces in their filenames. > This might confuse a few people. How about mapping spaces to '_' characters - I doubt it would cause any namespace collisions. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Sep 24 2: 8:43 2000 Delivered-To: freebsd-fs@freebsd.org Received: from roaming.cacheboy.net (roaming.cacheboy.net [203.56.168.69]) by hub.freebsd.org (Postfix) with ESMTP id 7228137B424; Sun, 24 Sep 2000 02:08:38 -0700 (PDT) Received: (from adrian@localhost) by roaming.cacheboy.net (8.11.0/8.11.0) id e8O8ukS07598; Sun, 24 Sep 2000 10:56:46 +0200 (CEST) (envelope-from adrian) Date: Sun, 24 Sep 2000 10:56:45 +0200 From: Adrian Chadd To: Kris Kennaway Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: Fsck wrappers, revisited Message-ID: <20000924105645.A7573@roaming.cacheboy.net> References: <20001223114150.A38052@roaming.cacheboy.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from kris@FreeBSD.org on Sun, Sep 24, 2000 at 01:37:41AM -0700 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Sep 24, 2000, Kris Kennaway wrote: > > The trouble is that some of the FS strings have spaces in their filenames. > > This might confuse a few people. > > How about mapping spaces to '_' characters - I doubt it would cause any > namespace collisions. Yes, as bp mentioned to me before, so I'm thinking about passing the fsname through a tolower() and a s/ /_/g before using it as a filename. Any problems with this? Adrian -- Adrian Chadd "The main reason Santa is so jolly is because he knows where all the bad girls live." -- Random IRC quote To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Sep 25 1:25:56 2000 Delivered-To: freebsd-fs@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 5434837B424 for ; Mon, 25 Sep 2000 01:25:50 -0700 (PDT) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id KAA51986; Mon, 25 Sep 2000 10:25:49 +0200 (CEST) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Michael Aronsen Cc: "'fs@freebsd.org'" Subject: Re: Journaling Filesystems in bsd? References: <9164771DDCABD3118333005004E9446E204774@mother.netcentralen.dk> From: Dag-Erling Smorgrav Date: 25 Sep 2000 10:25:48 +0200 In-Reply-To: Michael Aronsen's message of "Thu, 21 Sep 2000 10:30:19 +0200" Message-ID: Lines: 11 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Michael Aronsen writes: > Just wanted to know if there are any projects to get something like reiserfs > to FreeBSD? I doubt it. Given the current state of reiserfs, the attitude of Reiser himself, and the general tone of conversation on the reiserfs lists, I doubt that even Linux will ever ship with reiserfs. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Sep 25 1:29:33 2000 Delivered-To: freebsd-fs@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 4F1BF37B422 for ; Mon, 25 Sep 2000 01:29:31 -0700 (PDT) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id KAA51993; Mon, 25 Sep 2000 10:28:14 +0200 (CEST) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Dwight Tuinstra Cc: freebsd-fs Subject: Re: Journaling Filesystems in bsd? (LFS, anyone?) References: <9164771DDCABD3118333005004E9446E204774@mother.netcentralen.dk> <20001222152532.B97883@roaming.cacheboy.net> <39CA26D7.51D314BF@clarkson.edu> From: Dag-Erling Smorgrav Date: 25 Sep 2000 10:28:14 +0200 In-Reply-To: Dwight Tuinstra's message of "Thu, 21 Sep 2000 11:18:47 -0400" Message-ID: Lines: 13 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dwight Tuinstra writes: > At present, the only working, available LFS system (that I'm aware > of) for a freeNIX is the one in NetBSD, though there are at least two > efforts underway for Linux. > [...] > Is there any interest in porting/redesigning LFS for FreeBSD? If NetBSD has an LFS, I think it would be best to port that and strive to remain compatible with NetBSD rather than invent our own stuff. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Sep 25 3:17:12 2000 Delivered-To: freebsd-fs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 21FEC37B42C; Mon, 25 Sep 2000 03:17:10 -0700 (PDT) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id DAA36059; Mon, 25 Sep 2000 03:17:10 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Mon, 25 Sep 2000 03:17:09 -0700 (PDT) From: Kris Kennaway To: Dag-Erling Smorgrav Cc: Dwight Tuinstra , freebsd-fs Subject: Re: Journaling Filesystems in bsd? (LFS, anyone?) 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 On 25 Sep 2000, Dag-Erling Smorgrav wrote: > Dwight Tuinstra writes: > > At present, the only working, available LFS system (that I'm aware > > of) for a freeNIX is the one in NetBSD, though there are at least two > > efforts underway for Linux. > > [...] > > Is there any interest in porting/redesigning LFS for FreeBSD? > > If NetBSD has an LFS, I think it would be best to port that and strive > to remain compatible with NetBSD rather than invent our own stuff. NetBSD have an LFS which is at least actively developed, whether or not it's production-grade. However they also don't have a unified buffer cache; lack of developer attention to adapt the code to this being what killed our LFS, as I understand it. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Sep 25 5:41:59 2000 Delivered-To: freebsd-fs@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id B30DB37B42C for ; Mon, 25 Sep 2000 05:40:27 -0700 (PDT) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id OAA44078; Mon, 25 Sep 2000 14:40:21 +0200 (CEST) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id OAA79016; Mon, 25 Sep 2000 14:40:21 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Mon, 25 Sep 2000 14:40:21 +0200 (CEST) From: Marius Bendiksen To: Dag-Erling Smorgrav Cc: Dwight Tuinstra , freebsd-fs Subject: Re: Journaling Filesystems in bsd? (LFS, anyone?) 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 > If NetBSD has an LFS, I think it would be best to port that and strive > to remain compatible with NetBSD rather than invent our own stuff. Actually, the LFS that has been ressurected in NetBSD is also available in FreeBSD on old systems. It got yanked at LFS_RETIRE. Anyway, the implementation is apparently rather proof-of-concept stage, as I've heard, so you might actually do well to join up with the NetBSD people to make a more proper such filesystem. Or, get someone to port WAFL, and get NVRAM. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Sep 25 9:52:15 2000 Delivered-To: freebsd-fs@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 27E4537B42C; Mon, 25 Sep 2000 09:52:01 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id DAA02156; Tue, 26 Sep 2000 03:51:56 +1100 Date: Tue, 26 Sep 2000 03:51:51 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Adrian Chadd Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Fsck wrappers, revisited In-Reply-To: <20000923114434.A4419@roaming.cacheboy.net> 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 On Sat, 23 Sep 2000, Adrian Chadd wrote: > On Sat, Sep 23, 2000, Bruce Evans wrote: > > On Sat, 23 Dec 2000, Adrian Chadd wrote: > > > > > Here's the patch: > > > > > > --- fsck.c.orig Sat Dec 23 11:13:30 2000 > > > +++ fsck.c Sat Dec 23 11:13:34 2000 > > > @@ -501,7 +501,7 @@ > > > errx(1, "partition `%s' is not of a legal vfstype", > > > str); > > > - if ((vfstype = dktypenames[t]) == NULL) > > > + if ((vfstype = fstypenames[t]) == NULL) > > > errx(1, "vfstype `%s' on partition `%s' is not supported", > > > fstypenames[t], str); > > > > > > > > > So now is a problem which I'm sure the NetBSD people came up against. > > > The fstypenames are names like 4.2BSD, vinum, ISO9660, etc. NetBSD fixed > > > this by creating a new list 'mountnames[]', which maps the fs type to > > > a string. > > > > fs typenames are already strings in FreeBSD (the kernel's vfc_index is an > > implementation detail which should not be visible in applications). > > Oh, wait. I understand what you're talking about now. There isn't any mapping > to partition type (p_fstype) to fs typename string. > > > > http://cvsweb.netbsd.org/bsdweb.cgi/syssrc/sys/sys/disklabel.h.diff?r1=1.60&r2=1.61 > > > > > > What do people think about doing this as well? It would certainly make things > > > a little tidier, but every time a new fs comes in the magic autodetection code > > > will need to be updated (if appropriate, of course.) > > > > This would be a bug. > > Well, if you have any suggestions, I'm all for it. :-) I don't understand the problem. You get the filesystem type name (fstypename) from fs_vfstype in struct fstab or from f_fstypename in struct statfs. You attempt to execute strcat("/sbin/fsck_", fstypename) to see if fsck is supported on filesystems of type fstypename. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Sep 25 10: 8:16 2000 Delivered-To: freebsd-fs@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 1628B37B42C; Mon, 25 Sep 2000 10:08:10 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id EAA02688; Tue, 26 Sep 2000 04:08:06 +1100 Date: Tue, 26 Sep 2000 04:08:01 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Adrian Chadd Cc: Kris Kennaway , freebsd-fs@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Fsck wrappers, revisited In-Reply-To: <20000924105645.A7573@roaming.cacheboy.net> 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 On Sun, 24 Sep 2000, Adrian Chadd wrote: > On Sun, Sep 24, 2000, Kris Kennaway wrote: > > > > The trouble is that some of the FS strings have spaces in their filenames. > > > This might confuse a few people. > > > > How about mapping spaces to '_' characters - I doubt it would cause any > > namespace collisions. > > Yes, as bp mentioned to me before, so I'm thinking about passing the fsname > through a tolower() and a s/ /_/g before using it as a filename. > > Any problems with this? This shouldn't be necessary. All fstypenames for currently supported filesystems are in lower case with no underscores, and new ones should follow this convention. Spaces in the names would probably break /etc/fstab. Fstypenames for currently supported filesystems as found by grepping for VFS_SET in /sys: cd9660 coda devfs ext2fs fdesc hpfs kernfs linprocfs mfs msdos nfs ntfs ntfs nullfs nwfs portal procfs ufs umap union Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Sep 26 18:10:15 2000 Delivered-To: freebsd-fs@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id EDC6537B43C; Tue, 26 Sep 2000 18:10:04 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id VAA81368; Tue, 26 Sep 2000 21:09:58 -0400 (EDT) (envelope-from rwatson@FreeBSD.org) Date: Tue, 26 Sep 2000 21:09:58 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: freebsd-fs@FreeBSD.org Cc: freebsd-arch@FreeBSD.org, trustedbsd-discuss@TrustedBSD.org Subject: VOP_ACCESS() and new VADMIN/VATTRIB? 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 (sorry about flagrant cross-posting -- wanted to make sure that those with interest would have the opportunity to comment) In general, access control for operations within a file system is determined via a recursive VOP_ACCESS() call on the vnode, vis. VOP_OPEN(vp, ...) -> ufs_open(vp, ...) -> VOP_ACCESS(vp, ...) -> ufs_access(vp, ...) Flags are passed to VOP_ACCESS() indicating the specific requests being made on the object, allowing VOP_ACCESS() to implement a variety of discretionary and mandatory policies. VOP_ACCESS(9) documents these flags as VREAD, VWRITE, and VEXEC, reflecting respectively read, write, and execute rights. In recent changes to improve modularity and consistency, Poul-Henning moved most of the mode/ownership-related components of ufs_access() (and from other file systems) into vaccess(). File-system specific components, such as the readonly status of the file system, and UFS file flags, remain in ufs_access(). In the UFS code, VOP_ACCESS() is used fairly routinely to guard access to the data associated with a file or directory. However, there is an additional class of requests relating to file operations wherein checks of inode attributes and characteristics are performed directly, rather than falling back on the central VOP_ACCESS() implementation for the file system. In general these requests relate to administrative actions for the file: the ability to set protection rights for the file (ufs_chmod(), ufs_chown(), and in the ACL implementation, also ufs_setacl()). As a result, these access checks are scattered through the file system implementation, and do not lend themselves to further generalization. I ran into this problem while implementing mandatory access control for FreeBSD: mandatory policies override rights that may be granted by discretionary mechanisms (such as permissions and ACLs), allowing effective partitioning and segregation of the system based on other properties, such as sensitivity and integrity labels. One of example of this is a Biba integrity policy, in which the permissions of a file might allow write access to all users, but the MAC policy forbids this access as it might violate system integrity (for example, incorrectly set permissions on /kernel). Without generalized and centralized access control for all access decisions, it is difficult to cleanly inserts more flexible access control policies. I'd like to propose that an existing VADMIN flag be added determining whether or not the passed credentials are permitted to administer the file. Here is a brief itemization of locations in the code where i->uid checks would be replaced with VOP_ACCESS(vp, ... VADMIN ...) calls, with some possible omissions: File Use ufs_lookup.c Allow owner of a sticky directory to delete any file in it ufs_lookup.c Allow owner of a file to delete it from a sticky directory ufs_vnops.c Allow owner of a file to set non-system file flags ufs_vnops.c Allow owner to modify times on file ufs_vnops.c Allow owner to modify permissions on file ufs_vnops.c Allow owner to modify group of file ufs_vnops.c Allow owner of a file or its parent directory to overwrite that file if its parent directory is sticky There are some other references to i_uid in ufs_vnops.c relating to the QUOTA and SUIDDIR code. It is my belief, although I'd be glad to take comments, that the QUOTA code should remain as is, as it's not for access control but rather accounting. Similarly, the SUIDDIR code should remain as is, as it has to do with whether or not the ownership on a newly created file should be set to reflect the parent directory's ownership instead of the calling credential. The effect of this change would be to allow any rights granted via ownership of a file but not in the VREAD, VWRITE, and VEXEC catagories to the new VADMIN category. As a result, changes to the file system's VOP_ACCESS() code could then grant or deny these requests based on other factors in the credential, including mandatory policies. I selected the name VADMIN based on a similar right in the Andrew File System (AFS), "admin", which permits users or groups with admin rights for a directory to manipulate its access control list. You could imagine adding a new right such as this to the ACL implementation, although I have no plans to do so at this point. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Sep 26 23:13:14 2000 Delivered-To: freebsd-fs@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 703BF37B424; Tue, 26 Sep 2000 23:13:10 -0700 (PDT) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA13214; Tue, 26 Sep 2000 23:12:38 -0700 (PDT) Date: Tue, 26 Sep 2000 23:12:37 -0700 (PDT) From: Julian Elischer To: Robert Watson Cc: freebsd-fs@FreeBSD.org, freebsd-arch@FreeBSD.org, trustedbsd-discuss@TrustedBSD.org Subject: Re: VOP_ACCESS() and new VADMIN/VATTRIB? 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 agree with all you have said here. On Tue, 26 Sep 2000, Robert Watson wrote: > > > In general, access control for operations within a file system is > determined via a recursive VOP_ACCESS() call on the vnode, vis. > > VOP_OPEN(vp, ...) -> ufs_open(vp, ...) -> VOP_ACCESS(vp, ...) -> > ufs_access(vp, ...) [...] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Sep 27 0:23:56 2000 Delivered-To: freebsd-fs@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 6CE9F37B424; Wed, 27 Sep 2000 00:23:51 -0700 (PDT) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id AAA02627; Wed, 27 Sep 2000 00:21:16 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpdAAA2Xa4bf; Wed Sep 27 00:21:10 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id AAA20257; Wed, 27 Sep 2000 00:23:38 -0700 (MST) From: Terry Lambert Message-Id: <200009270723.AAA20257@usr05.primenet.com> Subject: Re: VOP_ACCESS() and new VADMIN/VATTRIB? To: julian@elischer.org (Julian Elischer) Date: Wed, 27 Sep 2000 07:23:38 +0000 (GMT) Cc: rwatson@FreeBSD.ORG (Robert Watson), freebsd-fs@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG, trustedbsd-discuss@TrustedBSD.org In-Reply-To: from "Julian Elischer" at Sep 26, 2000 11:12:37 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Julian Elisher wrote: > I agree with all you have said here. > > On Tue, 26 Sep 2000, Robert Watson wrote: > > In general, access control for operations within a file system is > > determined via a recursive VOP_ACCESS() call on the vnode, vis. > > > > VOP_OPEN(vp, ...) -> ufs_open(vp, ...) -> VOP_ACCESS(vp, ...) -> > > ufs_access(vp, ...) > [...] Perhaps a better question would be "assuming you generalize the references cited using the orioised VADMIN, how many references not using VOP_ACCES() will remain?". I think the generalization and centralization which took place are really bad things, since I think administrative policy is something that I may very well want to set on _both_ a system basis _and_ on a per-FS basis. I also think that read-only-ness of an FS is a mount option having nothing to do with the underlying FS itself. It seems to me that some of the centralization should, in fact, be backed out, since it seems that it would preclude layer recursion in some useful stacking arrangements, much in the same was a non-NULL VOP did when the "default" layer was introduced (with no mechanism to provide default semantics for nely defined VOPs, without a kernel recompile). 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 From owner-freebsd-fs Wed Sep 27 0:42:17 2000 Delivered-To: freebsd-fs@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id D167737B424; Wed, 27 Sep 2000 00:42:12 -0700 (PDT) Received: by relay.butya.kz (Postfix, from userid 1000) id 8EBB228770; Wed, 27 Sep 2000 14:42:03 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 77D9C285EE; Wed, 27 Sep 2000 14:42:03 +0700 (ALMST) Date: Wed, 27 Sep 2000 14:42:03 +0700 (ALMST) From: Boris Popov To: Robert Watson Cc: freebsd-fs@FreeBSD.org, trustedbsd-discuss@TrustedBSD.org Subject: Re: VOP_ACCESS() and new VADMIN/VATTRIB? 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 On Tue, 26 Sep 2000, Robert Watson wrote: > I'd like to propose that an existing VADMIN flag be added determining > whether or not the passed credentials are permitted to administer the > file. Here is a brief itemization of locations in the code where i->uid > checks would be replaced with VOP_ACCESS(vp, ... VADMIN ...) calls, with > some possible omissions: Interesting, but will there a strict policy which declares priority of this flag and its relation with suser() ? -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Sep 27 5:53:48 2000 Delivered-To: freebsd-fs@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 0A77437B42C; Wed, 27 Sep 2000 05:53:39 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id IAA88998; Wed, 27 Sep 2000 08:53:06 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 27 Sep 2000 08:53:06 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Terry Lambert Cc: Julian Elischer , freebsd-fs@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG, trustedbsd-discuss@TrustedBSD.org Subject: Re: VOP_ACCESS() and new VADMIN/VATTRIB? In-Reply-To: <200009270723.AAA20257@usr05.primenet.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 On Wed, 27 Sep 2000, Terry Lambert wrote: > Perhaps a better question would be "assuming you generalize > the references cited using the orioised VADMIN, how many > references not using VOP_ACCES() will remain?". My goal was to identify the application of ownership righs on files and directories (i.e., rights not granted by the discretionary permission maks of ACL). As it turns out, this class of checks maps extremely well into the current use of ip-i_uid in the src/sys/ufs/ufs tree, resulting in very few remaining references. As I refered to, the remaining references generally fall into two categories: first, the quota code which uses the file uid to determine how to account for use (index into dqget()), to determine when it should or should not report quota limit problems (uprintf() to warn of quota conditions), and to determine whether the current credential cr_uid matches the owner of the parent directory of a newly created file when SUIDDIR is enabled. In general, these are not access control decisions, rather strict use of the cr_uid as an identifier, meaning that abstraction of VADMIN as a category successfully removes all remaining uid-based authorization code in UFS. > I think the generalization and centralization which took > place are really bad things, since I think administrative > policy is something that I may very well want to set on > _both_ a system basis _and_ on a per-FS basis. I think there are both reasonable arguments for and against the generalization in vaccess(). One important advantage of the generalization is that it reduces the number of instances of permission-based authorization checks, allowing easier auditing and modification of the policy. For example, when I introduced support for POSIX.1e capabilities in my source tree, I needed only replace one instance of suser() rather than dozens scattered through the source tree. It also makes it easier to audit the use of privilege for correctness and logging purposes if it can be centrally identified. There is probably a decent argument that vaccess(), while a good idea, does not have an API lending itself to future expansion and flexibility: it directly accepts file uid, gid, and mode fields, and does not have a policy-related argument that could be used by the caller to specify how centralized checking should apply in the context of the current file system. > I also think that read-only-ness of an FS is a mount > option having nothing to do with the underlying FS itself. However, I think it is also arguable that the read-only-ness of a file system is not a security property, but in some cases a media property. That is to say, some file systems should be read-only by virtue of the underlying storage medium or file system type. Often, file systems are mounted read-only for security reasons, which is "different". vaccess() abstracts only the generalized security decision, not determination of per-file system or per-mount options. I think it would be reasonable to argue that we should attempt to distinguish security and non-security mount options, and provide the file system an opportunity to pass the security mount options to generalized security checking code, and that the current single read-only flag does not distinguish the security and file system properties that might be desirable. That said, I think there's also an argument that you would only process the read-only property centrally if you were willing to allow super-user privilege to override that protection. I.e., vaccess() performs discretionary and mandatory access checks, with privilege allowing the overriding of those protections. If the protections should not be overriden by appropriate privilege, they should not be processed as security protections in vacess(), which would further distinguish read-only mounting and a read-only security status. > It seems to me that some of the centralization should, in > fact, be backed out, since it seems that it would preclude > layer recursion in some useful stacking arrangements, much > in the same was a non-NULL VOP did when the "default" layer > was introduced (with no mechanism to provide default > semantics for nely defined VOPs, without a kernel recompile). I'm not sure I follow this argument. Each file system's VOP_ACCESS() implementation invokes vaccess() based on arguments it provides, and only if it chooses. For example, only file systems making use of a per-file uid/gid/mode currently invoke vaccess(). Coda does not invoke it, and in my ACLs tree, UFS doesn't invoke it, instead, vaccess_acl() in kern_acl.c. vaccess() is not a default VOP, rather, a helper function for VOP_ACCESS() implementations with common security properties. VOP_ACCESS() -> ufs_access() -> vaccess() Given this description, do you believe there would be limits imposed on stacked file system support? Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Sep 27 5:58:57 2000 Delivered-To: freebsd-fs@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 0DAAF37B423 for ; Wed, 27 Sep 2000 05:58:54 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id IAA89056; Wed, 27 Sep 2000 08:58:37 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 27 Sep 2000 08:58:37 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Boris Popov Cc: freebsd-fs@FreeBSD.org, trustedbsd-discuss@TrustedBSD.org Subject: Re: VOP_ACCESS() and new VADMIN/VATTRIB? 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 On Wed, 27 Sep 2000, Boris Popov wrote: > On Tue, 26 Sep 2000, Robert Watson wrote: > > > I'd like to propose that an existing VADMIN flag be added determining > > whether or not the passed credentials are permitted to administer the > > file. Here is a brief itemization of locations in the code where i->uid > > checks would be replaced with VOP_ACCESS(vp, ... VADMIN ...) calls, with > > some possible omissions: > > Interesting, but will there a strict policy which declares > priority of this flag and its relation with suser() ? The semantics will not change: VADMIN may be exercised on a file either by virtue of being the owner of the file (in the case of UFS-like file systems invoking vaccess()), or by virtue of possessing appropriate privilege. In the base FreeBSD tree, appropriate privilege will be a successful invocation of the suser() call. In my capabilities tree, it will generally correspond to CAP_FOWNER, or the capability to override access control failure based on not owning the file system object. Although I haven't finished the integration of the changes yet, I believe the patch for kern/vfs_subr.c would look something like the following: --- vfs_subr.c 2000/09/21 15:55:55 1.277 +++ vfs_subr.c 2000/09/27 12:55:36 @@ -2976,6 +2976,7 @@ /* Check the owner. */ if (cred->cr_uid == file_uid) { + dac_granted |= VADMIN; if (file_mode & S_IXUSR) dac_granted |= VEXEC; if (file_mode & S_IRUSR) That is, if you are the owner of the file by the traditional owner definition, then the VADMIN right is added to the mask of rights granted via the discretionary access control mechanism. When the check occurs and fails, it is followed by a check for appropriate privilege. You could think of this as the "loose end" category for access control checks, but actually all of the rights associated with VADMIN fit quite nicely into the category "access granted based on owning the file", or the shorter "administrative rights for the file" (VADMIN). I would be willing to consider arguments for giving VADMIN a different name, possibly VOWNER, VSETATTR, etc. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Sep 27 12:10: 7 2000 Delivered-To: freebsd-fs@freebsd.org Received: from pedigree.cs.ubc.ca (pedigree.cs.ubc.ca [142.103.6.50]) by hub.freebsd.org (Postfix) with ESMTP id 81F6237B422 for ; Wed, 27 Sep 2000 12:09:59 -0700 (PDT) Received: from cascade.cs.ubc.ca (dima@cascade.cs.ubc.ca [142.103.7.7]) by pedigree.cs.ubc.ca (8.8.8/8.6.9) with ESMTP id MAA23112 for ; Wed, 27 Sep 2000 12:09:54 -0700 (PDT) From: Dmitry Brodsky Received: (dima@localhost) by cascade.cs.ubc.ca (8.9.3/8.6.12) id MAA13804 for freebsd-fs@freebsd.org; Wed, 27 Sep 2000 12:09:54 -0700 (PDT) Message-Id: <200009271909.MAA13804@cascade.cs.ubc.ca> Subject: stackable fs & rename problem To: freebsd-fs@freebsd.org Date: Wed, 27 Sep 2000 12:09:54 -0700 (PDT) X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I am building a stackable FS using nullfs as a template; this is under FreeBSD 4.0-RELEASE. When rename is called the files being renamed are backed up. So if in a directory you have a files A and B and you do rename( A, B ), the files will first be backed up and copies will be made of A and B. The problem I am having is the following: If we have just one file A and we do rename( A, B ) then everything works as it should. If we also have B and we do rename( A, B ) then after the call completes and I do an ls on the fs I get: ls: B: Bad file descriptor This only occurrs if B exists. Now if I do rename( B, C ), the command completes without any complaints and C exists and contains the contents of A as it should. Does anybody have any idea what might be going on. It seems that if A and B exists and I do an vn_open on A or B then things will get messed up. I looked in the code for rename in kern/vfs_syscalls.c and I don't see much of a difference in terms of paths taken in the rename function. Note, I do the same thing in remove without any problems. Thanks for any help ttyl Dima -- Dima Brodsky dima@cs.ubc.ca http://www.cs.ubc.ca/~dima 201-2366 Main Mall (604) 822-6179 (Office) Department of Computer Science (604) 822-2895 (DSG Lab) University of British Columbia, Canada (604) 822-5485 (FAX) Computers are like Old Testament gods; lots of rules and no mercy. (Joseph Campbell) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Sep 28 1:36:51 2000 Delivered-To: freebsd-fs@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id DC2CA37B422 for ; Thu, 28 Sep 2000 01:36:48 -0700 (PDT) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id BAA02799; Thu, 28 Sep 2000 01:36:05 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp01.primenet.com, id smtpdAAAOva4Af; Thu Sep 28 01:36:03 2000 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id BAA11788; Thu, 28 Sep 2000 01:36:43 -0700 (MST) From: Terry Lambert Message-Id: <200009280836.BAA11788@usr02.primenet.com> Subject: Re: crypto fs? To: kuku@gilberto.physik.rwth-aachen.de (Christoph Kukulies) Date: Thu, 28 Sep 2000 08:36:43 +0000 (GMT) Cc: freebsd-fs@FreeBSD.ORG In-Reply-To: <200009140958.LAA77431@gilberto.physik.rwth-aachen.de> from "Christoph Kukulies" at Sep 14, 2000 11:58:18 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Is there an implementation of the crypto filesystem for FreeBSD? > > Such that a disk that falls into hands of anyone not knowing > the secret key cannot be decyphered in the duration of the universe? Sorry for the latency on the reply. Yes, several students of John Heidemann's at UCLA built a crypto FS; they have also built a compressing FS. John is the guy who built the VFS stacking code for the UCLA FICUS project; it is the code that is used by FreeBSD today. Last time I talked to John, he was wiling to release the code for experimental purposes, so long as you were willing to agree to a non-redistribution waiver. Note that the FreeBSD VFS stacking is still somewhat broken due to cached object duplication in the way FreeBSD deals with vnodes as backing objects, so having the code for a FreeBSD system (as opposed to a BSDI or Solaris system) may not do you much good. 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 From owner-freebsd-fs Thu Sep 28 5: 4:23 2000 Delivered-To: freebsd-fs@freebsd.org Received: from chuggalug.clues.com (chuggalug.clues.com [194.159.1.85]) by hub.freebsd.org (Postfix) with ESMTP id 6F2D437B422 for ; Thu, 28 Sep 2000 05:04:21 -0700 (PDT) Received: (from geoffb@localhost) by chuggalug.clues.com (8.9.3/8.9.3) id NAA02389 for freebsd-fs@freebsd.org; Thu, 28 Sep 2000 13:04:20 +0100 (BST) (envelope-from geoffb) Date: Thu, 28 Sep 2000 13:04:19 +0100 From: Geoff Buckingham To: freebsd-fs@freebsd.org Subject: XFS Message-ID: <20000928130419.A2374@chuggalug.clues.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Sorry if this is old hat but on reading the caveats for SGIs XFS beta release. http://oss.sgi.com/projects/xfs/beta_caveats.html It seems rather badly hindered by the linux kernely. Was a FreeBSD port written off because of the GPL? -- GeoffB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Sep 28 6:21:43 2000 Delivered-To: freebsd-fs@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 9636637B422 for ; Thu, 28 Sep 2000 06:21:31 -0700 (PDT) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id GAA14107; Thu, 28 Sep 2000 06:18:50 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpdAAA1IaODB; Thu Sep 28 06:18:45 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id GAA27231; Thu, 28 Sep 2000 06:21:15 -0700 (MST) From: Terry Lambert Message-Id: <200009281321.GAA27231@usr05.primenet.com> Subject: Re: XFS To: geoffb@chuggalug.clues.com (Geoff Buckingham) Date: Thu, 28 Sep 2000 13:21:14 +0000 (GMT) Cc: freebsd-fs@FreeBSD.ORG In-Reply-To: <20000928130419.A2374@chuggalug.clues.com> from "Geoff Buckingham" at Sep 28, 2000 01:04:19 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Sorry if this is old hat but on reading the caveats for SGIs XFS beta release. > > http://oss.sgi.com/projects/xfs/beta_caveats.html > > It seems rather badly hindered by the linux kernely. > > Was a FreeBSD port written off because of the GPL? I have talked to SGI's chief scientist about the license, and he is rather adamant. This is not surprising, since I think it was Larry McVoy's and Jeremy Allison's GPL influence that got the ball rolling on them releasing anything at all. He also didn't seem to get that any improvements coming from the community would not be allowed to be integrated back into IRIX, unless all of IRIX were to become GPL'ed. Rather than mark him off as "clueless" (despite a "why can't FreeBSD go GPL?" comment), I rather think they don't believe that they will get improvements that they care about from the community; either this is hubris ("we're professionals, not hackers!"), a loss leader, or it's just a way to get into the press. Without a license change, XFS can never ship compiled into the FreeBSD GENERIC kernel by default, and it can therefore never really be used as a boot filesystem for anything important or useful, apart from individual's hobby machines or commercial machines which are never, ever sold to customers. I tried to convince him about the existance of serious FS researchers mostly doing their work on BSD, and that he was locking out a lot of contributions, not to mention improvements that could be rolled into IRIX, but he was pretty much just not interested. My main interest has been in the recovery characteristics following a failure, since the soft updates "come up and run the cylinder group cleanup in the background" can not be achieved without NVRAM, and then only in the case of 3 out of 5 types of failures (see the recent discussion on this topic on this list). So at this point, it's an interesting curiousity, but not worth any developement effort. Duplicating it under a different license might be worthwhile; doing so would certainly undercut the SGI folks, if the intent was to limit it to hobby use, in the first place. SGI looks pretty much ready to roll up the sidewalks, anyway, at this point; their only big market is a niche in movie special effects, and "The Matrix" and "Titanic" have shown that Open Source OSs are makinginroads there, too, so they are probably not long for this world. 8-(. 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 From owner-freebsd-fs Thu Sep 28 6:30:47 2000 Delivered-To: freebsd-fs@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 43D9B37B423 for ; Thu, 28 Sep 2000 06:30:43 -0700 (PDT) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id PAA67771; Thu, 28 Sep 2000 15:30:41 +0200 (CEST) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Geoff Buckingham Cc: freebsd-fs@FreeBSD.ORG Subject: Re: XFS References: <20000928130419.A2374@chuggalug.clues.com> From: Dag-Erling Smorgrav Date: 28 Sep 2000 15:30:40 +0200 In-Reply-To: Geoff Buckingham's message of "Thu, 28 Sep 2000 13:04:19 +0100" Message-ID: Lines: 23 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Geoff Buckingham writes: > http://oss.sgi.com/projects/xfs/beta_caveats.html > > It seems rather badly hindered by the linux kernely. > > Was a FreeBSD port written off because of the GPL? I'm not sure what the point of your question is, but: 1) SGI decided to port XFS to Linux mainly to ride the wave. 2) there is no FreeBSD version because XFS was proprietary until the first beta was released a few days ago, so noone had access to information or source code that would allow them to write a FreeBSD XFS driver (short of reverse-engineering the IRIX driver) 3) it's interesting to note that SGI would probably have had an easier time porting XFS to FreeBSD than to Linux; most of the caveats listed on that page would not apply to FreeBSD. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Sep 28 9: 7: 9 2000 Delivered-To: freebsd-fs@freebsd.org Received: from chuggalug.clues.com (chuggalug.clues.com [194.159.1.85]) by hub.freebsd.org (Postfix) with ESMTP id 5F30D37B422 for ; Thu, 28 Sep 2000 09:07:04 -0700 (PDT) Received: (from geoffb@localhost) by chuggalug.clues.com (8.9.3/8.9.3) id RAA02874; Thu, 28 Sep 2000 17:07:02 +0100 (BST) (envelope-from geoffb) Date: Thu, 28 Sep 2000 17:07:01 +0100 From: Geoff Buckingham To: Dag-Erling Smorgrav Cc: freebsd-fs@FreeBSD.ORG Subject: Re: XFS Message-ID: <20000928170701.C2431@chuggalug.clues.com> References: <20000928130419.A2374@chuggalug.clues.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Dag-Erling Smorgrav on Thu, Sep 28, 2000 at 03:30:40PM +0200 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Sep 28, 2000 at 03:30:40PM +0200, Dag-Erling Smorgrav wrote: > > I'm not sure what the point of your question is, but: > Essentially I was wondering if following this announcement, and the availability of code XFS was likely to make it's way into /usr/src/contrib one day. I understand the GPL issues but have spent the last 4-5 years building/maintaining/fixing soloutions for large ISPs/telco/webhosting companies. In that time I have come to appreciate the perfomance and recovery characteristic of XFS in IRIX. Also appreciated the performace reliability and maintainability (is that a real word?) of FreeBSD. In addition I had to fix a couple of busy services that had been deployed on Linux and broken under load (usually through a combination of poor design and the limitations of the Linux kernel). I now find myself in the movie/internet world, looking for 5TB+ file systems to run 24x7 XFS is attractive. Linux is not. > > 3) it's interesting to note that SGI would probably have had an > easier time porting XFS to FreeBSD than to Linux; most of the > caveats listed on that page would not apply to FreeBSD. > :-) I came to that conclusion too. -- GeoffB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Sep 28 10: 6:53 2000 Delivered-To: freebsd-fs@freebsd.org Received: from squishycow.goldenterrace.com.au (squishycow.goldenterrace.com.au [203.41.110.130]) by hub.freebsd.org (Postfix) with ESMTP id 4BAEA37B424; Thu, 28 Sep 2000 10:06:43 -0700 (PDT) Received: from roaming.cacheboy.net (unknown [203.41.110.145]) by squishycow.goldenterrace.com.au (Postfix) with ESMTP id DA15319D1A; Fri, 29 Sep 2000 04:06:28 +1100 (EST) Received: (from adrian@localhost) by roaming.cacheboy.net (8.11.0/8.11.0) id e8S5vmL01766; Thu, 28 Sep 2000 07:57:48 +0200 (CEST) (envelope-from adrian) Date: Thu, 28 Sep 2000 07:57:47 +0200 From: Adrian Chadd To: Bruce Evans Cc: freebsd-current@freebsd.org, freebsd-fs@freebsd.org Subject: Re: Fsck wrappers, revisited Message-ID: <20000928075747.B1740@roaming.cacheboy.net> References: <20000923114434.A4419@roaming.cacheboy.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from bde@zeta.org.au on Tue, Sep 26, 2000 at 03:51:51AM +1100 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Sep 26, 2000, Bruce Evans wrote: > > Well, if you have any suggestions, I'm all for it. :-) > > I don't understand the problem. You get the filesystem type name > (fstypename) from fs_vfstype in struct fstab or from f_fstypename in > struct statfs. You attempt to execute strcat("/sbin/fsck_", fstypename) > to see if fsck is supported on filesystems of type fstypename. You don't try to auto-detect and fsck a mounted FS. If its mounted and you are doing it during bootup, it'll generally be in fstab which the current wrapper code looks in. So, the question is: how do you take the raw disk device and figure out which FS type it is, and then which fsck program to run? Adrian -- Adrian Chadd "The main reason Santa is so jolly is because he knows where all the bad girls live." -- Random IRC quote To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Sep 28 23:41:33 2000 Delivered-To: freebsd-fs@freebsd.org Received: from hermes.mixx.net (hermes.mixx.net [212.84.196.2]) by hub.freebsd.org (Postfix) with ESMTP id D577837B424 for ; Thu, 28 Sep 2000 23:41:28 -0700 (PDT) Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 8C7B4F904 for ; Fri, 29 Sep 2000 08:41:22 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 43DE32CA6D; Fri, 29 Sep 2000 08:41:22 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.bln.list.freebsd.fs Subject: Re: XFS Date: 29 Sep 2000 06:41:22 GMT Organization: innominate AG, Berlin, Germany Lines: 17 Distribution: local Message-ID: References: <20000928130419.A2374@chuggalug.clues.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 970209682 2084 10.0.0.69 (29 Sep 2000 06:41:22 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.4.0-test5 (i586)) To: fs@FreeBSD.org Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dag-Erling Smorgrav wrote: > 2) there is no FreeBSD version because XFS was proprietary until the > first beta was released a few days ago, so noone had access to > information or source code that would allow them to write a > FreeBSD XFS driver (short of reverse-engineering the IRIX driver) just a small correction: the XFS code is public available since end of march this yaer not only since the beta t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Sep 28 23:55:56 2000 Delivered-To: freebsd-fs@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 34EFD37B422 for ; Thu, 28 Sep 2000 23:55:46 -0700 (PDT) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id XAA18322; Thu, 28 Sep 2000 23:54:59 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpdAAAiMa4VJ; Thu Sep 28 23:54:50 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id XAA13410; Thu, 28 Sep 2000 23:55:31 -0700 (MST) From: Terry Lambert Message-Id: <200009290655.XAA13410@usr08.primenet.com> Subject: Re: XFS To: graichen@innominate.de Date: Fri, 29 Sep 2000 06:55:31 +0000 (GMT) Cc: fs@FreeBSD.ORG In-Reply-To: from "Thomas Graichen" at Sep 29, 2000 06:41:22 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > 2) there is no FreeBSD version because XFS was proprietary until the > > first beta was released a few days ago, so noone had access to > > information or source code that would allow them to write a > > FreeBSD XFS driver (short of reverse-engineering the IRIX driver) > > just a small correction: the XFS code is public available since > end of march this yaer not only since the beta I originally found the code by going "URL fishing" at about that time, before they even had the links on the main web site up. At the time, it was only a very small portion of the code, since most of it was not "sanitized" of copyrighted material from USL, etc.. This appears to be the first release of function, non-crippled, non-fragmentary code that would be usable for anything like a port. 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 From owner-freebsd-fs Fri Sep 29 7:48:42 2000 Delivered-To: freebsd-fs@freebsd.org Received: from akademie3000.de (akademie3000.de [194.121.70.49]) by hub.freebsd.org (Postfix) with ESMTP id 82D4737B43C; Fri, 29 Sep 2000 07:48:33 -0700 (PDT) Received: from schlappy.mobile.tld ([12.128.176.177]) by akademie3000.de (8.9.2/8.9.2) with ESMTP id QAA01042; Fri, 29 Sep 2000 16:48:15 +0200 (CEST) Received: (from andre@localhost) by schlappy.mobile.tld (8.11.0/8.11.0) id e8TESkw00722; Fri, 29 Sep 2000 16:28:46 +0200 (CEST) (envelope-from andre) Date: Fri, 29 Sep 2000 16:28:46 +0200 From: Andre Albsmeier To: Greg Lehey Cc: Marc Tardif , freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: ccd with other filesystems Message-ID: <20000929162846.A698@schlappy.mobile.tld> References: <20000923133806.B78943@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20000923133806.B78943@wantadilla.lemis.com>; from grog@lemis.com on Sat, Sep 23, 2000 at 01:38:06PM +0930 X-Echelon: BND CIA NSA Mossad KGB MI6 IRA detonator nuclear assault strike Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 23-Sep-2000 at 13:38:06 +0930, Greg Lehey wrote: > > ... > > > I ask because I'm not sure how the word "partition" is used > > in the manpage, is it suppose to mean a slice (as in DOS > > partition) or the partition of a slice? Also, I'm intrigued > > by the following passage: > > Note that the `raw' partitions of the disks should not be > > combined. > > I really don't understand what this is supposed to mean. Could this mean that you should not use the 'c' partitions as ccd components? I, for example, use the 'a' partitions which start at sector 16... -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Sep 29 9:25:32 2000 Delivered-To: freebsd-fs@freebsd.org Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by hub.freebsd.org (Postfix) with ESMTP id AD06137B422 for ; Fri, 29 Sep 2000 09:25:23 -0700 (PDT) Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA28861 for ; Fri, 29 Sep 2000 09:17:33 -0700 (PDT) mail_from (overby@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id LAA6241728 for ; Fri, 29 Sep 2000 11:25:15 -0500 (CDT) Received: from zhadum.americas.sgi.com (zhadum.americas.sgi.com [128.162.184.32]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id LAA24259 for ; Fri, 29 Sep 2000 11:25:15 -0500 (CDT) Received: by zhadum.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id LAA41951; Fri, 29 Sep 2000 11:25:15 -0500 (CDT) Message-Id: <200009291625.LAA41951@zhadum.americas.sgi.com> Date: Fri, 29 Sep 2000 11:25:15 -0500 (CDT) To: freebsd-fs@freebsd.org From: overby@rrnet.com (Glen Overby) Subject: Re: XFS Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ I read this list via a mail-to-news gateway so I might be a bit behind on discussions ] tlambert@primenet.com (Terry Lambert) flamed: > I have talked to SGI's chief scientist about the license, SGI is afraid of competitors (Sun, HP, etc) porting XFS to their own proprietary OS. In a sick sort of way, the GPL protects SGI from that. You won't see a non-GPL XFS coming from SGI. Sorry. > anything at all. He also didn't seem to get that any > improvements coming from the community would not be > allowed to be integrated back into IRIX, unless all of I'm disappointed to see you take the opinions & attitudes of one chief as being representative of everyone here. But many of us do "get it". One of the plans is/was to request copyright assignment for contributions that we want to move back to Irix. I haven't heard of that happening, but I do believe that the (few) external contributions were incorporated into the Linux XFS source tree. This works because Irix XFS and Linux XFS are completely separate source trees. I've seen what they did to XFS to work around the things that Linux didn't have and to do big endian / little endian translation. I'm hoping those never make it back into Irix. There's no reason you couldn't have a small FFS root filesystem, load XFS as a kernel module from that filesystem and use XFS for your big filesystems. BTW, isn't FreeBSD all loadable kernel modules now? If so, maybe it could be loaded at boot time. No, I won't pay for the defense lawyers when FSF sues :-) > I rather think they don't believe that they will get > improvements that they care about from the community; > either this is hubris ("we're professionals, not hackers!"), > a loss leader, or it's just a way to get into the press. While the chief you talked to may have not quite understood how to work with others, that doesn't reflect the attitudes others working on Linux XFS. As for SGI's future, XFS is "free" (as free as any GPLed code gets) and thus is no longer tied to SGI's future. If "the community" wants to continue with it after the demise you're predicting, they're free to do so. BTW, thanks for sending out this flame. It reminded me why I stopped trying to do contribute to FreeBSD years ago. des@ofug.org (Dag-Erling Smorgrav) flamed: > 1) SGI decided to port XFS to Linux mainly to ride the wave. SGI agreed to open source XFS after several individuals inside the company convinced certain executives to do so. The individials' intent was to help Linux. The executives' decisions may not have been as altruistic. > 2) there is no FreeBSD version because XFS was proprietary until the > first beta was released a few days ago, so noone had access to Wrong. XFS escaped from the lawyer's grasp several months ago and has been available from OSS.sgi.com since then. I think a tarball was done of only the initial code; since then you need to use CVS. > 3) it's interesting to note that SGI would probably have had an > easier time porting XFS to FreeBSD than to Linux; most of the > caveats listed on that page would not apply to FreeBSD. I thought so, too, at first. In retrospect thats not true. FreeBSD vnodes != Irix vnodes FreeBSD virtual memroy != Irix virtual memory FreeBSD buffer cache != Irix buffer cache FWIW, there are two people in the XFS group who run FreeBSD at home. We'd love to have the time to port XFS to FreeBSD (or, like Linux, we'd love to port FreeBSD to XFS :-) If anyone wants to give a port a try, I'll try to answer [technical :-)] questions you have about XFS. Glen Overby I don't speak for SGI. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Sep 29 10: 0:18 2000 Delivered-To: freebsd-fs@freebsd.org Received: from msp-26-178-57.mn.rr.com (msp-26-178-57.mn.rr.com [24.26.178.57]) by hub.freebsd.org (Postfix) with ESMTP id D419737B423 for ; Fri, 29 Sep 2000 10:00:15 -0700 (PDT) Received: by msp-26-178-57.mn.rr.com (Postfix, from userid 501) id 7C62C5F0; Fri, 29 Sep 2000 12:00:09 -0500 (CDT) Date: Fri, 29 Sep 2000 12:00:09 -0500 From: Goblin To: Glen Overby Cc: freebsd-fs@freebsd.org Subject: Re: XFS Message-ID: <20000929120009.A5990@uswest.net> References: <200009291625.LAA41951@zhadum.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline User-Agent: Mutt/1.3.9i In-Reply-To: <200009291625.LAA41951@zhadum.americas.sgi.com>; from overby@rrnet.com on Fri, Sep 29, 2000 at 11:25:15AM -0500 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Why can't there be a vmount style port? BTW, does vmount still exist? (Sorry, it's been a while since I've been on FBSD due to alien hardware.) A userland vmount type port wouldn't have quite the performance, but it would be cool. On 09/29, Glen Overby rearranged the electrons to read: >=20 > [ I read this list via a mail-to-news gateway so I might be a bit > behind on discussions ] >=20 > tlambert@primenet.com (Terry Lambert) flamed: > > I have talked to SGI's chief scientist about the license, >=20 > SGI is afraid of competitors (Sun, HP, etc) porting XFS to their own > proprietary OS. In a sick sort of way, the GPL protects SGI from > that. You won't see a non-GPL XFS coming from SGI. Sorry. >=20 > > anything at all. He also didn't seem to get that any > > improvements coming from the community would not be > > allowed to be integrated back into IRIX, unless all of >=20 > I'm disappointed to see you take the opinions & attitudes of one chief > as being representative of everyone here. >=20 > But many of us do "get it". One of the plans is/was to request > copyright assignment for contributions that we want to move back to > Irix. I haven't heard of that happening, but I do believe that the > (few) external contributions were incorporated into the Linux XFS > source tree. >=20 > This works because Irix XFS and Linux XFS are completely separate > source trees. I've seen what they did to XFS to work around the > things that Linux didn't have and to do big endian / little endian > translation. I'm hoping those never make it back into Irix. >=20 > There's no reason you couldn't have a small FFS root filesystem, load > XFS as a kernel module from that filesystem and use XFS for your big > filesystems. BTW, isn't FreeBSD all loadable kernel modules now? If > so, maybe it could be loaded at boot time. >=20 > No, I won't pay for the defense lawyers when FSF sues :-) >=20 > > I rather think they don't believe that they will get > > improvements that they care about from the community; > > either this is hubris ("we're professionals, not hackers!"), > > a loss leader, or it's just a way to get into the press. >=20 > While the chief you talked to may have not quite understood how to > work with others, that doesn't reflect the attitudes others working on > Linux XFS. >=20 > As for SGI's future, XFS is "free" (as free as any GPLed code gets) Your eyes are weary from staring at the CRT. You feel sleepy. Notice how restful it is to watch the cursor blink. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise. --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE51MqYubgCGkrWpN4RAoA1AJ0abWvQct31h5DBZDW4yP4bQY+34ACeLIcD 9QVBOCyn5GcCsbOqIcltyU4= =y7Ai -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Sep 29 10: 3:34 2000 Delivered-To: freebsd-fs@freebsd.org Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by hub.freebsd.org (Postfix) with ESMTP id DAF9C37B423 for ; Fri, 29 Sep 2000 10:03:31 -0700 (PDT) Received: from shekel.mcl.cs.columbia.edu (shekel.mcl.cs.columbia.edu [128.59.18.15]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA25759; Fri, 29 Sep 2000 13:03:27 -0400 (EDT) Received: (from ezk@localhost) by shekel.mcl.cs.columbia.edu (8.9.3/8.9.3) id NAA29170; Fri, 29 Sep 2000 13:03:26 -0400 (EDT) Date: Fri, 29 Sep 2000 13:03:26 -0400 (EDT) Message-Id: <200009291703.NAA29170@shekel.mcl.cs.columbia.edu> From: Erez Zadok To: Terry Lambert Cc: kuku@gilberto.physik.rwth-aachen.de (Christoph Kukulies), freebsd-fs@FreeBSD.ORG Subject: Re: crypto fs? In-reply-to: Your message of "Thu, 28 Sep 2000 08:36:43 -0000." <200009280836.BAA11788@usr02.primenet.com> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <200009280836.BAA11788@usr02.primenet.com>, Terry Lambert writes: > > Is there an implementation of the crypto filesystem for FreeBSD? > > > > Such that a disk that falls into hands of anyone not knowing > > the secret key cannot be decyphered in the duration of the universe? > > Sorry for the latency on the reply. > > Yes, several students of John Heidemann's at UCLA built a crypto > FS; they have also built a compressing FS. Actually they never got a stackable compression f/s built or working. I asked John about his SOSP15 paper. He told me that they had a low-level block-style compression prototype instead. Mine in the only known (so far :-) working stackable compression f/s. My templates (Linux only) can do arbitrary size-changing f/s: I have a working gzipfs, uuencodefs, etc. See http://www.cs.columbia.edu/~ezk/research/fist/ for code and papers. Cheers, Erez. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Sep 29 15:31:39 2000 Delivered-To: freebsd-fs@freebsd.org Received: from brutus.conectiva.com.br (brutus.conectiva.com.br [200.250.58.146]) by hub.freebsd.org (Postfix) with ESMTP id 3F35437B503 for ; Fri, 29 Sep 2000 15:31:34 -0700 (PDT) Received: from localhost (riel@localhost) by brutus.conectiva.com.br (8.10.2/8.10.2) with ESMTP id e8TMVEZ13858; Fri, 29 Sep 2000 19:31:14 -0300 X-Authentication-Warning: duckman.distro.conectiva: riel owned process doing -bs Date: Fri, 29 Sep 2000 19:31:14 -0300 (BRST) From: Rik van Riel X-Sender: riel@duckman.distro.conectiva To: Glen Overby Cc: freebsd-fs@FreeBSD.ORG Subject: Re: XFS In-Reply-To: <200009291625.LAA41951@zhadum.americas.sgi.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 On Fri, 29 Sep 2000, Glen Overby wrote: > tlambert@primenet.com (Terry Lambert) flamed: > > I have talked to SGI's chief scientist about the license, > > SGI is afraid of competitors (Sun, HP, etc) porting XFS to their own > proprietary OS. In a sick sort of way, the GPL protects SGI from > that. You won't see a non-GPL XFS coming from SGI. Sorry. There is a nice license comparison from the point of view of game theory on the following URL. This might explain the reason behind licensing decisions being made by some businesses. http://www2.fastdial.net/~drysdam/essays/GPL-as-strategy.html > BTW, thanks for sending out this flame. It reminded me why I > stopped trying to do contribute to FreeBSD years ago. I wonder how much of the cultural difference between BSD and Linux is due to licensing ... (and no, personally I don't care about the particular license; _my_ gains are in the fact that I can program on stuff I think is cool and get paid for it .. and that I can freely exchange my ideas with others) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Sep 30 18:47:27 2000 Delivered-To: freebsd-fs@freebsd.org Received: from mail.webmonster.de (datasink.webmonster.de [194.162.162.209]) by hub.freebsd.org (Postfix) with SMTP id A7AF237B66C for ; Sat, 30 Sep 2000 18:47:24 -0700 (PDT) Received: (qmail 84237 invoked by uid 1000); 1 Oct 2000 01:47:19 -0000 Date: Sun, 1 Oct 2000 03:47:19 +0200 From: "Karsten W. Rohrbach" To: Julian Elischer Cc: Archie Cobbs , Soren Schmidt , mbendiks@eunet.no, terry@lambert.org, fs@freebsd.org Subject: Re: disable write caching with softupdates? Message-ID: <20001001034719.C83678@rohrbach.de> Reply-To: karsten@rohrbach.de References: <200009211900.MAA18117@bubba.whistle.com> <39CA6304.2781E494@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <39CA6304.2781E494@elischer.org>; from julian@elischer.org on Thu, Sep 21, 2000 at 12:35:32PM -0700 X-Arbitrary-Number-Of-The-Day: 42 X-Sender: karsten@rohrbach.de Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Julian Elischer(julian@elischer.org)@Thu, Sep 21, 2000 at 12:35:32PM -0700: [...] > > Archies comment about MOST drives not supporting safe writing of > accepted work is an understatement. When I was testing and selecting > drives for the interjet, I found NO drives that would guarantee that > data accepted for writing would be written in the case of power > failure. were those only ata or scsi drives, too? /k -- > "There is a God, but He drinks" -- Blore KR433/KR11-RIPE -- http://www.webmonster.de -- ftp://ftp.webmonster.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Sep 30 19: 5:23 2000 Delivered-To: freebsd-fs@freebsd.org Received: from mail.webmonster.de (datasink.webmonster.de [194.162.162.209]) by hub.freebsd.org (Postfix) with SMTP id 5E53737B66D for ; Sat, 30 Sep 2000 19:05:21 -0700 (PDT) Received: (qmail 84568 invoked by uid 1000); 1 Oct 2000 02:05:20 -0000 Date: Sun, 1 Oct 2000 04:05:20 +0200 From: "Karsten W. Rohrbach" To: Marius Bendiksen Cc: Dag-Erling Smorgrav , Dwight Tuinstra , freebsd-fs Subject: Re: Journaling Filesystems in bsd? (LFS, anyone?) Message-ID: <20001001040520.D83678@rohrbach.de> Reply-To: karsten@rohrbach.de References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from mbendiks@eunet.no on Mon, Sep 25, 2000 at 02:40:21PM +0200 X-Arbitrary-Number-Of-The-Day: 42 X-Sender: karsten@rohrbach.de Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Marius Bendiksen(mbendiks@eunet.no)@Mon, Sep 25, 2000 at 02:40:21PM +0200: [...] > more proper such filesystem. Or, get someone to port WAFL, and get NVRAM. this would be an interesting thing. with all the negative points of nvram you got a few good points in wafl design which might be of interest when it comes to lots of disks carrying one filesystem: a) metadata is contained in files b) those files are successors, referenced by the last on-volume snap c) spreading the file system over a bunch of disks is easy, also without lvm by design d) devices in a bunch can be different size e) you can hot-grow the filesystem (if your hardware supports hot-plug) f) you can have as many files as you wish (or limit in your hashing structure) on a volume g) linear write window over all devices is netapp's wafl concept patented somehow? /k -- > 71: 69 with two fingers up your ass. -- George Carlin KR433/KR11-RIPE -- http://www.webmonster.de -- ftp://ftp.webmonster.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Sep 30 19: 7:39 2000 Delivered-To: freebsd-fs@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 2514F37B502 for ; Sat, 30 Sep 2000 19:07:37 -0700 (PDT) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id TAA15959; Sat, 30 Sep 2000 19:04:35 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpdAAAoFayiF; Sat Sep 30 19:04:32 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id TAA18108; Sat, 30 Sep 2000 19:07:27 -0700 (MST) From: Terry Lambert Message-Id: <200010010207.TAA18108@usr05.primenet.com> Subject: Re: disable write caching with softupdates? To: karsten@rohrbach.de Date: Sun, 1 Oct 2000 02:07:22 +0000 (GMT) Cc: julian@elischer.org (Julian Elischer), archie@whistle.com (Archie Cobbs), sos@freebsd.dk (Soren Schmidt), mbendiks@eunet.no, terry@lambert.org, fs@freebsd.org In-Reply-To: <20001001034719.C83678@rohrbach.de> from "Karsten W. Rohrbach" at Oct 01, 2000 03:47:19 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Karsten writes: > Julian Elischer(julian@elischer.org)@Thu, Sep 21, 2000 at 12:35:32PM -0700: > [...] > > > > Archies comment about MOST drives not supporting safe writing of > > accepted work is an understatement. When I was testing and selecting > > drives for the interjet, I found NO drives that would guarantee that > > data accepted for writing would be written in the case of power > > failure. > were those only ata or scsi drives, too? ATA (IDE). The InterJet uses IDE drives only. It's not expected to have a high non-serialized load, even though it has AFS and SMB servers on board. 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 From owner-freebsd-fs Sat Sep 30 19: 9:44 2000 Delivered-To: freebsd-fs@freebsd.org Received: from mail.webmonster.de (datasink.webmonster.de [194.162.162.209]) by hub.freebsd.org (Postfix) with SMTP id 9E35137B503 for ; Sat, 30 Sep 2000 19:09:38 -0700 (PDT) Received: (qmail 84647 invoked by uid 1000); 1 Oct 2000 02:09:37 -0000 Date: Sun, 1 Oct 2000 04:09:37 +0200 From: "Karsten W. Rohrbach" To: Andre Albsmeier Cc: Greg Lehey , Marc Tardif , freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: ccd with other filesystems Message-ID: <20001001040937.E83678@rohrbach.de> Reply-To: karsten@rohrbach.de References: <20000923133806.B78943@wantadilla.lemis.com> <20000929162846.A698@schlappy.mobile.tld> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000929162846.A698@schlappy.mobile.tld>; from andre@akademie3000.de on Fri, Sep 29, 2000 at 04:28:46PM +0200 X-Arbitrary-Number-Of-The-Day: 42 X-Sender: karsten@rohrbach.de Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org the 'a' partition is reserved for the rootfs, as 'b' is for swap and 'c' for the whole device. you should use 'e' and p for payload (eg. mounted filesystems) i dont quite know why it is still possible doing a newfs on a 'c' partition, since the partition type is 'unused' and not '4.2BSD'. newfs should check this and throw an error while providing an expert-only-feature command line option to explicitly override it. it is a bad thing[tm] to be able to wedge every single blockdev in your system by (ab)using newfs. /k Andre Albsmeier(andre@akademie3000.de)@Fri, Sep 29, 2000 at 04:28:46PM +0200: > On Sat, 23-Sep-2000 at 13:38:06 +0930, Greg Lehey wrote: > > > > ... > > > > > I ask because I'm not sure how the word "partition" is used > > > in the manpage, is it suppose to mean a slice (as in DOS > > > partition) or the partition of a slice? Also, I'm intrigued > > > by the following passage: > > > Note that the `raw' partitions of the disks should not be > > > combined. > > > > I really don't understand what this is supposed to mean. > > Could this mean that you should not use the 'c' partitions as ccd > components? I, for example, use the 'a' partitions which start at > sector 16... > > -Andre > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" in the body of the message -- > What can you use used tampons for? Tea bags for vampires. KR433/KR11-RIPE -- http://www.webmonster.de -- ftp://ftp.webmonster.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Sep 30 19:16:19 2000 Delivered-To: freebsd-fs@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 3C41137B503; Sat, 30 Sep 2000 19:16:11 -0700 (PDT) Received: (from grog@localhost) by wantadilla.lemis.com (8.11.0/8.9.3) id e912Fe844311; Sun, 1 Oct 2000 11:45:40 +0930 (CST) (envelope-from grog) Date: Sun, 1 Oct 2000 11:45:40 +0930 From: Greg Lehey To: "Karsten W. Rohrbach" Cc: Andre Albsmeier , Marc Tardif , freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: ccd with other filesystems Message-ID: <20001001114540.G43885@wantadilla.lemis.com> References: <20000923133806.B78943@wantadilla.lemis.com> <20000929162846.A698@schlappy.mobile.tld> <20001001040937.E83678@rohrbach.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20001001040937.E83678@rohrbach.de>; from karsten@rohrbach.de on Sun, Oct 01, 2000 at 04:09:37AM +0200 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sunday, 1 October 2000 at 4:09:37 +0200, Karsten W. Rohrbach wrote: > Andre Albsmeier(andre@akademie3000.de)@Fri, Sep 29, 2000 at 04:28:46PM +0200: >> On Sat, 23-Sep-2000 at 13:38:06 +0930, Greg Lehey wrote: >>> >>> ... >>> >>>> I ask because I'm not sure how the word "partition" is used >>>> in the manpage, is it suppose to mean a slice (as in DOS >>>> partition) or the partition of a slice? Also, I'm intrigued >>>> by the following passage: >>>> Note that the `raw' partitions of the disks should not be >>>> combined. >>> >>> I really don't understand what this is supposed to mean. >> >> Could this mean that you should not use the 'c' partitions as ccd >> components? I, for example, use the 'a' partitions which start at >> sector 16... > > the 'a' partition is reserved for the rootfs, as 'b' is for swap and > 'c' for the whole device. you should use 'e' and p for payload > (eg. mounted filesystems) None of the partitions is special except for 'c'. By convention we put root file systems on 'a' and swap on 'b', but nothing relies on this convention. > i dont quite know why it is still possible doing a newfs on a 'c' > partition, since the partition type is 'unused' and not > '4.2BSD'. newfs should check this and throw an error while providing > an expert-only-feature command line option to explicitly override > it. I think this is a bug in newfs. It should only create file systems on partitions of type 4.2BSD. Does anybody disagree? Otherwise I'll fix it. > it is a bad thing[tm] to be able to wedge every single blockdev in your > system by (ab)using newfs. Agreed. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Sep 30 19:17:42 2000 Delivered-To: freebsd-fs@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id ECD9737B503 for ; Sat, 30 Sep 2000 19:17:39 -0700 (PDT) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id TAA22948; Sat, 30 Sep 2000 19:15:03 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpdAAA4saiMS; Sat Sep 30 19:14:53 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id TAA18354; Sat, 30 Sep 2000 19:17:22 -0700 (MST) From: Terry Lambert Message-Id: <200010010217.TAA18354@usr05.primenet.com> Subject: Re: Journaling Filesystems in bsd? (LFS, anyone?) To: karsten@rohrbach.de Date: Sun, 1 Oct 2000 02:17:17 +0000 (GMT) Cc: mbendiks@eunet.no (Marius Bendiksen), des@ofug.org (Dag-Erling Smorgrav), tuinstra@clarkson.edu (Dwight Tuinstra), freebsd-fs@FreeBSD.ORG (freebsd-fs) In-Reply-To: <20001001040520.D83678@rohrbach.de> from "Karsten W. Rohrbach" at Oct 01, 2000 04:05:20 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Karsten writes: > Marius Bendiksen(mbendiks@eunet.no)@Mon, Sep 25, 2000 at 02:40:21PM +0200: > [...] > > more proper such filesystem. Or, get someone to port WAFL, and get NVRAM. > > this would be an interesting thing. with all the negative points of > nvram you got a few good points in wafl design which might be of > interest when it comes to lots of disks carrying one filesystem: > a) metadata is contained in files > b) those files are successors, referenced by the last on-volume snap > c) spreading the file system over a bunch of disks is easy, also without > lvm by design > d) devices in a bunch can be different size > e) you can hot-grow the filesystem (if your hardware supports hot-plug) > f) you can have as many files as you wish (or limit in your hashing > structure) on a volume > g) linear write window over all devices > > is netapp's wafl concept patented somehow? There are three patents of which I'm aware. That said, someone has already written a read-only WAFL FS for FreeBSD; it was announced to the FreeBSD FS list several weeks ago. Another interesting concept is described in: The Design and Implementation of a DCD Device Driver for UNIX Tycho Nightengale, Yiming Hu, Qing Yang 1999 Usenix Ignore the fact that Jordan and I are thanked for a tiny amount of information at the end of the paper: it's a very good paper, anyway. ;^) 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 From owner-freebsd-fs Sat Sep 30 19:28:31 2000 Delivered-To: freebsd-fs@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 3E71C37B503; Sat, 30 Sep 2000 19:28:26 -0700 (PDT) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id TAA20661; Sat, 30 Sep 2000 19:28:46 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAADAa4vO; Sat Sep 30 19:28:37 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id TAA18618; Sat, 30 Sep 2000 19:28:14 -0700 (MST) From: Terry Lambert Message-Id: <200010010228.TAA18618@usr05.primenet.com> Subject: Re: ccd with other filesystems To: grog@lemis.com (Greg Lehey) Date: Sun, 1 Oct 2000 02:28:09 +0000 (GMT) Cc: karsten@rohrbach.de (Karsten W. Rohrbach), andre@akademie3000.de (Andre Albsmeier), intmktg@CAM.ORG (Marc Tardif), freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG In-Reply-To: <20001001114540.G43885@wantadilla.lemis.com> from "Greg Lehey" at Oct 01, 2000 11:45:40 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Greg Writes: > None of the partitions is special except for 'c'. By convention we > put root file systems on 'a' and swap on 'b', but nothing relies on > this convention. The kernel and other files loaded by the loader myst be below the 1024 cylinder boundary on the disk, since the FrrBSD boot loader, unlike Linux's LILO, can not read past cylinder 1024, since it does not understand how to make LBA BIOS calls properly. If you have a FreeBSD straddling the 8G boundary on a large drive, therefore, you will want to ensure that whatever partition you place "/" on is entirely below the 8G limit. You're right that this is no necessarily "a", but in general, the installation tools will order allocations as a,b,..., which makes it "a" in common practice. The same applies to a FreeBSD-only system, with a very large drive, even if it's "dangerously dedicated". > > i dont quite know why it is still possible doing a newfs on a 'c' > > partition, since the partition type is 'unused' and not > > '4.2BSD'. newfs should check this and throw an error while providing > > an expert-only-feature command line option to explicitly override > > it. > > I think this is a bug in newfs. It should only create file systems on > partitions of type 4.2BSD. Does anybody disagree? Otherwise I'll fix > it. I have several systems, where the entirety of the disk (the "c" partition) is mounted as a single file system. So long as this is done right, such that I can tell it that the "c" partition is of type "4.2BSD", and so long as the sysinstall and other tools do the right thing, it doesn't matter to me if you fix it. But... > > it is a bad thing[tm] to be able to wedge every single blockdev in your > > system by (ab)using newfs. > > Agreed. This appears to be a problem with not checking the label for overlap, since a mounted FS should not be spam'able under any circumstances. Protecting people from spam'ming unmounted FSs by pounding on "c" might be a laudable goal, but provides only a tiny amount of additional protection. 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 From owner-freebsd-fs Sat Sep 30 19:35:32 2000 Delivered-To: freebsd-fs@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 9B7F737B502; Sat, 30 Sep 2000 19:35:21 -0700 (PDT) Received: (from grog@localhost) by wantadilla.lemis.com (8.11.0/8.9.3) id e912YrT49033; Sun, 1 Oct 2000 12:04:53 +0930 (CST) (envelope-from grog) Date: Sun, 1 Oct 2000 12:04:53 +0930 From: Greg Lehey To: Terry Lambert Cc: "Karsten W. Rohrbach" , Andre Albsmeier , Marc Tardif , freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: ccd with other filesystems Message-ID: <20001001120453.I43885@wantadilla.lemis.com> References: <20001001114540.G43885@wantadilla.lemis.com> <200010010228.TAA18618@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200010010228.TAA18618@usr05.primenet.com>; from tlambert@primenet.com on Sun, Oct 01, 2000 at 02:28:09AM +0000 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sunday, 1 October 2000 at 2:28:09 +0000, Terry Lambert wrote: > Greg Writes: >> None of the partitions is special except for 'c'. By convention we >> put root file systems on 'a' and swap on 'b', but nothing relies on >> this convention. > > The kernel and other files loaded by the loader myst be below > the 1024 cylinder boundary on the disk, since the FrrBSD boot > loader, unlike Linux's LILO, can not read past cylinder 1024, > since it does not understand how to make LBA BIOS calls > properly. This is no longer the case. The restriction was lifted a few months back. >>> i dont quite know why it is still possible doing a newfs on a 'c' >>> partition, since the partition type is 'unused' and not >>> '4.2BSD'. newfs should check this and throw an error while providing >>> an expert-only-feature command line option to explicitly override >>> it. >> >> I think this is a bug in newfs. It should only create file systems on >> partitions of type 4.2BSD. Does anybody disagree? Otherwise I'll fix >> it. > > I have several systems, where the entirety of the disk (the "c" > partition) is mounted as a single file system. You can do it, but it's not a good idea. I'd like to see a good reason for doing this. > So long as this is done right, such that I can tell it that the "c" > partition is of type "4.2BSD", and so long as the sysinstall and > other tools do the right thing, it doesn't matter to me if you fix > it. There is no way to do this right. >>> it is a bad thing[tm] to be able to wedge every single blockdev in your >>> system by (ab)using newfs. >> >> Agreed. > > This appears to be a problem with not checking the label for > overlap, since a mounted FS should not be spam'able under any > circumstances. Protecting people from spam'ming unmounted FSs by > pounding on "c" might be a laudable goal, but provides only a tiny > amount of additional protection. This is a separate issue. Yes, disklabel should warn about a number of things, including overlapping partitions and incorrect partition types (c should be "unused", because by definition it overlaps all other partitions). Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Sep 30 19:49: 4 2000 Delivered-To: freebsd-fs@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 0024037B502; Sat, 30 Sep 2000 19:48:59 -0700 (PDT) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id TAA20726; Sat, 30 Sep 2000 19:47:31 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpdAAA2qayEO; Sat Sep 30 19:47:27 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id TAA19148; Sat, 30 Sep 2000 19:48:53 -0700 (MST) From: Terry Lambert Message-Id: <200010010248.TAA19148@usr05.primenet.com> Subject: Re: ccd with other filesystems To: grog@lemis.com (Greg Lehey) Date: Sun, 1 Oct 2000 02:48:53 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), karsten@rohrbach.de (Karsten W. Rohrbach), andre@akademie3000.de (Andre Albsmeier), intmktg@CAM.ORG (Marc Tardif), freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG In-Reply-To: <20001001120453.I43885@wantadilla.lemis.com> from "Greg Lehey" at Oct 01, 2000 12:04:53 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > The kernel and other files loaded by the loader myst be below > > the 1024 cylinder boundary on the disk, since the FrrBSD boot > > loader, unlike Linux's LILO, can not read past cylinder 1024, > > since it does not understand how to make LBA BIOS calls > > properly. > > This is no longer the case. The restriction was lifted a few months > back. Someone should tell my Sony Vaio, which hated having 4.1 installed on it past 8G on an 18G drive. > > I have several systems, where the entirety of the disk (the "c" > > partition) is mounted as a single file system. > > You can do it, but it's not a good idea. I'd like to see a good > reason for doing this. If "c" is defined to be "the whole disk" , and you want to use "the whole disk", it makes sense. I uses to mount most of my CDROMs that way, as well. > > This appears to be a problem with not checking the label for > > overlap, since a mounted FS should not be spam'able under any > > circumstances. Protecting people from spam'ming unmounted FSs by > > pounding on "c" might be a laudable goal, but provides only a tiny > > amount of additional protection. > > This is a separate issue. Yes, disklabel should warn about a number > of things, including overlapping partitions and incorrect partition > types (c should be "unused", because by definition it overlaps all > other partitions). I really _don't_ want the use of "c" broken ("fixed"). The "c" partition is not "defined" to overlap; it merely does so by default and by istorical convention. I threw away this convention on many of my systems long ago, when I resigned myself to aving a DOS parititon table on my machines, when the Alpha and PReP platforms decided to require it as well. I have eight or ten disks that have non-overlapping "c" values that place their regions between "b" and "d" regions on the disk. If that's not enough, the best argument I have for three of those is "so that I can have one more partition that I would otherwise be permitted to have". 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 From owner-freebsd-fs Sat Sep 30 20:29:57 2000 Delivered-To: freebsd-fs@freebsd.org Received: from mail.webmonster.de (datasink.webmonster.de [194.162.162.209]) by hub.freebsd.org (Postfix) with SMTP id 0E87137B502 for ; Sat, 30 Sep 2000 20:29:54 -0700 (PDT) Received: (qmail 86058 invoked by uid 1000); 1 Oct 2000 03:29:52 -0000 Date: Sun, 1 Oct 2000 05:29:52 +0200 From: "Karsten W. Rohrbach" To: Terry Lambert Cc: freebsd-fs Subject: Re: Journaling Filesystems in bsd? (LFS, anyone?) Message-ID: <20001001052952.F83678@rohrbach.de> Reply-To: karsten@rohrbach.de References: <20001001040520.D83678@rohrbach.de> <200010010217.TAA18354@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200010010217.TAA18354@usr05.primenet.com>; from tlambert@primenet.com on Sun, Oct 01, 2000 at 02:17:17AM +0000 X-Arbitrary-Number-Of-The-Day: 42 X-Sender: karsten@rohrbach.de Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Terry Lambert(tlambert@primenet.com)@Sun, Oct 01, 2000 at 02:17:17AM +0000: > Karsten writes: > > Marius Bendiksen(mbendiks@eunet.no)@Mon, Sep 25, 2000 at 02:40:21PM +0200: > > [...] > > > more proper such filesystem. Or, get someone to port WAFL, and get NVRAM. > > > > this would be an interesting thing. with all the negative points of > > nvram you got a few good points in wafl design which might be of > > interest when it comes to lots of disks carrying one filesystem: > > a) metadata is contained in files > > b) those files are successors, referenced by the last on-volume snap > > c) spreading the file system over a bunch of disks is easy, also without > > lvm by design > > d) devices in a bunch can be different size > > e) you can hot-grow the filesystem (if your hardware supports hot-plug) > > f) you can have as many files as you wish (or limit in your hashing > > structure) on a volume > > g) linear write window over all devices > > > > is netapp's wafl concept patented somehow? > > There are three patents of which I'm aware. could you be more specific, please? > > That said, someone has already written a read-only WAFL FS for > FreeBSD; it was announced to the FreeBSD FS list several weeks > ago. ahum, i obviously skipped over the mail it seems... is this available for download somewhere? or perhaps already committed? ;-) > > Another interesting concept is described in: > > The Design and Implementation of a DCD Device Driver > for UNIX > Tycho Nightengale, Yiming Hu, Qing Yang > 1999 Usenix > > > Ignore the fact that Jordan and I are thanked for a tiny amount > of information at the end of the paper: it's a very good paper, > anyway. ;^) i am sometimes thinking about a different concept of direct-attached storage servers. in other words, a setup like this one: [service server (www,...)] | | (1) <-- SCSI | [storage server] | | (2) <-- SCSI, 1 or more channels | [disks (a lot)] the basic idea is to implement a driver that creates a high-performance block device on tail (1) which can be accessed as a giant scsi disk. the inner workings of that disk should not be visible to the client, eg. the service server (high volume web site, news, whatever). given this abstrakt 'exported' block device, the storage server now can utilize for example greg's vinum and (of course, since it's a cool idea) for example implement the dcd concept or hardware nvram or whatever you wish. bottom line is that the storage server is intelligent enough to do a) strong buffering and intelligent scheduling of writes b) adaptive read caching c) provide high availability by soft/hardware instrumentation like vinum raid-5 code or dedicated controller hardware while offloading most of the i/o processing load off the service server. hm, this mail's now become nearly a paper, too ;-) tell me what you think /k -- > Hackers do it with fewer instructions. KR433/KR11-RIPE -- http://www.webmonster.de -- ftp://ftp.webmonster.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Sep 30 20:41:59 2000 Delivered-To: freebsd-fs@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 4AA3237B502; Sat, 30 Sep 2000 20:41:52 -0700 (PDT) Received: (from grog@localhost) by wantadilla.lemis.com (8.11.0/8.9.3) id e913fQi80746; Sun, 1 Oct 2000 13:11:26 +0930 (CST) (envelope-from grog) Date: Sun, 1 Oct 2000 13:11:26 +0930 From: Greg Lehey To: Terry Lambert Cc: "Karsten W. Rohrbach" , Andre Albsmeier , Marc Tardif , freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Partitioning (was: ccd with other filesystems) Message-ID: <20001001131126.L43885@wantadilla.lemis.com> References: <20001001120453.I43885@wantadilla.lemis.com> <200010010248.TAA19148@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200010010248.TAA19148@usr05.primenet.com>; from tlambert@primenet.com on Sun, Oct 01, 2000 at 02:48:53AM +0000 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sunday, 1 October 2000 at 2:48:53 +0000, Terry Lambert wrote: >>> The kernel and other files loaded by the loader myst be below >>> the 1024 cylinder boundary on the disk, since the FrrBSD boot >>> loader, unlike Linux's LILO, can not read past cylinder 1024, >>> since it does not understand how to make LBA BIOS calls >>> properly. >> >> This is no longer the case. The restriction was lifted a few months >> back. > > Someone should tell my Sony Vaio, which hated having 4.1 installed > on it past 8G on an 18G drive. > >>> I have several systems, where the entirety of the disk (the "c" >>> partition) is mounted as a single file system. >> >> You can do it, but it's not a good idea. I'd like to see a good >> reason for doing this. > > If "c" is defined to be "the whole disk" , and you want to use "the > whole disk", it makes sense. No, you don't *ever* want a UFS on the whole disk, you want it on a partition, because those are the objects on which file systems work. The partition may well cover the entire disk, but that doesn't give it the same semantics as an unused partition which covers it. > I uses to mount most of my CDROMs that way, as well. That's OK. CD-ROMs don't have partitions. It's probably a bug that we even have partition letters for non-partitioned media. >>> This appears to be a problem with not checking the label for >>> overlap, since a mounted FS should not be spam'able under any >>> circumstances. Protecting people from spam'ming unmounted FSs by >>> pounding on "c" might be a laudable goal, but provides only a tiny >>> amount of additional protection. >> >> This is a separate issue. Yes, disklabel should warn about a number >> of things, including overlapping partitions and incorrect partition >> types (c should be "unused", because by definition it overlaps all >> other partitions). > > I really _don't_ want the use of "c" broken ("fixed"). > > The "c" partition is not "defined" to overlap; it merely does so by > default and by istorical convention. Agreed. But there were good reasons for this. > I threw away this convention on many of my systems long ago, when I > resigned myself to aving a DOS parititon table on my machines, when > the Alpha and PReP platforms decided to require it as well. Is your 'h' key sticking? :-) I strongly object to the Microsoft "partition" table, and I don't use it myself. And of course you're welcome to use whatever you find convenient. It's not until you advocate making this a standard way that anybody can have any objection. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Sep 30 20:55:45 2000 Delivered-To: freebsd-fs@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-176-106.dsl.snfc21.pacbell.net [63.202.176.106]) by hub.freebsd.org (Postfix) with ESMTP id 1175237B502 for ; Sat, 30 Sep 2000 20:55:38 -0700 (PDT) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e913vDh00964; Sat, 30 Sep 2000 20:57:13 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200010010357.e913vDh00964@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Terry Lambert Cc: freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: ccd with other filesystems In-reply-to: Your message of "Sun, 01 Oct 2000 02:28:09 -0000." <200010010228.TAA18618@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 Sep 2000 20:57:13 -0700 From: Mike Smith Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Greg Writes: > > None of the partitions is special except for 'c'. By convention we > > put root file systems on 'a' and swap on 'b', but nothing relies on > > this convention. > > The kernel and other files loaded by the loader myst be below > the 1024 cylinder boundary on the disk, since the FrrBSD boot > loader, unlike Linux's LILO, can not read past cylinder 1024, > since it does not understand how to make LBA BIOS calls > properly. This is manifestly untrue. John Baldwin will now hit you with the Damn Thing. > I have several systems, where the entirety of the disk (the "c" > partition) is mounted as a single file system. So long as this > is done right, such that I can tell it that the "c" partition is > of type "4.2BSD", and so long as the sysinstall and other tools > do the right thing, it doesn't matter to me if you fix it. But... Nothing (much) checks the partition type. I'm not entirely sure this is a bad thing (manifest constants are evil). -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Sep 30 23:54:31 2000 Delivered-To: freebsd-fs@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 442D237B503 for ; Sat, 30 Sep 2000 23:54:26 -0700 (PDT) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA31142; Sat, 30 Sep 2000 23:51:38 -0700 (PDT) Date: Sat, 30 Sep 2000 23:51:38 -0700 (PDT) From: Julian Elischer To: "Karsten W. Rohrbach" Cc: Archie Cobbs , Soren Schmidt , mbendiks@eunet.no, terry@lambert.org, fs@freebsd.org Subject: Re: disable write caching with softupdates? In-Reply-To: <20001001034719.C83678@rohrbach.de> 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 We were using ATA drives but teh drive manufactureres also told me the same about SCSI drives. On Sun, 1 Oct 2000, Karsten W. Rohrbach wrote: > Julian Elischer(julian@elischer.org)@Thu, Sep 21, 2000 at 12:35:32PM -0700: > [...] > > > > Archies comment about MOST drives not supporting safe writing of > > accepted work is an understatement. When I was testing and selecting > > drives for the interjet, I found NO drives that would guarantee that > > data accepted for writing would be written in the case of power > > failure. > were those only ata or scsi drives, too? > /k > > > -- > > "There is a God, but He drinks" -- Blore > KR433/KR11-RIPE -- http://www.webmonster.de -- ftp://ftp.webmonster.de > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message