From owner-freebsd-fs@FreeBSD.ORG Sun Feb 18 22:42:07 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 964D216A400; Sun, 18 Feb 2007 22:42:07 +0000 (UTC) (envelope-from joe@tao.org.uk) Received: from mailhost.tao.org.uk (transwarp.tao.org.uk [87.74.4.34]) by mx1.freebsd.org (Postfix) with ESMTP id 4349C13C46B; Sun, 18 Feb 2007 22:42:07 +0000 (UTC) (envelope-from joe@tao.org.uk) Received: from genius.tao.org.uk (wireless58.dhcp.tao.org.uk [87.74.4.58]) by mailhost.tao.org.uk (Postfix) with ESMTP id B732C5FF4; Sun, 18 Feb 2007 22:42:05 +0000 (GMT) Received: by genius.tao.org.uk (Postfix, from userid 1000) id 88FE240D4; Sun, 18 Feb 2007 22:41:58 +0000 (GMT) Date: Sun, 18 Feb 2007 22:41:58 +0000 From: Josef Karthauser To: Kostik Belousov Message-ID: <20070218224158.GA1297@genius.tao.org.uk> References: <20070204023711.GA3393@genius.tao.org.uk> <20070215135750.GR64768@obiwan.tataz.chchile.org> <20070215152259.GA2950@genius.tao.org.uk> <20070215153135.GI39168@deviant.kiev.zoral.com.ua> <20070216125007.D38234@fledge.watson.org> <20070216143656.GM39168@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline In-Reply-To: <20070216143656.GM39168@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.11 Cc: Jeremie Le Hen , hackers@freebsd.org, Robert Watson , fs@freebsd.org Subject: Re: nullfs and named pipes. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2007 22:42:07 -0000 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 16, 2007 at 04:36:56PM +0200, Kostik Belousov wrote: > > >> cvs diff: Diffing . > > >> Index: null_subr.c > > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >> RCS file: /home/ncvs/src/sys/fs/nullfs/null_subr.c,v > > >> retrieving revision 1.48.2.1 > > >> diff -u -r1.48.2.1 null_subr.c > > >> --- null_subr.c 13 Mar 2006 03:05:17 -0000 1.48.2.1 > > >> +++ null_subr.c 14 Feb 2007 00:02:28 -0000 > > >> @@ -235,6 +235,8 @@ > > >> xp->null_vnode =3D vp; > > >> xp->null_lowervp =3D lowervp; > > >> vp->v_type =3D lowervp->v_type; > > >> + if (vp->v_type =3D=3D VSOCK || vp->v_type =3D=3D VFIFO) > > >> + vp->v_un =3D lowervp->v_un; > > > > > >I'm wondering is some reference counting needed there ? > >=20 > > Yes, I find this a bit worrying also, but I don't know enough about how= =20 > > nullfs works to reason about it. What happens when a vnode in the bott= om=20 > > layer has its on-disk reference count drop to zero -- is the vnode in t= he=20 > > top layer invalidated somehow? >=20 > Vnode reclamation from lower layer cannot do anithing for corresponding n= ullfs > vnode, but that vnode has reference from nullfs vnode. > On the other hand, can forced unmount proceed for lower layer ? Does know of any reason why I can't commit this as it is, at least for now. It doesn't appear that it would break anything that works currently, and in its current form it at least fixes named pipe functionality for the kinds of cases that people would want to use it. Joe --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iEYEARECAAYFAkXY1jUACgkQXVIcjOaxUBZ65gCfbG6iHjnQ+UfbJ2y5ElcWtoUY IRsAnRsXqalOHF9kOhR/IjOtwcgudwzB =xWNT -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- From owner-freebsd-fs@FreeBSD.ORG Mon Feb 19 07:54:01 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 36B6B16A400 for ; Mon, 19 Feb 2007 07:54:01 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id AEDCE13C478 for ; Mon, 19 Feb 2007 07:54:00 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (xydilc@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l1J7rrC0012211; Mon, 19 Feb 2007 08:53:58 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l1J7rrFO012210; Mon, 19 Feb 2007 08:53:53 +0100 (CET) (envelope-from olli) Date: Mon, 19 Feb 2007 08:53:53 +0100 (CET) Message-Id: <200702190753.l1J7rrFO012210@lurza.secnetix.de> From: Oliver Fromme To: freebsd-fs@FreeBSD.ORG, adamsch1@yahoo.com In-Reply-To: <401753.71633.qm@web31809.mail.mud.yahoo.com> X-Newsgroups: list.freebsd-fs User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 19 Feb 2007 08:53:59 +0100 (CET) Cc: Subject: Re: Advice on runtime directories ala .snapshot X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-fs@FreeBSD.ORG, adamsch1@yahoo.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 07:54:01 -0000 Shane Adams wrote: > I've been thinking about how I could add a "virtual" directory entry > similar to netapp, namely a .snapshot. Obviously I'd want to do this > at runtime, but I'm having trouble attacking this problem. There's no precedent for such a thing in FreeBSD currently. The closest thing would be the ".snap" directory used for FreeBSD's snapshot feature, or maybe even the historical "lost+found" directory. But both of them are created statically in the file system, and they represent ordinary directory entries without any magic. You will find purely synthetic files and directories only in the synthetic file systems such as procfs or devfs. > I've been looking at the ufs_lookup routines, seems thats the only > place to tackle such a feature? Or possibly inject a .snapshot entry > as the last entry read in a call to ufs_readdir ? It would be easier to give advice if we knew what you're actually trying to implement. Personally, I think it's not a good idea to mix real and synthetic entries within the same file system. Or at least there should be _very_ good reasons for doing so, and very careful consideration of all possible cases. For example, what's supposed to happen in case of a conflict, i.e. if there is already a real entry with the same name (".snapshot") with some contents? > I believe doing a ls -la on a netapp will not return the .snapshot > directory, only explicitly nameing the directory will achieve the > effects you want. That behaviour is configurable. On a NetApp filer you can configure per volume whether the .snapshot directory appears only in the mount point directory, or in every directory below it. In the case of a NetApp it's not a big problem to manage such synthetic directories, because it has full controll over its file system. Clients can only access it remotely (NFS, SMB, ...), so from the clients' viewpoint the whole file system is kind of "synthetic". Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart Any opinions expressed in this message are personal to the author and may not necessarily reflect the opinions of secnetix GmbH & Co KG in any way. FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one?" -- Tom Cargil, C++ Journal From owner-freebsd-fs@FreeBSD.ORG Mon Feb 19 14:01:19 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B526016A402; Mon, 19 Feb 2007 14:01:19 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8189313C4B4; Mon, 19 Feb 2007 14:01:19 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 1F8DE4959D; Mon, 19 Feb 2007 09:01:19 -0500 (EST) Date: Mon, 19 Feb 2007 14:01:19 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Josef Karthauser In-Reply-To: <20070218224158.GA1297@genius.tao.org.uk> Message-ID: <20070219135921.E80197@fledge.watson.org> References: <20070204023711.GA3393@genius.tao.org.uk> <20070215135750.GR64768@obiwan.tataz.chchile.org> <20070215152259.GA2950@genius.tao.org.uk> <20070215153135.GI39168@deviant.kiev.zoral.com.ua> <20070216125007.D38234@fledge.watson.org> <20070216143656.GM39168@deviant.kiev.zoral.com.ua> <20070218224158.GA1297@genius.tao.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: hackers@freebsd.org, Jeremie Le Hen , fs@freebsd.org Subject: Re: nullfs and named pipes. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 14:01:19 -0000 On Sun, 18 Feb 2007, Josef Karthauser wrote: > On Fri, Feb 16, 2007 at 04:36:56PM +0200, Kostik Belousov wrote: >>>>> cvs diff: Diffing . >>>>> Index: null_subr.c >>>>> =================================================================== >>>>> RCS file: /home/ncvs/src/sys/fs/nullfs/null_subr.c,v >>>>> retrieving revision 1.48.2.1 >>>>> diff -u -r1.48.2.1 null_subr.c >>>>> --- null_subr.c 13 Mar 2006 03:05:17 -0000 1.48.2.1 >>>>> +++ null_subr.c 14 Feb 2007 00:02:28 -0000 >>>>> @@ -235,6 +235,8 @@ >>>>> xp->null_vnode = vp; >>>>> xp->null_lowervp = lowervp; >>>>> vp->v_type = lowervp->v_type; >>>>> + if (vp->v_type == VSOCK || vp->v_type == VFIFO) >>>>> + vp->v_un = lowervp->v_un; >>>> >>>> I'm wondering is some reference counting needed there ? >>> >>> Yes, I find this a bit worrying also, but I don't know enough about how >>> nullfs works to reason about it. What happens when a vnode in the bottom >>> layer has its on-disk reference count drop to zero -- is the vnode in the >>> top layer invalidated somehow? >> >> Vnode reclamation from lower layer cannot do anithing for corresponding >> nullfs vnode, but that vnode has reference from nullfs vnode. On the other >> hand, can forced unmount proceed for lower layer ? > > Does know of any reason why I can't commit this as it is, at least for now. > It doesn't appear that it would break anything that works currently, and in > its current form it at least fixes named pipe functionality for the kinds of > cases that people would want to use it. Well, the worry would be that you would be replacing a clean error on failure with an occasional panic, the normal symptom of a race condition. I think I'm alright with the VFIFO case above, but I'm quite uncomfortable with the VSOCK case. In particular, I suspect that if the socket is closed, v_un will be reset in the lower layer, but continue to be a stale pointer in the upper layer, leading to accessing free'd or re-allocated kernel memory resulting in much badness. I've noticed tested this, but you might give it a try and see what happens. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-fs@FreeBSD.ORG Mon Feb 19 14:08:36 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A579316A402; Mon, 19 Feb 2007 14:08:36 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7430013C467; Mon, 19 Feb 2007 14:08:36 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 1C535495AF; Mon, 19 Feb 2007 09:08:36 -0500 (EST) Date: Mon, 19 Feb 2007 14:08:36 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Josef Karthauser In-Reply-To: <20070219135921.E80197@fledge.watson.org> Message-ID: <20070219140721.S80197@fledge.watson.org> References: <20070204023711.GA3393@genius.tao.org.uk> <20070215135750.GR64768@obiwan.tataz.chchile.org> <20070215152259.GA2950@genius.tao.org.uk> <20070215153135.GI39168@deviant.kiev.zoral.com.ua> <20070216125007.D38234@fledge.watson.org> <20070216143656.GM39168@deviant.kiev.zoral.com.ua> <20070218224158.GA1297@genius.tao.org.uk> <20070219135921.E80197@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: hackers@freebsd.org, Jeremie Le Hen , fs@freebsd.org Subject: Re: nullfs and named pipes. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 14:08:36 -0000 On Mon, 19 Feb 2007, Robert Watson wrote: > On Sun, 18 Feb 2007, Josef Karthauser wrote: > > Well, the worry would be that you would be replacing a clean error on > failure with an occasional panic, the normal symptom of a race condition. > > I think I'm alright with the VFIFO case above, but I'm quite uncomfortable > with the VSOCK case. In particular, I suspect that if the socket is closed, > v_un will be reset in the lower layer, but continue to be a stale pointer in > the upper layer, leading to accessing free'd or re-allocated kernel memory > resulting in much badness. I've noticed tested this, but you might give it > a try and see what happens. Bad typing day. Should read "not tested this". In any case, you get the idea: the problem here is a potential coherency issue on contents of v_un between the two file system layers. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-fs@FreeBSD.ORG Mon Feb 19 14:29:11 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D316116A400; Mon, 19 Feb 2007 14:29:11 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9E05213C48E; Mon, 19 Feb 2007 14:29:11 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id CD30A4969A; Mon, 19 Feb 2007 09:29:10 -0500 (EST) Date: Mon, 19 Feb 2007 14:29:10 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Josef Karthauser In-Reply-To: <20070219140721.S80197@fledge.watson.org> Message-ID: <20070219142816.N80197@fledge.watson.org> References: <20070204023711.GA3393@genius.tao.org.uk> <20070215135750.GR64768@obiwan.tataz.chchile.org> <20070215152259.GA2950@genius.tao.org.uk> <20070215153135.GI39168@deviant.kiev.zoral.com.ua> <20070216125007.D38234@fledge.watson.org> <20070216143656.GM39168@deviant.kiev.zoral.com.ua> <20070218224158.GA1297@genius.tao.org.uk> <20070219135921.E80197@fledge.watson.org> <20070219140721.S80197@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: hackers@freebsd.org, Jeremie Le Hen , fs@freebsd.org Subject: Re: nullfs and named pipes. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 14:29:11 -0000 On Mon, 19 Feb 2007, Robert Watson wrote: > On Mon, 19 Feb 2007, Robert Watson wrote: > >> On Sun, 18 Feb 2007, Josef Karthauser wrote: >> >> Well, the worry would be that you would be replacing a clean error on >> failure with an occasional panic, the normal symptom of a race condition. >> >> I think I'm alright with the VFIFO case above, but I'm quite uncomfortable >> with the VSOCK case. In particular, I suspect that if the socket is >> closed, v_un will be reset in the lower layer, but continue to be a stale >> pointer in the upper layer, leading to accessing free'd or re-allocated >> kernel memory resulting in much badness. I've noticed tested this, but you >> might give it a try and see what happens. > > Bad typing day. Should read "not tested this". In any case, you get the > idea: the problem here is a potential coherency issue on contents of v_un > between the two file system layers. For some reason I was thinking of v_fifoinfo as being stable after it is initialized, but in fact, it is not, as it can be free'd later. Also, the layers could become out of sync following a reboot. So in conclusion, I think the fifo part of the patch also suffers from the same problem. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-fs@FreeBSD.ORG Wed Feb 21 02:09:10 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0001C16ADE9 for ; Wed, 21 Feb 2007 02:09:09 +0000 (UTC) (envelope-from chris@sigd.net) Received: from ms05.mailstreet2003.net (ms05.mailstreet2003.net [69.25.50.235]) by mx1.freebsd.org (Postfix) with ESMTP id C418C13C442 for ; Wed, 21 Feb 2007 02:09:09 +0000 (UTC) (envelope-from chris@sigd.net) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Feb 2007 21:09:08 -0500 Message-ID: <6FC9F9894A9F8C49A722CF9F2132FC2204C9DAC7@ms05.mailstreet2003.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DragonFlyBSD new upcoming FS thread-index: AcdVXUZKF1X4OubDSm2zZ/iLmo33Hw== From: "Chris Haulmark" To: Subject: DragonFlyBSD new upcoming FS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 02:09:10 -0000 I managed to stumble onto this which was just posted recently by Matt Dillon which there could be support for a file system that can be accessed by several nodes in a cluster system. This is for DragonFlyBSD for now. http://leaf.dragonflybsd.org/mailarchive/users/2007-02/msg00164.html Thought I'll post here for those who followed my search for a FS to be supported on FreeBSD. I guess I can wait for a bit. Chris From owner-freebsd-fs@FreeBSD.ORG Wed Feb 21 07:38:36 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 662EB16A4FD for ; Wed, 21 Feb 2007 07:38:36 +0000 (UTC) (envelope-from steve@localhost.lu) Received: from linion.ion.lu (linion.ion.lu [80.90.47.168]) by mx1.freebsd.org (Postfix) with ESMTP id B188813C442 for ; Wed, 21 Feb 2007 07:38:35 +0000 (UTC) (envelope-from steve@localhost.lu) Received: (qmail 36632 invoked by uid 89); 21 Feb 2007 08:27:10 +0100 Received: from localhost (HELO webmail-lite.ion.lu) (127.0.0.1) by linion.ion.lu with SMTP; 21 Feb 2007 08:27:10 +0100 Received: from 62.229.116.183 (SquirrelMail authenticated user steve@localhost.lu) by webmail-lite.ion.lu with HTTP; Wed, 21 Feb 2007 08:27:10 +0100 (CET) Message-ID: <43302.62.229.116.183.1172042830.squirrel@webmail-lite.ion.lu> Date: Wed, 21 Feb 2007 08:27:10 +0100 (CET) From: "Steve Clement" To: freebsd-fs@freebsd.org User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: ZFS patches for FreeBSD. Makefile.inc1.rej X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 07:38:36 -0000 Using 6.2-RELEASE, the patches apply fine but Makefile.inc1 get's rejected. The reject is below, could the person that is taking care of the ZFS Patches check if this is true and eventually fix it... sincerely yours, Steve Clement laptop-steve# cat Makefile.inc1.rej *************** *** 40,46 **** .if ${MK_GAMES} != "no" SUBDIR+=games .endif - SUBDIR+=gnu include .if ${MK_KERBEROS} != "no" SUBDIR+=kerberos5 .endif --- 40,46 ---- .if ${MK_GAMES} != "no" SUBDIR+=games .endif + SUBDIR+=cddl gnu include .if ${MK_KERBEROS} != "no" SUBDIR+=kerberos5 .endif *************** *** 998,1004 **** ${_secure_lib_libcrypto} ${_secure_lib_libssh} \ ${_secure_lib_libssl} - _generic_libs= gnu/lib ${_kerberos5_lib} lib ${_secure_lib} usr.bin/lex/lib lib/libopie__L lib/libtacplus__L: lib/libmd__L --- 1000,1006 ---- ${_secure_lib_libcrypto} ${_secure_lib_libssh} \ ${_secure_lib_libssl} + _generic_libs= cddl/lib gnu/lib ${_kerberos5_lib} lib ${_secure_lib} usr.bin/lex/lib lib/libopie__L lib/libtacplus__L: lib/libmd__L -- __o | Steve Clement - Unix System Administrator _ \<,_ | Current Location: Luxembourgr/Europe (_)/ (_) | "Work to Eat, Eat to Live, Live to Bike, Bike to Work" From owner-freebsd-fs@FreeBSD.ORG Wed Feb 21 08:06:16 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 79D5116E0FA for ; Wed, 21 Feb 2007 08:06:16 +0000 (UTC) (envelope-from steve@localhost.lu) Received: from linion.ion.lu (linion.ion.lu [80.90.47.168]) by mx1.freebsd.org (Postfix) with ESMTP id EA91913C474 for ; Wed, 21 Feb 2007 08:06:15 +0000 (UTC) (envelope-from steve@localhost.lu) Received: (qmail 41981 invoked by uid 89); 21 Feb 2007 09:07:00 +0100 Received: from localhost (HELO webmail-lite.ion.lu) (127.0.0.1) by linion.ion.lu with SMTP; 21 Feb 2007 09:07:00 +0100 Received: from 62.229.116.183 (SquirrelMail authenticated user steve@localhost.lu) by webmail-lite.ion.lu with HTTP; Wed, 21 Feb 2007 09:07:00 +0100 (CET) Message-ID: <45551.62.229.116.183.1172045220.squirrel@webmail-lite.ion.lu> Date: Wed, 21 Feb 2007 09:07:00 +0100 (CET) From: "Steve Clement" To: freebsd-fs@freebsd.org User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: ZFS patches for FreeBSD. 6.2-RELEASE Compile Errors X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 08:06:16 -0000 Hi list, thanks for all the good work. hereby an error I receive upon buildworld on 6.2-RELEASE what would that mean? sincerely yours, Steve Clement laptop-steve# cd cddl/ laptop-steve# ls Makefile Makefile.inc Makefile.inc.orig Makefile.orig lib usr.bin usr.sbin laptop-steve# make ===> lib (all) ===> lib/libavl (all) cc -O2 -fno-strict-aliasing -pipe -I/usr/src/cddl/lib/libavl/../../../sys/compat/opensolaris -I/usr/src/cddl/lib/libavl/../../../sys/contrib/opensolaris/uts/common -D_SOLARIS_C_SOURCE -c /usr/src/cddl/lib/libavl/../../../contrib/opensolaris/common/avl/avl.c In file included from /usr/src/cddl/lib/libavl/../../../contrib/opensolaris/common/avl/avl.c:93: /usr/src/cddl/lib/libavl/../../../sys/compat/opensolaris/sys/types.h:27: error: syntax error before "offset_t" /usr/src/cddl/lib/libavl/../../../sys/compat/opensolaris/sys/types.h:27: warning: data definition has no type or storage class /usr/src/cddl/lib/libavl/../../../sys/compat/opensolaris/sys/types.h:28: error: syntax error before "u_offset_t" /usr/src/cddl/lib/libavl/../../../sys/compat/opensolaris/sys/types.h:28: warning: data definition has no type or storage class /usr/src/cddl/lib/libavl/../../../sys/compat/opensolaris/sys/types.h:34: error: syntax error before "diskaddr_t" /usr/src/cddl/lib/libavl/../../../sys/compat/opensolaris/sys/types.h:34: warning: data definition has no type or storage class /usr/src/cddl/lib/libavl/../../../sys/compat/opensolaris/sys/types.h:35: error: syntax error before "o_mode_t" /usr/src/cddl/lib/libavl/../../../sys/compat/opensolaris/sys/types.h:35: warning: data definition has no type or storage class In file included from /usr/src/cddl/lib/libavl/../../../sys/contrib/opensolaris/uts/common/sys/avl.h:41, from /usr/src/cddl/lib/libavl/../../../contrib/opensolaris/common/avl/avl.c:96: /usr/src/cddl/lib/libavl/../../../sys/contrib/opensolaris/uts/common/sys/avl_impl.h:150: error: syntax error before "ulong_t" In file included from /usr/src/cddl/lib/libavl/../../../contrib/opensolaris/common/avl/avl.c:96: /usr/src/cddl/lib/libavl/../../../sys/contrib/opensolaris/uts/common/sys/avl.h:258: error: syntax error before "avl_numnodes" /usr/src/cddl/lib/libavl/../../../sys/contrib/opensolaris/uts/common/sys/avl.h:258: warning: data definition has no type or storage class /usr/src/cddl/lib/libavl/../../../contrib/opensolaris/common/avl/avl.c: In function `avl_insert': /usr/src/cddl/lib/libavl/../../../contrib/opensolaris/common/avl/avl.c:492: error: structure has no member named `avl_numnodes' /usr/src/cddl/lib/libavl/../../../contrib/opensolaris/common/avl/avl.c: In function `avl_remove': /usr/src/cddl/lib/libavl/../../../contrib/opensolaris/common/avl/avl.c:747: error: structure has no member named `avl_numnodes' /usr/src/cddl/lib/libavl/../../../contrib/opensolaris/common/avl/avl.c: In function `avl_create': /usr/src/cddl/lib/libavl/../../../contrib/opensolaris/common/avl/avl.c:828: error: structure has no member named `avl_numnodes' /usr/src/cddl/lib/libavl/../../../contrib/opensolaris/common/avl/avl.c: At top level: /usr/src/cddl/lib/libavl/../../../contrib/opensolaris/common/avl/avl.c:850: error: syntax error before "avl_numnodes" /usr/src/cddl/lib/libavl/../../../contrib/opensolaris/common/avl/avl.c: In function `avl_numnodes': /usr/src/cddl/lib/libavl/../../../contrib/opensolaris/common/avl/avl.c:853: error: structure has no member named `avl_numnodes' /usr/src/cddl/lib/libavl/../../../contrib/opensolaris/common/avl/avl.c: In function `avl_destroy_nodes': /usr/src/cddl/lib/libavl/../../../contrib/opensolaris/common/avl/avl.c:914: error: structure has no member named `avl_numnodes' /usr/src/cddl/lib/libavl/../../../contrib/opensolaris/common/avl/avl.c:925: error: structure has no member named `avl_numnodes' *** Error code 1 Stop in /usr/src/cddl/lib/libavl. *** Error code 1 Stop in /usr/src/cddl/lib. *** Error code 1 Stop in /usr/src/cddl. -- __o | Steve Clement - Unix System Administrator _ \<,_ | Current Location: Luxembourgr/Europe (_)/ (_) | "Work to Eat, Eat to Live, Live to Bike, Bike to Work" From owner-freebsd-fs@FreeBSD.ORG Wed Feb 21 10:24:27 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B16BC16E9A8 for ; Wed, 21 Feb 2007 10:24:27 +0000 (UTC) (envelope-from bsdportal@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.232]) by mx1.freebsd.org (Postfix) with ESMTP id 6007F13C471 for ; Wed, 21 Feb 2007 10:24:27 +0000 (UTC) (envelope-from bsdportal@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so2540381wxc for ; Wed, 21 Feb 2007 02:24:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=st/5Xc6JdQPTTp1j/yd+RXbzwZE6jn2f9kJnyZhlTVswz+MwuSzAmECpLkeeba1l4TxryNUFXu1zA9c1L+LBH+k9HDahD8vFTY3fC99+2i5E39gauhNp0qVJ5T1e19ri2OeP7oDglv7JIAK5ogmO1Fclc1DpsDqXoJgKckHE8y0= Received: by 10.114.80.4 with SMTP id d4mr3710572wab.1172051730277; Wed, 21 Feb 2007 01:55:30 -0800 (PST) Received: by 10.115.17.8 with HTTP; Wed, 21 Feb 2007 01:55:30 -0800 (PST) Message-ID: <4d3557900702210155n2f57761fl6b8b4df500a1cf77@mail.gmail.com> Date: Wed, 21 Feb 2007 12:55:30 +0300 From: "Alexey Karakuts" Sender: bsdportal@gmail.com To: freebsd-fs@freebsd.org MIME-Version: 1.0 X-Google-Sender-Auth: aa1222270964a61e Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: The patch delete no umount eject flash disk freebsd panic X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 10:24:27 -0000 #The patch delete flash disk freebsd panic #Any questions send email sys@bsdportal.ru Alexey N. Karakuts --- /sys/geom/geom_vfs.c Mon Mar 13 03:05:29 2006 +++ geom_vfs.c Wed Dec 6 19:42:46 2006 @@ -70,16 +70,9 @@ struct buf *bp; int vfslocked; - if (bip->bio_error) { - printf("g_vfs_done():"); - g_print_bio(bip); - printf("error = %d\n", bip->bio_error); - } bp = bip->bio_caller2; bp->b_error = bip->bio_error; bp->b_ioflags = bip->bio_flags; - if (bip->bio_error) - bp->b_ioflags |= BIO_ERROR; bp->b_resid = bp->b_bcount - bip->bio_completed; g_destroy_bio(bip); vfslocked = VFS_LOCK_GIANT(((struct mount *)NULL)); -- __________________________________________ Administrator BSDPORTAL.RU Alexey N. Karakuts From owner-freebsd-fs@FreeBSD.ORG Wed Feb 21 13:15:30 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B1FBF16F112 for ; Wed, 21 Feb 2007 13:15:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7D9D413C47E for ; Wed, 21 Feb 2007 13:15:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 6D16148859; Wed, 21 Feb 2007 08:15:29 -0500 (EST) Date: Wed, 21 Feb 2007 13:15:29 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: freebsd-fs@freebsd.org In-Reply-To: <20070215002206.G16383@fledge.watson.org> Message-ID: <20070221131330.S80197@fledge.watson.org> References: <20070213075627.63126.qmail@web34502.mail.mud.yahoo.com> <6FC9F9894A9F8C49A722CF9F2132FC2204C9DAB4@ms05.mailstreet2003.net> <6FC9F9894A9F8C49A722CF9F2132FC2204C9DAB5@ms05.mailstreet2003.net> <6FC9F9894A9F8C49A722CF9F2132FC2204C9DAB6@ms05.mailstreet2003.net> <45D1F30A.6080403@freebsd.org> <20070213192906.U726@chrishome.localnet> <20070214162938.GA96725@keira.kiwi-computer.com> <20070214173211.L1054@chrishome.localnet> <20070214170808.GC96725@keira.kiwi-computer.com> <20070215002206.G16383@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Rick C. Petty" , arla-drinkers@stacken.kth.se, Tomas Olsson Subject: Re: UFS2 with SAN X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 13:15:30 -0000 On Thu, 15 Feb 2007, Robert Watson wrote: >> I'm already funded and can work full time on this, but a FreeBSD hacker >> would help a lot. Any volunteers? > > I'm not the right person to talk to you about FreeBSD VFS/buffering, but I'm > very interested in seeing support for Arla improve for recent FreeBSD > versions. In particular, I think it would be very helpful it it worked on > FreeBSD 7-CURRENT, which would facilitate merging nnpfs into CVS. This > might help solve the "forever playing catchup" problem that Arla seems > constantly to experience with FreeBSD, in which nnpfs (previously xfs) gets > left behind and works only on stale FreeBSD versions. In any recent FreeBSD > kernel, nnpfs will need to run as an MPSAFE file system, however. FYI to all as a follow-up on this thread: I've set Tomas up with an account on the FreeBSD Perforce server as a place to do the work-in-progress, which should improve exposure in (and opportunity for collaboration with) the FreeBSD developer community, as well as making it easier to track the 7-CURRENT mainline. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-fs@FreeBSD.ORG Wed Feb 21 14:40:04 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 642DB16DF1F for ; Wed, 21 Feb 2007 14:40:04 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 334ED13C4B2 for ; Wed, 21 Feb 2007 14:40:04 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l1LEduBk095562; Wed, 21 Feb 2007 08:39:56 -0600 (CST) (envelope-from anderson@freebsd.org) Message-ID: <45DC59C0.8080206@freebsd.org> Date: Wed, 21 Feb 2007 08:40:00 -0600 From: Eric Anderson User-Agent: Thunderbird 1.5.0.9 (X11/20070204) MIME-Version: 1.0 To: Alexey Karakuts References: <4d3557900702210155n2f57761fl6b8b4df500a1cf77@mail.gmail.com> In-Reply-To: <4d3557900702210155n2f57761fl6b8b4df500a1cf77@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/2617/Wed Feb 21 05:38:25 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=8.0 tests=BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-fs@freebsd.org Subject: Re: The patch delete no umount eject flash disk freebsd panic X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 14:40:04 -0000 On 02/21/07 03:55, Alexey Karakuts wrote: > #The patch delete flash disk freebsd panic > #Any questions send email sys@bsdportal.ru Alexey N. Karakuts > --- /sys/geom/geom_vfs.c Mon Mar 13 03:05:29 2006 > +++ geom_vfs.c Wed Dec 6 19:42:46 2006 > @@ -70,16 +70,9 @@ > struct buf *bp; > int vfslocked; > > - if (bip->bio_error) { > - printf("g_vfs_done():"); > - g_print_bio(bip); > - printf("error = %d\n", bip->bio_error); > - } > bp = bip->bio_caller2; > bp->b_error = bip->bio_error; > bp->b_ioflags = bip->bio_flags; > - if (bip->bio_error) > - bp->b_ioflags |= BIO_ERROR; > bp->b_resid = bp->b_bcount - bip->bio_completed; > g_destroy_bio(bip); > vfslocked = VFS_LOCK_GIANT(((struct mount *)NULL)); > So what happens when you have a regular drive fail then? Or yank a SATA or other drive out from under the OS? This patch seems awfully dangerous to me.. Eric From owner-freebsd-fs@FreeBSD.ORG Thu Feb 22 08:59:12 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E551B16A403; Thu, 22 Feb 2007 08:59:12 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp1.yandex.ru (smtp1.yandex.ru [213.180.223.87]) by mx1.freebsd.org (Postfix) with ESMTP id E520413C428; Thu, 22 Feb 2007 08:59:11 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mail.kirov.so-cdu.ru ([87.226.153.33]:48652 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S2077324AbXBVIsb (ORCPT + 1 other); Thu, 22 Feb 2007 11:48:31 +0300 X-Comment: RFC 2476 MSA function at smtp1.yandex.ru logged sender identity as: bu7cher Message-ID: <45DD58DD.6030800@yandex.ru> Date: Thu, 22 Feb 2007 11:48:29 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: gjournal/geom_journal man page request X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 08:59:13 -0000 Hi, Pawel and All, Can somebody write a small manual about using gjournal? Or point me to documentation/explanation if it's already exist? Thanks! -- WBR, Andrey V. Elsukov From owner-freebsd-fs@FreeBSD.ORG Thu Feb 22 10:04:17 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 985CC16A402 for ; Thu, 22 Feb 2007 10:04:17 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from chipmunk.ai.net (axe.ai.net [205.134.161.26]) by mx1.freebsd.org (Postfix) with ESMTP id 4614113C48E for ; Thu, 22 Feb 2007 10:04:17 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from localhost (net-ix.gw.ai.net [205.134.160.6]) by chipmunk.ai.net (8.13.4/8.13.4) with SMTP id l1MA4IZa087201; Thu, 22 Feb 2007 05:04:18 -0500 (EST) (envelope-from trhodes@FreeBSD.org) Date: Thu, 22 Feb 2007 05:04:09 -0500 From: Tom Rhodes To: "Andrey V. Elsukov" Message-Id: <20070222050409.4c5596a9.trhodes@FreeBSD.org> In-Reply-To: <45DD58DD.6030800@yandex.ru> References: <45DD58DD.6030800@yandex.ru> Organization: The FreeBSD Project X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: gjournal/geom_journal man page request X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 10:04:17 -0000 On Thu, 22 Feb 2007 11:48:29 +0300 "Andrey V. Elsukov" wrote: > Hi, Pawel and All, Hi, > > Can somebody write a small manual about using gjournal? > Or point me to documentation/explanation if it's already exist? > Thanks! A gjournal(8) manual page was recently committed to CURRENT, please let us know if it does not help you out. Thanks, -- Tom Rhodes From owner-freebsd-fs@FreeBSD.ORG Thu Feb 22 15:12:29 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C5B5816A405; Thu, 22 Feb 2007 15:12:29 +0000 (UTC) (envelope-from bjoern.koenig@alpha-tierchen.de) Received: from mail.liberty-hosting.de (mail.liberty-hosting.de [195.225.132.203]) by mx1.freebsd.org (Postfix) with ESMTP id 86B3B13C48D; Thu, 22 Feb 2007 15:12:29 +0000 (UTC) (envelope-from bjoern.koenig@alpha-tierchen.de) Received: from mail.liberty-hosting.de ([195.225.132.203]) by localhost (liberty-mail [195.225.132.203]) (amavisd-new, port 10024) with ESMTP id 67049-10; Thu, 22 Feb 2007 15:53:27 +0100 (CET) Received: from alpha-tierchen.de (port-212-202-170-218.dynamic.qsc.de [212.202.170.218]) by mail.liberty-hosting.de (Postfix) with ESMTP id D11AD180F4E; Thu, 22 Feb 2007 15:53:26 +0100 (CET) Received: from [192.168.1.2] (muhkuh.lan [192.168.1.2]) by alpha-tierchen.de (Postfix) with ESMTP id A083450907; Thu, 22 Feb 2007 15:53:24 +0100 (CET) Message-ID: <45DDAE70.8010508@alpha-tierchen.de> Date: Thu, 22 Feb 2007 15:53:36 +0100 From: =?ISO-8859-1?Q?Bj=F6rn_K=F6nig?= User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Eric Anderson References: <4d3557900702210155n2f57761fl6b8b4df500a1cf77@mail.gmail.com> <45DC59C0.8080206@freebsd.org> In-Reply-To: <45DC59C0.8080206@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at mail.smartterra.de Cc: freebsd-fs@freebsd.org Subject: Re: The patch delete no umount eject flash disk freebsd panic X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 15:12:29 -0000 Eric Anderson schrieb: > So what happens when you have a regular drive fail then? Or yank a SATA > or other drive out from under the OS? > > This patch seems awfully dangerous to me.. I don't want to disagree. This is dangerous. Seriously, I have another thought: is it less dangerous to risk data loss or corruption of other file systems that are not affected just because we killed the whole system immediately? I had this problem several times: device removed and access to one of its file systems causes the death of the machine. For example: - insert a disk into floppy disk drive - mount its file system - remove floppy disk (oops!) - insert it again (quickly, before anything notice) - umount the file system => kernel panic The result is that other well running file systems on this machine became corrupt or inconsistent. This issue definitively needs a solution. I understand if you don't want to ignore and override the disappearance of a file system, but in this case we probably either need a kind of "soft panic" that tries to unmount other file systems before death blow, a safe way to force unmounting a broken file system without kernel panic explicitely or a configurable case differentiation. Regards Björn From owner-freebsd-fs@FreeBSD.ORG Thu Feb 22 15:39:51 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6C3A316A400 for ; Thu, 22 Feb 2007 15:39:51 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3BF4813C474 for ; Thu, 22 Feb 2007 15:39:51 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l1MFcf8f072490; Thu, 22 Feb 2007 09:38:42 -0600 (CST) (envelope-from anderson@freebsd.org) Message-ID: <45DDB906.1070405@freebsd.org> Date: Thu, 22 Feb 2007 09:38:46 -0600 From: Eric Anderson User-Agent: Thunderbird 1.5.0.9 (X11/20070204) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bj=F6rn_K=F6nig?= References: <4d3557900702210155n2f57761fl6b8b4df500a1cf77@mail.gmail.com> <45DC59C0.8080206@freebsd.org> <45DDAE70.8010508@alpha-tierchen.de> In-Reply-To: <45DDAE70.8010508@alpha-tierchen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.88.4/2628/Thu Feb 22 05:31:25 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=8.0 tests=BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-fs@freebsd.org Subject: Re: The patch delete no umount eject flash disk freebsd panic X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 15:39:51 -0000 On 02/22/07 08:53, Björn König wrote: > Eric Anderson schrieb: > >> So what happens when you have a regular drive fail then? Or yank a SATA >> or other drive out from under the OS? >> >> This patch seems awfully dangerous to me.. > > I don't want to disagree. This is dangerous. Seriously, I have another > thought: is it less dangerous to risk data loss or corruption of other > file systems that are not affected just because we killed the whole > system immediately? > > I had this problem several times: device removed and access to one of > its file systems causes the death of the machine. For example: > > - insert a disk into floppy disk drive > - mount its file system > - remove floppy disk (oops!) > - insert it again (quickly, before anything notice) > - umount the file system > => kernel panic > > The result is that other well running file systems on this machine > became corrupt or inconsistent. This issue definitively needs a > solution. I understand if you don't want to ignore and override the > disappearance of a file system, but in this case we probably either need > a kind of "soft panic" that tries to unmount other file systems before > death blow, a safe way to force unmounting a broken file system without > kernel panic explicitely or a configurable case differentiation. I agree that other file systems should not be messed with. I suppose instead of panicking another option is the remove the mount point, blast anything in cache for it, and then kill any processes touching it? How would one deal with daemons like mountd, and nfsd though? This would be a good thing for servers too, since a missing file system would hopefully not kill everything. Maybe someone with more locking/file system/geom knowledge could provide some input here.. Eric From owner-freebsd-fs@FreeBSD.ORG Thu Feb 22 15:40:00 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A580216A402; Thu, 22 Feb 2007 15:40:00 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id 1356613C4A3; Thu, 22 Feb 2007 15:39:59 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (shkjof@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l1MFd0xe075916; Thu, 22 Feb 2007 16:39:05 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l1MFd0Vr075915; Thu, 22 Feb 2007 16:39:00 +0100 (CET) (envelope-from olli) Date: Thu, 22 Feb 2007 16:39:00 +0100 (CET) Message-Id: <200702221539.l1MFd0Vr075915@lurza.secnetix.de> From: Oliver Fromme To: freebsd-fs@FreeBSD.ORG, bjoern.koenig@alpha-tierchen.de, anderson@FreeBSD.ORG In-Reply-To: <45DDAE70.8010508@alpha-tierchen.de> X-Newsgroups: list.freebsd-fs User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 22 Feb 2007 16:39:05 +0100 (CET) Cc: Subject: Re: The patch delete no umount eject flash disk freebsd panic X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-fs@FreeBSD.ORG, bjoern.koenig@alpha-tierchen.de, anderson@FreeBSD.ORG List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 15:40:00 -0000 Recently I had an idea to solve (or work around) the problem in a completely different way, using FUSE. With FUSE it would be possible (and quite simple, in fact) to implement an msdosfs-like file system as a userland daemon. The daemon could be started during boot and run until shutdown, i.e. the mount would exist all the time. You could insert and remove USB sticks, compact flash cards and other removable FAT media at will, without having to mount or umount. If you remove the device, the files would simply disappear from the mountpoint. Any files still open by processes would have to return some sensible error code (maybe EBADF or ESTALE). The actual code for the daemon could be borrowed from the kernel's msdosfs, or from mtools (ports/emulators/mtools). Unfortunately I don't have sufficient time right now for doing it myself. But if someone picks up that idea and implements it, it would be quite useful. Using FUSE isn't difficult, bascially you have to link against the library and implement handlers for a number of file system related functions (lookup, read, write etc.). Since it runs entirely in userland, there's no danger of kernel panics, and debugging is quite simple. Maybe something for the FreeBSD ideas web page ...? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart Any opinions expressed in this message are personal to the author and may not necessarily reflect the opinions of secnetix GmbH & Co KG in any way. FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Being really good at C++ is like being really good at using rocks to sharpen sticks." -- Thant Tessman From owner-freebsd-fs@FreeBSD.ORG Thu Feb 22 17:23:53 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4291A16A401 for ; Thu, 22 Feb 2007 17:23:53 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 1898613C49D for ; Thu, 22 Feb 2007 17:23:52 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l1MHMfX8091770; Thu, 22 Feb 2007 11:22:41 -0600 (CST) (envelope-from anderson@freebsd.org) Message-ID: <45DDD166.4060606@freebsd.org> Date: Thu, 22 Feb 2007 11:22:46 -0600 From: Eric Anderson User-Agent: Thunderbird 1.5.0.9 (X11/20070204) MIME-Version: 1.0 To: freebsd-fs@freebsd.org, bjoern.koenig@alpha-tierchen.de References: <200702221539.l1MFd0Vr075915@lurza.secnetix.de> In-Reply-To: <200702221539.l1MFd0Vr075915@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/2628/Thu Feb 22 05:31:25 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: Subject: Re: The patch delete no umount eject flash disk freebsd panic X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 17:23:53 -0000 On 02/22/07 09:39, Oliver Fromme wrote: > Recently I had an idea to solve (or work around) the problem > in a completely different way, using FUSE. > > With FUSE it would be possible (and quite simple, in fact) > to implement an msdosfs-like file system as a userland > daemon. The daemon could be started during boot and run > until shutdown, i.e. the mount would exist all the time. > You could insert and remove USB sticks, compact flash cards > and other removable FAT media at will, without having to > mount or umount. If you remove the device, the files would > simply disappear from the mountpoint. Any files still open > by processes would have to return some sensible error code > (maybe EBADF or ESTALE). > > The actual code for the daemon could be borrowed from the > kernel's msdosfs, or from mtools (ports/emulators/mtools). > > Unfortunately I don't have sufficient time right now for > doing it myself. But if someone picks up that idea and > implements it, it would be quite useful. Using FUSE isn't > difficult, bascially you have to link against the library > and implement handlers for a number of file system related > functions (lookup, read, write etc.). Since it runs > entirely in userland, there's no danger of kernel panics, > and debugging is quite simple. > > Maybe something for the FreeBSD ideas web page ...? > > Best regards > Oliver > Honestly, I think the OS should do this, not an external userland tool. Having a FUSE module handle this, to me, is a bandaid for the right solution. I'm not claiming I know the solution yet, but I know it should be a built-in. Eric From owner-freebsd-fs@FreeBSD.ORG Thu Feb 22 19:12:27 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4463316A403 for ; Thu, 22 Feb 2007 19:12:27 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (keira.kiwi-computer.com [63.224.10.3]) by mx1.freebsd.org (Postfix) with SMTP id CB5CC13C4A3 for ; Thu, 22 Feb 2007 19:12:26 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 68152 invoked by uid 2001); 22 Feb 2007 19:12:22 -0000 Date: Thu, 22 Feb 2007 13:12:22 -0600 From: "Rick C. Petty" To: freebsd-fs@FreeBSD.ORG Message-ID: <20070222191222.GA65105@keira.kiwi-computer.com> References: <45DDAE70.8010508@alpha-tierchen.de> <200702221539.l1MFd0Vr075915@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200702221539.l1MFd0Vr075915@lurza.secnetix.de> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: The patch delete no umount eject flash disk freebsd panic X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 19:12:27 -0000 On Thu, Feb 22, 2007 at 04:39:00PM +0100, Oliver Fromme wrote: > Recently I had an idea to solve (or work around) the problem > in a completely different way, using FUSE. FUSE has other issues tho, in particular: security. It doesn't implement a good security model; the use who mounts gets treated like root, AFAIK. Which is fine for things like FAT32, but not so fine for NTFS, UFS, AFS, or anything with a decent ACL model. -- Rick C. Petty From owner-freebsd-fs@FreeBSD.ORG Thu Feb 22 19:30:13 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 74FB516A405 for ; Thu, 22 Feb 2007 19:30:13 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 0FE4B13C491 for ; Thu, 22 Feb 2007 19:30:12 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 8948A487F5; Thu, 22 Feb 2007 20:30:10 +0100 (CET) Received: from localhost (public-gprs36513.centertel.pl [91.94.14.191]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id BBD6845683; Thu, 22 Feb 2007 20:29:36 +0100 (CET) Date: Thu, 22 Feb 2007 20:27:02 +0100 From: Pawel Jakub Dawidek To: "Andrey V. Elsukov" Message-ID: <20070222192702.GA1244@garage.freebsd.pl> References: <45DD58DD.6030800@yandex.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline In-Reply-To: <45DD58DD.6030800@yandex.ru> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: gjournal/geom_journal man page request X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 19:30:13 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 22, 2007 at 11:48:29AM +0300, Andrey V. Elsukov wrote: > Hi, Pawel and All, >=20 > Can somebody write a small manual about using gjournal? > Or point me to documentation/explanation if it's already exist? gjournal manual page was committed some time ago. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF3e6GForvXbEpPzQRAtMZAJ9KrCdKib9DyXVtJKhSQ31K/wGAYwCfaPfs 9rZnM/mTxue5GbbSPHJVP8Q= =cPBF -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From owner-freebsd-fs@FreeBSD.ORG Thu Feb 22 19:36:06 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4730D16A401; Thu, 22 Feb 2007 19:36:06 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id AA11313C481; Thu, 22 Feb 2007 19:36:05 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (wnetwv@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l1MJZ2n7004737; Thu, 22 Feb 2007 20:35:08 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l1MJYwLC004725; Thu, 22 Feb 2007 20:34:58 +0100 (CET) (envelope-from olli) Date: Thu, 22 Feb 2007 20:34:58 +0100 (CET) Message-Id: <200702221934.l1MJYwLC004725@lurza.secnetix.de> From: Oliver Fromme To: freebsd-fs@FreeBSD.ORG, anderson@FreeBSD.ORG, rick-freebsd@kiwi-computer.com, bjoern.koenig@alpha-tierchen.de In-Reply-To: <45DDD166.4060606@freebsd.org> X-Newsgroups: list.freebsd-fs User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 22 Feb 2007 20:35:08 +0100 (CET) Cc: Subject: Re: The patch delete no umount eject flash disk freebsd panic X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-fs@FreeBSD.ORG, anderson@FreeBSD.ORG, rick-freebsd@kiwi-computer.com, bjoern.koenig@alpha-tierchen.de List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 19:36:06 -0000 Eric Anderson wrote: > Honestly, I think the OS should do this, not an external userland tool. > Having a FUSE module handle this, to me, is a bandaid for the right > solution. I'm not claiming I know the solution yet, but I know it > should be a built-in. I agree completely, that's why I wrote "work around". It wouldn't be a real solution. The real solution would be of course, to fix the kernel so it doesn't panic in cases like that. However, the problem exists for as long as FreeBSD exists, and has been discussed a lot of times. It became clear that it is not easy to fix at all, and I don't expect to see a solution in the kernel in the non-distant future. That's why I suggested a rather simple work around that would allow users to keep the damn thing mounted all the time and not have to care about mount and umount at all. It would probably be just a weekend of coding. In reply to Rick's mail regarding security: If you allow ordinary users to mount file systems (via vfs.usermount or via sudo/super), you can run into security problems, but it doesn't matter whether you use FUSE or not. In either case the admin has to think carefully about the possible implications. If you restrict user mounts to mount points owned by the user and enforce nosuid (the default), then it isn't that bad from a security point of view. Apart from that, the proposed solution was intended to be used on personal machines (e.g. laptops) where there is usually only one user anyway. For example, I certainly wouldn't mind using such a FUSE mount on my own notebook. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart Any opinions expressed in this message are personal to the author and may not necessarily reflect the opinions of secnetix GmbH & Co KG in any way. FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C++: "an octopus made by nailing extra legs onto a dog" -- Steve Taylor, 1998 From owner-freebsd-fs@FreeBSD.ORG Thu Feb 22 21:26:58 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A56E416A401 for ; Thu, 22 Feb 2007 21:26:58 +0000 (UTC) (envelope-from adamsch1@yahoo.com) Received: from web31815.mail.mud.yahoo.com (web31815.mail.mud.yahoo.com [68.142.206.168]) by mx1.freebsd.org (Postfix) with SMTP id 3389513C4AA for ; Thu, 22 Feb 2007 21:26:58 +0000 (UTC) (envelope-from adamsch1@yahoo.com) Received: (qmail 23197 invoked by uid 60001); 22 Feb 2007 21:26:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=adI4+k9cwak3G67mGTPZjE9aasuZjqtnMa4+cPT8xTMI3WgChV7veFeEHyx35pcb648H0tH/vNdmb2C8n3KzfOCosk6nejzAn6CBeokuLiKGRGXCHqB85Lnjk8e18NexJEQm2AVtKKlTy9SNF6eZ9g/r7+ZbiGJ7WgzB1apWGe8=; X-YMail-OSG: _NwgotMVM1lmNYWy_J6F6gT5tC_uV4BCAFxiZwKFFQDdLawSKQxqdubfqwfNXOQxjmLEKaw6Ary_e.tBww8wcz9qMstoOsb4rn_3eAQPGNk4crZibn3ajU0AVtPkczV1F9Ky2WRGXtw18CE- Received: from [216.145.54.158] by web31815.mail.mud.yahoo.com via HTTP; Thu, 22 Feb 2007 13:26:57 PST X-Mailer: YahooMailRC/468 YahooMailWebService/0.6.132.8 Date: Thu, 22 Feb 2007 13:26:57 -0800 (PST) From: Shane Adams To: freebsd-fs@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <320631.20440.qm@web31815.mail.mud.yahoo.com> Cc: Subject: Re: Advice on runtime directories ala .snapshot X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 21:26:58 -0000 Sorry I wasn't clear earlier. I'd like to emulate how netapp drops a .snap= shot directory in any subdirectory of a snapshotted filesystem.=0A=0AIt see= med natural to do this dynamically on a per-request basis. =0A=0AAfter rea= ding your response I happened upon nullfs, and I'm now thinking that would = be the right area to look at? At *least* for simplicity?=0A=0AScrewing aro= und on a netapp I found all .snapshot directory entries had the same ino, w= hile subdirectories, like nightly_0, nightly_1 etc. had seemingly unique in= o's, which would indicate to me they are persisting them somehow, or not, a= nd they cache them as long as possible/necessary.=0A=0AShane=0A=0A----- Ori= ginal Message ----=0AFrom: Oliver Fromme =0ATo: fre= ebsd-fs@FreeBSD.ORG; adamsch1@yahoo.com=0ASent: Sunday, February 18, 2007 1= 1:53:53 PM=0ASubject: Re: Advice on runtime directories ala .snapshot=0A=0A= Shane Adams wrote:=0A > I've been thinking about how I could add a "virtual= " directory entry=0A > similar to netapp, namely a .snapshot. Obviously I'= d want to do this=0A > at runtime, but I'm having trouble attacking this pr= oblem.=0A=0AThere's no precedent for such a thing in FreeBSD currently.=0AT= he closest thing would be the ".snap" directory used for=0AFreeBSD's snapsh= ot feature, or maybe even the historical=0A"lost+found" directory. But bot= h of them are created=0Astatically in the file system, and they represent o= rdinary=0Adirectory entries without any magic.=0A=0AYou will find purely sy= nthetic files and directories only=0Ain the synthetic file systems such as = procfs or devfs.=0A=0A > I've been looking at the ufs_lookup routines, seem= s thats the only=0A > place to tackle such a feature? Or possibly inject a= .snapshot entry=0A > as the last entry read in a call to ufs_readdir ?=0A= =0AIt would be easier to give advice if we knew what you're=0Aactually tryi= ng to implement. Personally, I think it's not=0Aa good idea to mix real an= d synthetic entries within the=0Asame file system. Or at least there shoul= d be _very_ good=0Areasons for doing so, and very careful consideration of = all=0Apossible cases. For example, what's supposed to happen in=0Acase of = a conflict, i.e. if there is already a real entry=0Awith the same name (".s= napshot") with some contents?=0A=0A > I believe doing a ls -la on a netapp = will not return the .snapshot=0A > directory, only explicitly nameing the d= irectory will achieve the=0A > effects you want.=0A=0AThat behaviour is con= figurable. On a NetApp filer you can=0Aconfigure per volume whether the .s= napshot directory=0Aappears only in the mount point directory, or in every= =0Adirectory below it. In the case of a NetApp it's not a big=0Aproblem to= manage such synthetic directories, because it=0Ahas full controll over its= file system. Clients can only=0Aaccess it remotely (NFS, SMB, ...), so fr= om the clients'=0Aviewpoint the whole file system is kind of "synthetic".= =0A=0ABest regards=0A Oliver=0A=0A-- =0AOliver Fromme, secnetix GmbH & Co= . KG, Marktplatz 29, 85567 Grafing b. M.=0AHandelsregister: Registergericht= Muenchen, HRA 74606, Gesch=E4ftsfuehrung:=0Asecnetix Verwaltungsgesellsch= . mbH, Handelsregister: Registergericht M=FCn-=0Achen, HRB 125758, Gesch= =E4ftsf=FChrer: Maik Bachmann, Olaf Erb, Ralf Gebhart=0AAny opinions expres= sed in this message are personal to the author and may=0Anot necessarily re= flect the opinions of secnetix GmbH & Co KG in any way.=0AFreeBSD-Dienstlei= stungen, -Produkte und mehr: http://www.secnetix.de/bsd=0A=0A"If you think= C++ is not overly complicated, just what is a protected=0Aabstract virtual= base pure virtual private destructor, and when was the=0Alast time you nee= ded one?"=0A -- Tom Cargil, C++ Journal=0A=0A=0A From owner-freebsd-fs@FreeBSD.ORG Thu Feb 22 22:11:50 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1BF2316A402; Thu, 22 Feb 2007 22:11:50 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5DF0E13C4A3; Thu, 22 Feb 2007 22:11:49 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l1MMBmYl045306; Thu, 22 Feb 2007 16:11:48 -0600 (CST) (envelope-from anderson@freebsd.org) Message-ID: <45DE1528.8020902@freebsd.org> Date: Thu, 22 Feb 2007 16:11:52 -0600 From: Eric Anderson User-Agent: Thunderbird 1.5.0.9 (X11/20070204) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <45D69918.3000008@freebsd.org> <20070217210322.GB64936@garage.freebsd.pl> In-Reply-To: <20070217210322.GB64936@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/2630/Thu Feb 22 13:12:40 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: "freebsd-fs@freebsd.org" Subject: Re: question about vfs_lookup X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 22:11:50 -0000 On 02/17/07 15:03, Pawel Jakub Dawidek wrote: > On Fri, Feb 16, 2007 at 11:56:40PM -0600, Eric Anderson wrote: >> I'm just curious about how this block (starting at line 712) could possibly ever get executed, since right before it there is a condition that would cause a panic. >> >> Can anyone explain this please? > > You read KASSERT(9) in a wrong way. The condition used in assertion says > "don't panic if the condition is true". Here we panic when flag ISLASTCN > is not set and *ndp->ni_next is not equal to '/'. That makes a lot more sense now.. Thanks :) Eric >> In sys/kern/vfs_lookup.c: >> 710 KASSERT((cnp->cn_flags & ISLASTCN) || *ndp->ni_next == '/', >> 711 ("lookup: invalid path state.")); >> 712 if (*ndp->ni_next == '/') { >> 713 cnp->cn_nameptr = ndp->ni_next; >> 714 while (*cnp->cn_nameptr == '/') { >> 715 cnp->cn_nameptr++; >> 716 ndp->ni_pathlen--; >> 717 } >> 718 if (ndp->ni_dvp != dp) >> 719 vput(ndp->ni_dvp); >> 720 else >> 721 vrele(ndp->ni_dvp); >> 722 VFS_UNLOCK_GIANT(dvfslocked); >> 723 dvfslocked = vfslocked; /* dp becomes dvp in dirloop */ >> 724 vfslocked = 0; >> 725 goto dirloop; >> 726 } > From owner-freebsd-fs@FreeBSD.ORG Thu Feb 22 22:49:27 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 83ABE16A406 for ; Thu, 22 Feb 2007 22:49:27 +0000 (UTC) (envelope-from rodrigc@crodrigues.org) Received: from alnrmhc15.comcast.net (alnrmhc15.comcast.net [204.127.225.95]) by mx1.freebsd.org (Postfix) with ESMTP id 597B113C491 for ; Thu, 22 Feb 2007 22:49:27 +0000 (UTC) (envelope-from rodrigc@crodrigues.org) Received: from c-66-31-35-94.hsd1.ma.comcast.net ([66.31.35.94]) by comcast.net (alnrmhc15) with ESMTP id <20070222222301b1500k47fre>; Thu, 22 Feb 2007 22:23:01 +0000 Received: from c-66-31-35-94.hsd1.ma.comcast.net (localhost.crodrigues.org [127.0.0.1]) by c-66-31-35-94.hsd1.ma.comcast.net (8.13.8/8.13.8) with ESMTP id l1MMN16X013497; Thu, 22 Feb 2007 17:23:02 -0500 (EST) (envelope-from rodrigc@c-66-31-35-94.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-31-35-94.hsd1.ma.comcast.net (8.13.8/8.13.8/Submit) id l1MMN14F013496; Thu, 22 Feb 2007 17:23:01 -0500 (EST) (envelope-from rodrigc) Date: Thu, 22 Feb 2007 17:23:01 -0500 From: Craig Rodrigues To: freebsd-current@freebsd.org Message-ID: <20070222222301.GA13464@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: freebsd-fs@freebsd.org Subject: What does "mount -o union" and MNT_UNION really do? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 22:49:27 -0000 Hi, As part of recent cleanups and stability fixes in vfs_syscalls.c, Kostik Belousov removed the union_dircheckp() callback which the old unionfs implementation used, but the new one does not. Now I am looking at the mount code in vfs_mount.c, and am trying to figure out what the MNT_UNION flag is used for, which is set by doing "mount -o union". The following code in vfs_mount.c sets it: else if (strcmp(opt->name, "union") == 0) fsflags |= MNT_UNION; However, the mount_unionfs binary never passes down "-o union", so the MNT_UNION flag is never set if you do: "mount -t unionfs" or "mount_unionfs". The mount(8) man page documents it as: union Causes the namespace at the mount point to appear as the union of the mounted file system root and the existing directory. Lookups will be done in the mounted file sys- tem first. If those operations fail due to a non-exis- tent file the underlying directory is then accessed. All creates are done in the mounted file system. Is there a legitimate case where you would want to do "mount -o union", and have it behave differently from "mount_unionfs / mount -t unionfs"? Or is this a leftover from a long time ago that we can now whack (it would simplify some code in the VFS layer if we whack it)? The MNT_UNION flag seemed to appear a long time ago: revision 1.120 date: 1999/03/03 02:35:51; author: julian; state: Exp; lines: +35 -33 Slight cleanup of code resurected for union mounts.. Submitted by: Tony Finch ---------------------------- revision 1.119 date: 1999/02/27 07:06:05; author: julian; state: Exp; lines: +23 -1 Fix code for union mounts Accidentally deleted by peter when he extracted the unionfs stuff in 1.109 Submitted by: Tony Finch ---------------------------- revision 1.109 date: 1998/11/03 08:01:47; author: peter; state: Exp; lines: +15 -114 Change the #ifdef UNION code into a callable hook. Arrange to have this set up when unionfs is present, either statically or as a kld module. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-fs@FreeBSD.ORG Fri Feb 23 06:28:51 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F1D9A16A400 for ; Fri, 23 Feb 2007 06:28:51 +0000 (UTC) (envelope-from jwdevel@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id 8DCB613C48E for ; Fri, 23 Feb 2007 06:28:51 +0000 (UTC) (envelope-from jwdevel@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so549410nfc for ; Thu, 22 Feb 2007 22:28:50 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ReWnSBgEbgKfE8Py8rmj7r9LVyfJLJ0CYEqulPXK/q8PWlPo2EV6tVaPL6OYs04WfoHRa11HAWCuua70BHIbEpgNm8/7y5oebO95rYRz39sN127Oiy4nN2mVx6bvE7D087K4mVIIBLnBjipiGFk5RRuHooXokEBF9dd3XEFZrqQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=on+uBT8whz4B+WF+6tXF5JMcERCA2Eu6q3BLgHLzKH040WxNuGlXH2oqSZjjHyFxm9N7N/8nnhO8tSmeKdTXMFY03dVPZDlMW8L//3lAACdlzyv0QHybgjZOKjus1GgkDPoS2ktZ20DLZJS9yKa3VK4Ha7UVxdlQ/P+QaxEnbsg= Received: by 10.78.97.7 with SMTP id u7mr133268hub.1172210655218; Thu, 22 Feb 2007 22:04:15 -0800 (PST) Received: by 10.78.18.4 with HTTP; Thu, 22 Feb 2007 22:04:15 -0800 (PST) Message-ID: Date: Thu, 22 Feb 2007 22:04:15 -0800 From: "j w" To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: strange fdisk numbers X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2007 06:28:52 -0000 Hello (first post, so let me know if this is the wrong list for this) I am working up the courage to use growfs, but got a little confused by fdisk's numbers. The output is below, but what interests me is that it says "heads=16", but then later on has some partitions(slices) saying "head 254" and such there's 16 tracks/cylinder, so maybe that figures in the calculation somehow? (16 tracks * 16 heads ?) I put the output of bsdlabel -A as well any ideas? ******* Working on device /dev/ad2 ******* parameters extracted from in-core disklabel are: cylinders=26310 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=26310 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 7 (0x07),(OS/2 HPFS, NTFS, QNX-2 (16 bit) or Advanced UNIX) start 63, size 10490382 (5122 Meg), flag 0 beg: cyl 0/ head 1/ sector 1; end: cyl 652/ head 254/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 14683410, size 11837070 (5779 Meg), flag 80 (active) beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 15/ sector 63 The data for partition 3 is: The data for partition 4 is: # /dev/ad2s2: type: unknown disk: amnesiac label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 11743 sectors/unit: 11837070 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 1048576 0 4.2BSD 2048 16384 8 b: 2045792 1048576 swap c: 11837070 0 unused 0 0 # "raw" part, don't edit d: 3119104 3094368 4.2BSD 2048 16384 28552 e: 1048576 6213472 4.2BSD 2048 16384 8 f: 4575022 7262048 4.2BSD 2048 16384 28552 From owner-freebsd-fs@FreeBSD.ORG Fri Feb 23 07:21:48 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2BDFB16A403; Fri, 23 Feb 2007 07:21:48 +0000 (UTC) (envelope-from ports@fsck.ch) Received: from secure.socket.ch (secure.socket.ch [212.103.70.36]) by mx1.freebsd.org (Postfix) with ESMTP id BB12313C48E; Fri, 23 Feb 2007 07:21:47 +0000 (UTC) (envelope-from ports@fsck.ch) Received: from localhost ([127.0.0.1] helo=secure.socket.ch) by secure.socket.ch with esmtp (Exim 4.66 (FreeBSD)) (envelope-from ) id 1HKUCO-000KNu-T4; Fri, 23 Feb 2007 07:46:36 +0100 Received: from 62.2.233.2 (SquirrelMail authenticated user roth@fsck.ch) by secure.socket.ch with HTTP; Fri, 23 Feb 2007 07:46:32 +0100 (CET) Message-ID: <1238.62.2.233.2.1172213192.squirrel@secure.socket.ch> In-Reply-To: <20070222222301.GA13464@crodrigues.org> References: <20070222222301.GA13464@crodrigues.org> Date: Fri, 23 Feb 2007 07:46:32 +0100 (CET) From: "Tobias Roth" To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: -3.8 (---) X-Spam-Report: Spam detection software, running on the system "secure.socket.ch", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: [resend, as I forgot to cc the lists and only replied to Craig] On Thu, February 22, 2007 11:23 pm, Craig Rodrigues wrote: > Hi, > > As part of recent cleanups and stability fixes in vfs_syscalls.c, > Kostik Belousov removed the union_dircheckp() callback > which the old unionfs implementation used, but the new one does not. > > Now I am looking at the mount code in vfs_mount.c, and > am trying to figure out what the MNT_UNION flag > is used for, which is set by doing "mount -o union". > The following code in vfs_mount.c sets it: > > else if (strcmp(opt->name, "union") == 0) > fsflags |= MNT_UNION; > > > However, the mount_unionfs binary never passes down "-o union", > so the MNT_UNION flag is never set if you do: "mount -t unionfs" > or "mount_unionfs". > > The mount(8) man page documents it as: > union Causes the namespace at the mount point to appear as > the > union of the mounted file system root and the > existing > directory. Lookups will be done in the mounted file > sys- > tem first. If those operations fail due to a > non-exis- > tent file the underlying directory is then accessed. > All > creates are done in the mounted file system. > > > Is there a legitimate case where you would > want to do "mount -o union", and have it behave differently > from "mount_unionfs / mount -t unionfs"? Or is this a leftover from > a long time ago that we can now whack (it would simplify some code > in the VFS layer if we whack it)? > > The MNT_UNION flag seemed to appear a long time ago: > > revision 1.120 > date: 1999/03/03 02:35:51; author: julian; state: Exp; lines: +35 -33 > Slight cleanup of code resurected for union mounts.. > Submitted by: Tony Finch > > revision 1.119 > date: 1999/02/27 07:06:05; author: julian; state: Exp; lines: +23 -1 > Fix code for union mounts > Accidentally deleted by peter when he extracted the unionfs stuff in 1.109 > > Submitted by: Tony Finch > > revision 1.109 > date: 1998/11/03 08:01:47; author: peter; state: Exp; lines: +15 -114 > Change the #ifdef UNION code [...] Content analysis details: (-3.8 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.6 AWL AWL: From: address is in the auto white-list X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: ports@fsck.ch X-SA-Exim-Scanned: No (on secure.socket.ch); SAEximRunCond expanded to false Cc: Subject: Re: What does "mount -o union" and MNT_UNION really do? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2007 07:21:48 -0000 [resend, as I forgot to cc the lists and only replied to Craig] On Thu, February 22, 2007 11:23 pm, Craig Rodrigues wrote: > Hi, > > As part of recent cleanups and stability fixes in vfs_syscalls.c, > Kostik Belousov removed the union_dircheckp() callback > which the old unionfs implementation used, but the new one does not. > > Now I am looking at the mount code in vfs_mount.c, and > am trying to figure out what the MNT_UNION flag > is used for, which is set by doing "mount -o union". > The following code in vfs_mount.c sets it: > > else if (strcmp(opt->name, "union") == 0) > fsflags |= MNT_UNION; > > > However, the mount_unionfs binary never passes down "-o union", > so the MNT_UNION flag is never set if you do: "mount -t unionfs" > or "mount_unionfs". > > The mount(8) man page documents it as: > union Causes the namespace at the mount point to appear as > the > union of the mounted file system root and the > existing > directory. Lookups will be done in the mounted file > sys- > tem first. If those operations fail due to a > non-exis- > tent file the underlying directory is then accessed. > All > creates are done in the mounted file system. > > > Is there a legitimate case where you would > want to do "mount -o union", and have it behave differently > from "mount_unionfs / mount -t unionfs"? Or is this a leftover from > a long time ago that we can now whack (it would simplify some code > in the VFS layer if we whack it)? > > The MNT_UNION flag seemed to appear a long time ago: > > revision 1.120 > date: 1999/03/03 02:35:51; author: julian; state: Exp; lines: +35 -33 > Slight cleanup of code resurected for union mounts.. > Submitted by: Tony Finch > ---------------------------- > revision 1.119 > date: 1999/02/27 07:06:05; author: julian; state: Exp; lines: +23 -1 > Fix code for union mounts > Accidentally deleted by peter when he extracted the unionfs stuff in 1.109 > > Submitted by: Tony Finch > ---------------------------- > revision 1.109 > date: 1998/11/03 08:01:47; author: peter; state: Exp; lines: +15 -114 > Change the #ifdef UNION code into a callable hook. Arrange to have this > set up when unionfs is present, either statically or as a kld module. > > > -- > Craig Rodrigues > rodrigc@crodrigues.org > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Fri Feb 23 10:11:46 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7ED8416A400 for ; Fri, 23 Feb 2007 10:11:46 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id 2114B13C47E for ; Fri, 23 Feb 2007 10:11:46 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout1.pacific.net.au (Postfix) with ESMTP id B73C25A1D56; Fri, 23 Feb 2007 21:11:44 +1100 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 482872741A; Fri, 23 Feb 2007 21:11:43 +1100 (EST) Date: Fri, 23 Feb 2007 21:11:41 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: j w In-Reply-To: Message-ID: <20070223184946.A14691@besplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@FreeBSD.org Subject: Re: strange fdisk numbers X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2007 10:11:46 -0000 On Thu, 22 Feb 2007, j w wrote: > I am working up the courage to use growfs, but got a little confused > by fdisk's numbers. > The output is below, but what interests me is that it says "heads=16", > but then later on has some partitions(slices) saying "head 254" and > such This has been broken since FreeBSD-4. > there's 16 tracks/cylinder, so maybe that figures in the calculation > somehow? (16 tracks * 16 heads ?) > > I put the output of bsdlabel -A as well > ******* Working on device /dev/ad2 ******* > parameters extracted from in-core disklabel are: > cylinders=26310 heads=16 sectors/track=63 (1008 blks/cyl) After FreeBSD-4, almost everything is broken here: o The parameters weren't actually extracted from the in-core disk label. They were extracted from the "firmware". The "firmware" is usually the drive firmware, except possibly for very old drives which have broken or barely existing firmware, in which case the parameters are fictitious. o The firmware parameters are not the ones needed here. The BIOS parameters are the ones needed. In FreeBSD[2-4], the parameters here were actually extracted from the in-core disk label (for the whole disk), and the latter were set to the system's best guess at the BIOS parameters, so they were actually useful here and in sysinstall's fdisk in cases where they were guessed correctly (mainly in cases where a non-weird fisk table already existed; otherwise, "firmware" parameters were set in the in-core label). So the procedure for getting the correct parameters here is the same in all cases as it was in FreeBSD-[2-4] in the case where the fdisk table doesn't already exist: o ignore the "extracted" parameters here o type in the correct parameters. If an fdisk table already exists, then the correct parameters are the ones used to create the table. These may be determined from one or more of: - your records of what you type in to create the table. - BIOS configuration. What you typed in there, or auto-detected. - FreeBSD[2-4] fdisk or disklabel on the whole disk. The system should auto-detect the BIOS parameters in the same way as the BIOS. - AnOtherOS wth non-broken fdisk on the whole disk. Might work under emulation under FreeBSD, depending on whether the auto-detection is in the kernel or the application. (FreeBSD puts it in the kernel so that it doesn't need to be duplicated in utilities.) If the fdisk table doesn't exist, then almost any parameters that you type in can work, but parameters should be chosen for consistency and portability. Generally, it is best to configure the parameters in the BIOS and duplicate what you got or typed in there. Note that fdisk(8) permits typing in unreasonable (invalid) parameters. The fdisk in sysinstall(8) has more sanity checking, but at least in RELENG_6 its sanity checking is insane so it gets in the way of typing in reasonable (valid) parameters. E.g., the now-standard ATA "firmware" geometry of 16 heads and 63 sectors/track is considered insane for disks larger than 33GB (1GB = 10^9 bytes) since it gives > 65536 cylinders. This was only insane many years ago when BIOSes didn't support > 65536 (virtual) cylinders at much the same time that BIOSes didn't support disks larger than 33GB. Now it is only insane for old BIOSes. sysinstall also considers more than 63 sectors/ track to be insane, but newer BIOSes support up to about 255 sectors/ track. Some BIOSes even default to 255 (?) sectors/track when they don't need to, so if sysinstall actually knows the BIOS geometry like it does in some cases in FreeBSD[2-4], then it considers the perfectly configured and working geometry to be insane, and "fixes" (breaks) it to a "sane" geometry. The parameters are irrelvant to growfs unless you need to grow a slice to make space for growing the fs. Then the same parameters as were used to create the slice should be used. Bruce From owner-freebsd-fs@FreeBSD.ORG Fri Feb 23 10:45:46 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 420C816A401 for ; Fri, 23 Feb 2007 10:45:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1A14D13C441 for ; Fri, 23 Feb 2007 10:45:44 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 85A5D48A19; Fri, 23 Feb 2007 05:45:43 -0500 (EST) Date: Fri, 23 Feb 2007 10:45:43 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Eric Anderson In-Reply-To: <45DDD166.4060606@freebsd.org> Message-ID: <20070223104300.G80197@fledge.watson.org> References: <200702221539.l1MFd0Vr075915@lurza.secnetix.de> <45DDD166.4060606@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, bjoern.koenig@alpha-tierchen.de Subject: Re: The patch delete no umount eject flash disk freebsd panic X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2007 10:45:46 -0000 On Thu, 22 Feb 2007, Eric Anderson wrote: > On 02/22/07 09:39, Oliver Fromme wrote: >> >> The actual code for the daemon could be borrowed from the kernel's msdosfs, >> or from mtools (ports/emulators/mtools). >> >> Unfortunately I don't have sufficient time right now for doing it myself. >> But if someone picks up that idea and implements it, it would be quite >> useful. Using FUSE isn't difficult, bascially you have to link against the >> library and implement handlers for a number of file system related >> functions (lookup, read, write etc.). Since it runs entirely in userland, >> there's no danger of kernel panics, and debugging is quite simple. >> >> Maybe something for the FreeBSD ideas web page ...? > > Honestly, I think the OS should do this, not an external userland tool. > Having a FUSE module handle this, to me, is a bandaid for the right > solution. I'm not claiming I know the solution yet, but I know it should be > a built-in. I think I fall down more with Eric on this one, but do think we should put together an idea on the ideas page relating to msdosfs. I have three things on my desirable list for msdosfs: (1) General cleanup. It could use it. (2) Make it MPSAFE. (3) Make it resilient against disk removal, since it is most frequently used on removable disks (especially USB). The third might require some structural changes in surrounding layers to do right -- I'm not sure if we have all the right bio/GEOM/VM stuff in place to do it nicely now or not. It would be easy to imagine someone spending a summer getting up to speed with msdosfs, cleaning it up, and learning a lot by making in-roads on (2) and (3). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-fs@FreeBSD.ORG Fri Feb 23 16:52:15 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 311B616A404 for ; Fri, 23 Feb 2007 16:52:15 +0000 (UTC) (envelope-from rodrigc@crodrigues.org) Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.154]) by mx1.freebsd.org (Postfix) with ESMTP id DECD913C49D for ; Fri, 23 Feb 2007 16:52:14 +0000 (UTC) (envelope-from rodrigc@crodrigues.org) Received: from c-66-31-35-94.hsd1.ma.comcast.net ([66.31.35.94]) by comcast.net (rwcrmhc14) with ESMTP id <20070223165211m1400popu0e>; Fri, 23 Feb 2007 16:52:11 +0000 Received: from c-66-31-35-94.hsd1.ma.comcast.net (localhost.crodrigues.org [127.0.0.1]) by c-66-31-35-94.hsd1.ma.comcast.net (8.13.8/8.13.8) with ESMTP id l1NGqD7f018613 for ; Fri, 23 Feb 2007 11:52:13 -0500 (EST) (envelope-from rodrigc@c-66-31-35-94.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-31-35-94.hsd1.ma.comcast.net (8.13.8/8.13.8/Submit) id l1NGqDgN018612 for freebsd-fs@freebsd.org; Fri, 23 Feb 2007 11:52:13 -0500 (EST) (envelope-from rodrigc) Resent-Message-Id: <200702231652.l1NGqDgN018612@c-66-31-35-94.hsd1.ma.comcast.net> Received: from dibbler.crodrigues.org (localhost.crodrigues.org [127.0.0.1]) by c-66-31-35-94.hsd1.ma.comcast.net (8.13.8/8.13.8) with ESMTP id l1N6q9iW015471 for ; Fri, 23 Feb 2007 01:52:10 -0500 (EST) (envelope-from ports@fsck.ch) Received: from mail.comcast.net [204.127.228.10] by dibbler.crodrigues.org with POP3 (fetchmail-6.3.2) for (single-drop); Fri, 23 Feb 2007 01:52:10 -0500 (EST) Received: from smtp.easydns.com ([205.210.42.52]) by alnrmxc13.comcast.net (alnrmxc13) with ESMTP id <20070223064518a1300d4113e>; Fri, 23 Feb 2007 06:45:18 +0000 X-Originating-IP: [205.210.42.52] X-Greylist: Passed host: 212.103.70.36 Received: from secure.socket.ch (secure.socket.ch [212.103.70.36]) by smtp.easydns.com (Postfix) with ESMTP id 28C874ED73 for ; Fri, 23 Feb 2007 01:45:17 -0500 (EST) Received: from localhost ([127.0.0.1] helo=secure.socket.ch) by secure.socket.ch with esmtp (Exim 4.66 (FreeBSD)) (envelope-from ) id 1HKUB2-000KNT-PN for rodrigc@crodrigues.org; Fri, 23 Feb 2007 07:45:12 +0100 Received: from 62.2.233.2 (SquirrelMail authenticated user roth@fsck.ch) by secure.socket.ch with HTTP; Fri, 23 Feb 2007 07:45:08 +0100 (CET) Message-ID: <1235.62.2.233.2.1172213108.squirrel@secure.socket.ch> In-Reply-To: <20070222222301.GA13464@crodrigues.org> References: <20070222222301.GA13464@crodrigues.org> Date: Fri, 23 Feb 2007 07:45:08 +0100 (CET) From: "Tobias Roth" To: "Craig Rodrigues" User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: -3.1 (---) X-Spam-Report: Spam detection software, running on the system "secure.socket.ch", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On Thu, February 22, 2007 11:23 pm, Craig Rodrigues wrote: > Is there a legitimate case where you would > want to do "mount -o union", and have it behave differently > from "mount_unionfs / mount -t unionfs"? Or is this a leftover from > a long time ago that we can now whack (it would simplify some code > in the VFS layer if we whack it)? [...] Content analysis details: (-3.1 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 1.2 AWL AWL: From: address is in the auto white-list X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: ports@fsck.ch X-SA-Exim-Scanned: No (on secure.socket.ch); SAEximRunCond expanded to false Resent-From: rodrigc@crodrigues.org Resent-Date: Fri, 23 Feb 2007 11:52:13 -0500 Resent-To: freebsd-fs@freebsd.org Cc: Subject: Re: What does "mount -o union" and MNT_UNION really do? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2007 16:52:15 -0000 On Thu, February 22, 2007 11:23 pm, Craig Rodrigues wrote: > Is there a legitimate case where you would > want to do "mount -o union", and have it behave differently > from "mount_unionfs / mount -t unionfs"? Or is this a leftover from > a long time ago that we can now whack (it would simplify some code > in the VFS layer if we whack it)? Up to recently, mount -o union just worked, while unionfs was documented to be mostly broken. Profile.sh for instance uses -o union, and I never had any problems with it. I am using it exclusively in read only mode though. One difference that I can remember offhand is explained here (taken from mount_unionfs(8): Filenames are looked up in the upper layer and then in the lower layer. if a directory is found in the lower layer, and there is no entry in the upper layer, then a shadow directory will be created in the upper layer. It will be owned by the user who originally did the union mount, with mode ``rwxrwxrwx'' (0777) modified by the umask in effect at that time. This is not the case with -o union. Given the above statement, I am not sure whether unionfs will work if used in conjunction with read only mode. Mount_unionfs(8) talks about another difference, although I don't know whether this is meaningful in the current context: The union file system manipulates the namespace, rather than individual file systems. The union operation applies recursively down the directory tree now rooted at uniondir. Thus any file systems which are mounted under uniondir will take part in the union operation. This differs from the union option to mount(8) which only applies the union operation to the mount point itself, and then only for lookups. Thanks, Tobias From owner-freebsd-fs@FreeBSD.ORG Fri Feb 23 21:41:47 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8DC7416A405 for ; Fri, 23 Feb 2007 21:41:47 +0000 (UTC) (envelope-from koziol@hdfgroup.org) Received: from mail45.opentransfer.com (mail45.opentransfer.com [71.18.111.238]) by mx1.freebsd.org (Postfix) with SMTP id 3BDA413C4B9 for ; Fri, 23 Feb 2007 21:41:47 +0000 (UTC) (envelope-from koziol@hdfgroup.org) Received: (qmail 28845 invoked by uid 399); 23 Feb 2007 21:15:06 -0000 Received: from unknown (HELO ?192.17.35.118?) (192.17.35.118) by mail45.opentransfer.com with SMTP; 23 Feb 2007 21:15:06 -0000 Mime-Version: 1.0 (Apple Message framework v752.2) To: freebsd-fs@freebsd.org Message-Id: <4177DBCC-8DC9-47AC-A3E5-54962074CE6D@hdfgroup.org> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5-684589827; protocol="application/pkcs7-signature" From: Quincey Koziol Date: Fri, 23 Feb 2007 15:15:17 -0600 X-Mailer: Apple Mail (2.752.2) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Filesystem-like developer needed X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2007 21:41:47 -0000 --Apple-Mail-5-684589827 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi all, I'm a long-time FreeBSD user (since 1.x! :-) and advocate in the company I'm with and I'm hoping someone in the community can help me find a good developer for our open-source project. We're a small open-source development company and our main products closely resemble a file-system in a file (sorta :-). Right now we're looking for 1-2 good developers who like algorithms & data structures and know about (or would like to learn about) file system development. Here's the URL for the company: www.hdfgroup.org and the URL for the position description is here: ftp://ftp.hdfgroup.uiuc.edu/pub/ outgoing/koziol/SeniorDeveloperPosition.pdf Thanks, Quincey Koziol koziol@hdfgroup.org --Apple-Mail-5-684589827--