From owner-freebsd-hackers Wed Nov 19 22:44:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA14174 for hackers-outgoing; Wed, 19 Nov 1997 22:44:09 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id WAA14169 for ; Wed, 19 Nov 1997 22:44:06 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id HAA01818; Thu, 20 Nov 1997 07:44:05 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id TAA27758; Wed, 19 Nov 1997 19:31:41 +0100 (MET) Message-ID: <19971119193141.NY02422@uriah.heep.sax.de> Date: Wed, 19 Nov 1997 19:31:41 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Cc: luomat+freebsd+hackers@luomat.peak.org (Timothy J Luoma) Subject: Re: NBQ: Why partitioning? (was: Re: Partitioning suggestions?) References: <199711180019.TAA01983@dyson.iquest.net> <199711180202.VAA04479@luomat.peak.org> <19971117192532.37475@micron.mini.net> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <19971117192532.37475@micron.mini.net>; from Jonathan Mini on Nov 17, 1997 19:25:32 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Jonathan Mini wrote: > There are your reasons. :) I'm sure there are probably more. Well, having installed a new central server in our company last weekend, i had to find that i ran out of partition slots on the first disk to satisfy all my wishes. ;-) I've solved the problem by making /tmp not a separate disk filesystem, but MFS instead. (I'm not very fond of MFS, for a number of reasons.) I wished we would support 16 partition slots at least as an alternative to the backwards-compatible 8 slot model. The main reason for having multiple filesystems is that the unix kernel decides many things on a per-filesystem basis: mount flags describing the basic properties of the filesystem (read/only vs. read/write, async metadata updates, allowed to execute something at all, allowed to have /dev nodes, allowed to execute setuid binaries, etc. pp.), and NFS exportation come to mind. I understand that this is just a kernel optimization. It's sheer impossible inside the kernel, to find out for a particular vnode whether it's the part of a given tree subhierarchy. However, finding out about which filesystem you're mounted from is very simple. So if something like the mentioned features are to be applied to a particular subtree, binding them to a filesystem seems to be the best compromise given the historical structure of the unix filesystem. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)