From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 14 18:43:14 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 E722F16A4CE for ; Mon, 14 Mar 2005 18:43:13 +0000 (GMT) Received: from crumpet.united-ware.com (ddsl-66-42-172-210.fuse.net [66.42.172.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3714343D2D for ; Mon, 14 Mar 2005 18:43:13 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (adsl-68-252-59-28.dsl.wotnoh.ameritech.net [68.252.59.28]) (authenticated bits=0)j2EID9lu007438 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 14 Mar 2005 13:13:12 -0500 (EST) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: "Samuel J. Greear" Date: Mon, 14 Mar 2005 13:46:34 -0500 User-Agent: KMail/1.7 References: <1107178792.613.22.camel@spirit> <200503131524.16075.mistry.7@osu.edu> <200503140915.53619.freebsd-hackers@evilcode.net> In-Reply-To: <200503140915.53619.freebsd-hackers@evilcode.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart10268516.nCS0ysdE0r"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200503141346.41722.mistry.7@osu.edu> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on crumpet.united-ware.com 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 18:43:14 -0000 --nextPart10268516.nCS0ysdE0r Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 14 March 2005 10:15 am, Samuel J. Greear wrote: > 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 Would you be able to write up some design specs for getting all this=20 done? This might be a prime example of something to try to get=20 funding for development. =2D-=20 Anish Mistry --nextPart10268516.nCS0ysdE0r Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCNdwRxqA5ziudZT0RAjDnAJ0ey+K7RiZN0VckLuthoR/NLmuvnACg4RPL kqmIVre97Ar4EKvbf+DQN8s= =BWDp -----END PGP SIGNATURE----- --nextPart10268516.nCS0ysdE0r--