Re: disk partition schemes
On Thu, 5 Jul 2001 16:50, Torbjorn Pettersson wrote:
> /boot : Sector sizes and such already discussed, you will
> discover that you need a separate boot, and then it
> will be to late. You are not talking about wasing space
> here either, it can be really small, but you will need
> it for example when you start trying out alternative
> filesystems (like reiserfs or whatever) or software
> raid or other stuff...
You can boot off ReiserFS on RAID-1 with LILO, you should be able to boot
other file systems such as XFS or JFS too. However do you REALLY want to
try out new file systems on the root fs?
The issue isn't wasting space, it's wasting partition numbers. Partitio
numbers above 4 on Intel are liable to change when adding or removing
partitions, this is a real PITA so you want as much as possible in the
first 4 partitions.
> /var: Really necessary. Log files, .debs,. If this is on root
> filesystem chances are your machine will crasch, and
> not boot up.
Have you filed bugs against the daemons that block booting when the root
FS is full? The system should boot when all partitions are totally full.
Daemons may not be able to offer full service, and some daemons may
refuse to run, but the system should boot!
> /tmp Same reasons as with /var. If you are using the 2.4
> kernel you could use the shmemfs (or whatever it is
> called, same as tmpfs on SunOS.) if you allocate
> enough of swap. A lot faster.
tmpfs on Solaris is not a lot faster. Last time I tested creation of
large numbers of small files ReiserFS was faster than tmpfs. Deletion on
tmpfs is faster though.
I have not tested the Linux tmpfs for speed. When I tried it I couldn't
login to kde when it was mounted, so for me it seemed to be not fully
functional (and thus not worthy of testing for performance). I have not
yet determined the cause of this problem (KDE startup is very complex and
complicated).
> / & /usr Yes, also necessary. Reason behind this. Your
> machine is going to crasch. You will need as much of
> operating system as possible to salvage rest of
> system with. /var /home and other partitions with
> lots of writes to are going to be in a mess, and you
> are going to have one crash were you are not able to
> fsck these partitions, but must restore data from
> backups. Debian project working towards system
> containing enough tools on '/' to do this, but don't
> know if it is ready yet. Anyway, the smaller the
> root fs is the better. (fsck times and reduce chance of
> corruption)
Wouldn't the chance of corruption be determined by the number of writes
to the FS not the size of the FS? As usr is essentially read-only with
the exception of /usr/src (which I make a sym-link to /var or /home) I
would not expect it to add any risk by having it in the base system.
Also currently the jfs FSCK program is in /usr/sbin (I have filed a bug
report). This means that JFS is not suitable for /usr with the current
Debian packages...
Oh regarding backup. I have not heard of a large ISP that will EVER
backup mail for their customers. The technical issues related to backing
up 1M or more mail boxes make it extremely difficult and expensive - so
AFAIK no-one bothers.
It is rather amusing when a hardware upgrade goes wrong though and people
start sweating about whether 1M people will complain about lost mail. ;)
--
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page
Reply to: