Mailing List Archive


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

Re: [tlug] how filesystem works?



Arwyn Hainsworth wrote:
> On 02/04/07, *emiddleton@example.com
> <mailto:emiddleton@example.com>* <emiddleton@example.com
> <mailto:emiddleton@example.com>> wrote:
>
>     Arwyn Hainsworth wrote:
>     > On 02/04/07, * emiddleton@example.com
>     <mailto:emiddleton@example.com>
>     > <mailto:emiddleton@example.com
>     <mailto:emiddleton@example.com>>*
>     <emiddleton@example.com <mailto:emiddleton@example.com>
>     > <mailto:emiddleton@example.com
>     <mailto:emiddleton@example.com>>> wrote:
>     >
>     >     Stuart Luppescu wrote:
>     >     > Curt Sampson wrote:
>     >     >>
>     >     >>     root    64-128 MB
>     >     >>     tmp        128-1024 MB    mfs
>     >     >>     /usr    2-4 GB
>     >     >>     /var    0.5-2 GB    nosuid
>     >     >>     /home    2-8 GB        nosuid,nodev
>     >     >>     /u        remainder    nosuid,nodev
>     >     > This is something I never understood. Someone told me to
>     put /var in
>     >     > its own partition because if it fills us (with log files, or
>     >     whatever)
>     >     > it will crowd out other stuff and make the computer
>     unusable. I did
>     >     > that, and then /var filled up, syslog  and cron complained
>     about not
>     >     > being able to write files and the whole computer froze up.
>     Now I put
>     >     > /var inside / and haven't had any problems.
>     >
>     >     Have you ran out of memory in your one and only root
>     partition and
>     >     not
>     >     had any problems?
>     >
>     >
>     > You will have problems when you run out of space no matter how you
>     > break up your partitions. The reason for separate partitions is not
>     > for space, but to allow different mount options or even
>     different file
>     > systems for different tasks. Note that in the example above
>     /usr, /var
>     > and /home are all mounted with different options. As another
>     example,
>     > in some server environments you might want to have /var/log on an
>     > append-only fs to prevent log tampering.
>
>     Mount options and choice of file systems, are good reasons for using
>     separate partitions but partitioning space is also a good reason.  All
>     these things are really about making your system more robust.  Saying
>     that "You will have problems when you run out of space no matter
>     how you
>     break up your partitions." is like trying to justify not making proper
>     backups because they won't stop disk failures.
>
>
> No, it's more along the lines of "Even if you make backups, you will
> have trouble reading data from you disk if the disk fails.". Backups
> prevent data loss, they do not prevent the pain of replacing a hard
> drive. Using multiple partitions gives a few advantages, but does not
> prevent problems when they run out of space. If /var gets full some
> services might not want to run, if /home is full KDE and Gnome will
> not login and likewise some programs will fail if /tmp is full.
>
>     > In most cases such separation is not really required and badly
>     chosen
>     > partition sizes can cause more problems than they are worth.
>
>     This is what Logical Volume Management is for, unless you can predict
>     with absolute certainty what your future disk usage will be fixed
>     partition sizes are a really bad idea. 
>
>
> LVM will help with that, yes. But LVM also has its disadvantages. What
> I am trying to say is that there is no silver bullet and that each
> situation has it's own optimal configuration, but in most cases a
> simple 2/3 partition configuration will suffice.

If your /var is getting full something is wrong with your system,
perhaps you haven't allocated enough space or perhaps some process is
generating a log file that isn't being logrotated.  It would appear that
you are advocating using a combined root var file-system if you don't
have any better ideas about how to partition.  If you don't know how you
should be partitioning I would advocate taking a conservative, best
practice approach, something like what Curt advocated, with the addition
of having them placed on lvm so that you have the flexibility to change
things later.  It won't stop you running out of memory but it will make
it easier to fix if you do.  It also has the added advantage of allowing
you to see how much memory different parts of your file system are is
using (i.e. df)

Edward



Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links