From owner-freebsd-questions@FreeBSD.ORG Thu Oct 9 18:56:40 2003 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A59816A4B3 for ; Thu, 9 Oct 2003 18:56:40 -0700 (PDT) Received: from ganymede.hub.org (u173n10.eastlink.ca [24.224.173.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0C8D43FAF for ; Thu, 9 Oct 2003 18:56:38 -0700 (PDT) (envelope-from scrappy@hub.org) Received: by ganymede.hub.org (Postfix, from userid 1000) id CC58D358FE; Thu, 9 Oct 2003 22:55:26 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id C9B9B358FC; Thu, 9 Oct 2003 22:55:26 -0300 (ADT) Date: Thu, 9 Oct 2003 22:55:26 -0300 (ADT) From: "Marc G. Fournier" To: Kris Kennaway In-Reply-To: <20031010011640.GE10682@rot13.obsecurity.org> Message-ID: <20031009223612.J28590@ganymede.hub.org> References: <20030803200948.GA10712@lewiz.org> <200310091700.09658.kennyf@pchg.net> <20031010011640.GE10682@rot13.obsecurity.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD-questions cc: Lewis Thompson cc: Kenny Freeman Subject: Re: Jail FS questions. X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 01:56:40 -0000 On Thu, 9 Oct 2003, Kris Kennaway wrote: > On Thu, Oct 09, 2003 at 05:00:02PM -0400, Kenny Freeman wrote: > > > > I've been reading about unionfs and nullfs (well, more skim reading > > > really; I'm not FS guru, which is why I'm asking here) and one of these > > > sounds like it could be the idea solution. At first glance I'd say that > > > unionfs would be the way to go. > > Both unionfs and nullfs are documented to be broken. Seriously, those > big scary warnings in the manpages are there for a reason! > > Having said that, some people have reported success in certain limited > situations. If you insist on using them, then you're on your own > if/when it breaks. > > This means: do not complain to us when your system crashes and you > lose a filesystem. Wow, what a way to encourage ppl to report bugs ... glad there are ppl like Tor and David Schultz out there that are interested in fixing bugs and not ignoring them ... You know, its this attitude that would have kept Christopher Columbus in Europe ... all the "big scary warnings" said that the world was flat back then, no? As everyone on -STABLE knows by now, I very heavily use unionfs on very heavily loaded systems ... between Tor Egge and David Schultz, all of the unionfs related crashes I've experienced have happily disappered ... my unionfs related server hangs (dealing with vnodes) have also disappeared ... I have two things left that I know will trigger a crash: run pkg_delete on a unionfs'd jail, and it gives the unionfs_dir crash, and create a socket on a uniofs directory, and it causes a crash ... so I'm careful not to create sockets (/var isn't a unionfs mount as a result) and I rm'd pkg_delete so that it couldn't be accidentally run ... I have yet to "lose a file system" except when a hard drive went bad ... my biggest 'headache' right now is that periodically, if the server does crash, fsck takes a very very long time due to 'ZERO LENGTH DIRECTORIES' ... So, based on almost two years of heavy experience with unionfs ... yes, there are some problems with it, and yes, there used to be some that warranted the "big scary warning", but that state of unionfs today, IMHO, the warning now is way overstated, and is only serving to give an excuse for those wishing to ignore problem reports based on it ... In fact, if you ever followed some of the threads discussing what it would take to fix unionfs, you would see several developers mentioning that the whole VFS layer code needs a complete re-write ... several have suggested completely removing some of the more 'damaged aspects' (ie. nullfs and unionfs) to reduce the time required to do the re-write, and re-adding them in at a later date ...