[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

> / & /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: