[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