From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 14 16:12:34 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3558316A4CE for ; Mon, 14 Mar 2005 16:12:34 +0000 (GMT) Received: from avout3.midco.net (avout3.midco.net [24.220.0.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AE3F43D4C for ; Mon, 14 Mar 2005 16:12:31 +0000 (GMT) (envelope-from freebsd-hackers@evilcode.net) Received: (qmail 15242 invoked by uid 1009); 14 Mar 2005 16:12:31 -0000 Received: from freebsd-hackers@evilcode.net by avout3 by uid 1003 with qmail-scanner-1.22 (f-prot: 4.4.2/3.14.11. Clear:RC:1(69.9.210.177):. Processed in 0.074028 secs); 14 Mar 2005 16:12:31 -0000 X-Qmail-Scanner-Mail-From: freebsd-hackers@evilcode.net via avout3 X-Qmail-Scanner: 1.22 (Clear:RC:1(69.9.210.177):. Processed in 0.074028 secs) Received: from host-177-210-9-69.midco.net (HELO [69.9.210.177]) ([69.9.210.177]) (envelope-sender ) by avout3.midco.net (qmail-ldap-1.03) with SMTP for ; 14 Mar 2005 16:12:30 -0000 From: "Samuel J. Greear" Organization: Evilcode Corp. To: Anish Mistry Date: Mon, 14 Mar 2005 09:15:53 -0600 User-Agent: KMail/1.7.2 References: <1107178792.613.22.camel@spirit> <42348525.8080302@cis.strath.ac.uk> <200503131524.16075.mistry.7@osu.edu> In-Reply-To: <200503131524.16075.mistry.7@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503140915.53619.freebsd-hackers@evilcode.net> cc: freebsd-hackers@freebsd.org cc: Chris Hodgins Subject: Re: Idea about 'skeleton jail X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2005 16:12:34 -0000 On Sunday 13 March 2005 14:24, Anish Mistry wrote: > On Sunday 13 March 2005 01:23 pm, Chris Hodgins wrote: > > Samuel J. Greear wrote: > > > Not a bad 'idea' at all, although I won't comment on semantics. > > > I had something implemented using fs stacking (in a very hackish > > > way, and I believe it's lost now, so don't ask to see it...) to > > > implement per-jail quota's that seemed to work quite well. > > > > > > Sam > > > > Feel free to comment on the semantics. As I said before, I am not > > very knowledgable about filesystems and any insight or alternative > > implementation you can provide would be interesting I'm sure to > > everyone. > > Yeah, if there was jailfs that was setup automatically for the jails > that supported quotas out of the box that would kill my major gripe > about setting up jails. Chris, your concept looks reasonable to me. I think I would probably do something along those lines but borrow some idea's from my 'jail-build' script. It has the concept of both includes and excludes, but it also handles another directory for what I call overrides. My overrides directories are per-jail and typically include nothing more than config. files, but it works pretty handily. The overrides may best be implemented in a seperate layer... and I don't even know that I would call something like this a jailfs, more like a globfs or something... I can see potential uses beyond jails. The reasons that I never finished implementing my jailfs with quota support were primarily, that stackable filesystems seem to be somewhat of a black-art. Secondarily, I concluded that the time would be better spent implementing filesystem agnostic quota's in the vfs layer. A proper design should enable you to do a lot of fun things, I was thinking something along the lines of just a simple aggregator that a module could hand function pointers to and register interest in events, with options like.. just-notify-me and dont-continue-without-my-approval. Throw in some helpers for synchronizing module state to disk. The kernel side of this shouldn't really be very hard, but all of the userland quota utilities would need to be rewritten as they are tied to UFS at the block level. This all from about 3 years ago, and I haven't implemented any of it. I rock! Sam