8

Is there some kind of "best disk partitioning scheme" for a Linux-based web and application developer machine, in terms of performance, organization or others?

sonnuforevis
  • 201

5 Answers5

9

Partitioning doesn't affect performance so much, but yes, file systems and their configuration affect performance. Look at this benchmark. For a little information about mounting options, see fstab at the ArchWili; especially look at atime options.

Partitioning has nothing with organization files in Linux, because in Linux everything is mounted into one tree.

I recommend one partition for the root filesystem, /, and separate partitions for folders where you place your work and personal data: /home and /var/www if you put your websites here, because if you change distro you will no need to do backup.

You may make partitions/disks based on files organization and their importance.

For example, you have got projects and documents which are very precious, then you can have them on RAID-ed disks. Also you may have remote disk mounted with ssh/ftp.

Mounting scheme:

/                      -> SSD disk, partition 1
/home                  -> SSD disk, partition 2
/tmp                   -> tmpfs
/media/data            -> RAID-ed disk, partition 2 (ie. shared photos with family)

user mounts:
/home/miroslav/secure  -> RAID-ed disk, partition 1 (encrypted)
/home/miroslav/remote  -> sshfs/curlftpfs

To mount remote and secure directories you will probably need some script that asks you for password(s).

Directory sym-links pwd=/home/miroslav:

projects       ->  secure/projects
documents      ->  secure/documents
mails-dir      ->  secure/mails
G-Man Says 'Reinstate Monica'
  • 22,870
kravemir
  • 4,174
3

On our internal developement virtual machines we use three partitions:

  1. /root partition - housing mostly static operating system stuff

  2. /var partition - for all dynamic data

  3. /home partition - this is where development takes place with the user accounts of the developers

The reason to separate the partitions is to avoid a system halt due to full filesystem. If /home is full - does not matter. No running processes are affected. Delete something, enlarge online and continue.

/ should not change much (the only exception is /tmp - but files there are usually never big).

/var is the place where /var/tmp and all other "live" data resides (including /var/log). A full /var/log is still the number one reason for system/application failures, so /var has to be big enough and there has to be a warning in time when space is becoming sparse there...

On physical machines, where disk space does not matter that much, we divide up additional "partitions" (mostly LVs), including: /var, /var/tmp, /var/log, /tmp, /boot, ... but these are production machines, where uptime matters.

nozimica
  • 884
  • 8
  • 24
Nils
  • 18,492
1

At a minumum, I'd do:

  • 1 partion for /
  • 1 partition for /home (this would be most of the space)
Greenonline
  • 1,851
  • 7
  • 17
  • 23
bigdaveyl
  • 339
1

I used to make separate partitions for /, /home, /usr/local and /var, but I always seemed to end up with some sort of interactions across partitions. If I did install a different distro, I would want to have the unused dotfiles removed for simplicity, so I still made a backup and wiped /home.

As for making a /var partition, I made so many sites at school (~100 or so), with such a large variance in sizes between media heavy sites and text only exercises, that it was impossible for me to accurately estimate the amount of space to allocate.

Now, I just have one partition for everything, and I don't come anywhere near filling it up. Personal media (movies, games, shows) go on an external HD, so that I can take it to a friend's house. For virtual machines, which have to be virtual appliances in virtualbox if you want to move them, I like to have a dedicated flash drive for each one.

I've never seen a HD crash, but if it did, I don't think it would matter how the physical drive was partitioned; it would just be dead. The riskiest thing I've ever done with my HD is resizing partitions, which is no longer necessary.

Dan Ross
  • 615
  • 2
  • 6
  • 14
0

From experience probably the most manageable best partition scheme looks like this:

  • / (/Dev /etc /root /run /opt /mnt /media) 40 GB (for mounting large files)
  • /usr (/bin /sbin /lib /lib64) 10 GB
  • /tmp 8 GB (download file size max 6 GB)
  • /var 20 GB (don't want Linux jamming keep big)
  • /boot 1280 MB
  • /home (rest)
  • /home/bin 512 MB

Why like this?

For /, it's practical to mount it read-only minus /etc, but once system is fully configured, you want your system to feel fresh after every boot and that is an important step. Also you can safely mount these with noexec nosuid nodev without much in the way of consequence.

For /usr ideally you will mount as read only to stay fresh, but the odd time you update just remount as rw, no biggie; safely use nodev.

/tmp and /var because you can't make read only and want to use nodev nosuid noexec.

/boot for obvious reasons, read-only (ro) nodev nosuid noexec.

Why the separation between /home and /home/bin, so that I can chown root /home/bin and give it exec privileges, and deny those same privileges to /home. So scripts must be run as sudo and from that directory.

BTW, /proc and /sys are virtual file systems created by the kernel. Therefore can be mounted as desired in fstab.

Greenonline
  • 1,851
  • 7
  • 17
  • 23
E L
  • 1
  • 1