# Why different file systems and mount points?



## dave (Oct 9, 2011)

Can someone explain to me what the purpose of having different filesystems for /var, /etc, /usr, and / is? If they are all on the same physical device, why not just mount /?


----------



## Alt (Oct 9, 2011)

/var holds logs, mail spool etc, so overflowing can lead to system stop if you place it in same device as /. /usr is user dirs, installed packages etc, same issue. Plus, backup meanings. Dunno about /etc.


----------



## _martin (Oct 9, 2011)

Many reasons. You can better isolate possible issues and it does ease up the overall system administration; it does however depend what you are using the system for. 

It's easier to cleanup separated file systems (logs, mails, temps, etc.), easier to do the restore if some of the file system gets corrupted. You can specify special mount options for particular file system. You can play with a performance too (how the slices/partitions are done on the physical disk).


----------



## Beastie (Oct 9, 2011)

/etc is never given its own file system. The fstab file (among many others) which tells the system what file systems to mount and where to mount them, is stored in /etc. Making /etc a separate file system is just looking for trouble.

As for the rest, there are many reasons: file system usage optimization, damage control, security, ease of maintenance, etc.


----------



## Pushrod (Oct 10, 2011)

That type of partitioning is basically pointless in my opinion. A partition is much more likely to run out of space if it is small. When you have separate /usr, /var, and so on, this is bound to happen eventually, especially if the role of the machine changes over time.

If you have a machine that is a mail server or DB or something, you'd normally give THAT its own partition. Having a separate /usr or /var does nothing to accomplish this. Moving files between the partitions increases the chances of failure if the two partitions are on the same disk, as that disk has to read and write back and forth to move the data.

If the partition table on a disk with partitions is lost or corrupted, the chances of recovering any of the partitions goes way down. With a single partition, this can be solved by simply re-creating the partition that takes 100% of the space.

All that matters is having good backups. The so-called benefits of partitioning mean nothing if the data isn't backed up properly.


----------



## dave (Oct 10, 2011)

I tend to like backing up my OS drive using dump as described here.  Seems to me dump and restore would behave the same way whether or not there were separate filesystems.  Is this true?


----------



## dh (Oct 10, 2011)

More things to consider: Different blocksizes, different mount options (noexec, nosuid, not having softupdates on / mountpoint), quotas


----------



## fluca1978 (Oct 10, 2011)

The flexibility to split a system into slices and partitions gives you the capability to configure it as you want. It allows you to prevent the whole system stop running due to a full disk, it allows you to apply quotas to a single filesystem and not system wide, as well as other flags, and allows you to place partitions that must run faster on the disk space that will give you best performances. Of course, all this power is often too much for a home system or a desktop.


----------



## hedgehog (Oct 10, 2011)

Also, if you're using ZFS (or anything else snapshot capable), you could create snapshots of an existing filesystem before huge upgrade. For example snapshot would make quick backup for /usr/local and /var/db/pkg so you can quickly restore your desktop applications.

By the way there was vulnerability discovered in glibc a year ago. To exploit this one an attacker had to make hard link to suid flagged file. Systems with separated /tmp, /home or any other 777 directories wasn't vulnerable, because it's not possible to create hardlink to file on another device.


----------



## Shivaram (Oct 10, 2011)

dave said:
			
		

> I tend to like backing up my OS drive using dump as described here.  Seems to me dump and restore would behave the same way whether or not there were separate filesystems.  Is this true?



I've never used dump, but from what i understand it different if you have one file system for your entire system or multiple filesystems (partitions i mean). 

From the same document you mentioned 

"Each filesystem must be dumped individually; this is sometimes expressed as "dump does not cross filesystems"."


----------



## Beastie (Oct 10, 2011)

dave said:
			
		

> Seems to me dump and restore would behave the same way whether or not there were separate filesystems.


They work on individual file systems.
If you have your entire system on a single partition, you dump/restore that one (i.e. /).
If you have more than one partition, you dump/restore each one of them, or any one that you need. For example if you have /, /var, /tmp and /usr but don't care about /tmp, you'd dump/restore /, /var and /usr only, obviously.


----------



## wblock@ (Oct 10, 2011)

Using multiple filesystems is kind of like using multiple directories.  It gives you a way to divide things up for organization.  When space is limited, that's not efficient because the free space is split between multiple filesystems.

The FreeBSD-9 installer creates one unified filesystem by default.


----------



## kpa (Oct 10, 2011)

ZFS is very much how it should have been done from the beginning, you can use the whole space available in a pool and subdivide it into separate filesystems as you like and you don't have to think about partitions anymore.


----------



## Pushrod (Oct 10, 2011)

wblock@ said:
			
		

> The FreeBSD-9 installer creates one unified filesystem by default.



This is great news.

Next change request: make MINFREE a fixed size instead of a percentage.


----------

