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

Re: disk partition schemes



Russell Coker <russell@coker.com.au> writes:

> 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?
> 

 Maybe not to start with, but why limit ones options for the
future? 

> 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.
>

 Yes, but if you size the main OS partitions sensibly, and
either leave free space at end of disk, or set aside big
partition there, there is not going to be a problem with that.

> > /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!
>

I haven't had any problems with it the last couple of years. I
can't really tell if this is due to me having a separate /var,
or bugs being fixed, and also it is not fully debian specific,
since I set up my *nix boxen the same way.

> > /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.

Haven't compared tmpfs wither ReiserFS. Must do that, thanks!
One other thing tmpfs/shmemfs is faster at is fsck after system
crasch... ;-) (I know, bad joke...)

> 
> 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.
> 

 Yes, but what I was trying to say was that the more stuff I
separate from the root fs, the more writes are going to other
partitions, thus minimizing risk of corruption on rootfs. And
also, the more readonly data I can get away from the rootfs, the
lower the risk of corruption of this readonly data will be. The
only exception would be to leave stuff necessary for
craschrecovery on rootfs.


Regards
-- 
######################################################################
Torbjörn Pettersson               #  Email   tobbe@strul.nu
Vattugatan 5                      #  Web     www.strul.nu/~tobbe
S-111 52  Stockholm, Sweden       #
######################################################################



Reply to: