[plug] Disk partitioning

James Bromberger james at rcpt.to
Thu Jan 10 22:46:34 WST 2002


On Thu, Jan 10, 2002 at 10:32:06PM +0800, Jonathon Bates wrote:
<snip>
> > 1. safety,
> > 2. management,
> > 3. so I don't have to stare at a bad block read check for a very long time ?
> I have always believed that if you have a large drive, that you partition
> it down to a more managable size. And I do believe there are some 
> exploits with large drives being unparitioned.
> So I would suggest having / /tmp /home /var on different partitions.

There are lots of games you can play here, and it really depends on what the 
machine is to be used for. If it's just your own machine, with no other 
users, no direct inbound traffic from the Net, then you can probably 
just do one big one now days. My teachings were for paritioning to 
protect the system from the users and the outside world:

	* /home on one parition - if the users fill this up, 
	  then the user have a problem, and everything else is fine
	* /var on another, since this is variable data, such as mail spools 
	  and log files, and can grow quite big over time and due to inbound 
	  and outbound data.
	* /usr on another - since this is your installed programs, it can 
	  be mounted read-only to protect from unwanted messing with.
	* /boot - not needed now, but used to have to be there for old 
	  lilo so the image was in the first 1024 blocks or so of the disk.

Nowdays you can play with LVM too: Logical Volume managment, similar to 
Veritas in some respects, if you have heard of that name. LVM lets you 
soft partition the disk, and so long as the filesystem you have on 
each soft parition can be resized, you can rearrange as you like on 
the fly.

IMHO, LVM and RAID have a bit further to go in getting things right 
before I recommend it to anyone. I tried these two in combination 
with 2.4.8 some time back, but it was "non-trivial" at the time 
(I was also incorporating reiserfs and devfs too; I posted about 
this back at the time). Perhaps more recent kernels are neater - I 
have been scanning changelogs and see comments such as "RAID cleanup", 
"LVM tidy"... *shrug*

Anyway, you can always define something like a "space" parition for large 
disk areas, mount it as /space, and then use symbolic links from 
anywhere else on your file system into /space (or under 2.4, take 
advantage of the multiple mounts feature, but this may be more pain 
than gain, YMMV). For my last large disk, I defined /usr/local/fileshare, 
being the main Samba (happy birthday Samba, 10 y.o.) share (62 GB RAID 1).

  James

-- 
 James Bromberger <james_AT_rcpt.to> www.james.rcpt.to
 Australian Debian Conference: http://www.linux.org.au/conf/debiancon.html
 Remainder moved to http://www.james.rcpt.to/james/sig.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.plug.org.au/pipermail/plug/attachments/20020110/867cab83/attachment.pgp>


More information about the plug mailing list