1

When I install a graphical distro for personal purpose I usually separate /boot and /home.

When I install a server I stick to /boot and / only, and depending on the project I may consider some other on demand, as I have mentioned here with /var/log and /var/lib/docker.

Based on the premise I am talking about a Linux server it seems there is a tendency of recklessly separating every root directory into partitions I don't get why.

@Doug O'Neal have stated here that there is multiple best-practices documents (e.g, CIS Benchmark) that mandate separating /var, /home, /usr, etc, into different file systems.

During my research I have read this article which gives good reasons for separating partitions but doesn't seem to be overdone for every directory.

This other article and here as well mention the per directory partitioning, but does not give any reason, just do that for security sake, blindly trusting them!

The fact you could configure different flags on mounting as nodev, nosuid or even noexec doesn't seem such crucial to me as if the user is not sudoer simple denying write access would be enough, and if it is sudoer these flags would not prevent any damage.

The fact you could backup them separated doesn't pay the burden. and the fact you could clear them separated you could simple remove the directory.

The fact you could have badblocks on some of them doesn't make me feel any relieved, such as the badblocks are given by sector, the files would be damaged with or without partitions.

The only fact I can think could be a little good would be if the partitions are on separeted disks and one of them failed to be loaded or had the partition table sector damaged, but depending on the case you wouldn't be able to boot the system anyway, with or without several spread partitions.

Thinking about this last possibility, in order to recover the disk wouldn't make any difference to have one or several partition, you can run testdisk or ddrescue the image in any case will result the same.

I am wondering what are those so called best-practices' reasons for having several partition separation without taking into account which suit the project?

Tiago Pimenta
  • 111
  • 5
  • 1
    Best practice is just another opinion. I listed a number of (historical) reasons in [this Q&A](https://serverfault.com/a/629479/37681). Admittedly nowadays for VM's with virtual disks that can be arbitrarily expanded I have stopped caring about any fancy partitioning and assign the whole disk to the root fs (and use a swap file rather than partition) for trivial resizing. The odd physical server may get a bit more TLC as may a server where actual users get access, rather than the server only running a single application. – HBruijn Jun 20 '18 at 20:02

1 Answers1

0

I find it really depends upon your resources to work from, their preexisting configurations, and how you intend to work in the future. If you are still running on bare metal, and local storage, it makes sense to partition, since you may need to expand at the physical layer. You may not have a spare slot for putting in a RAID controller, or enough RAM to run RAID in software, so you do the best you can with your resources. For example, if /home is filling up, then you can add another disk to the system, then rsync, then go single user, resync, and reset the mount points. An "all in one" is possible, and negligible impact, but I find it easier to migrate this way.

Databases always prefer to have them split apart for performance reasons - put your logs in one place, your data in another, and if possible, your indexes in a third location - with their own disks, and controllers! It simply keeps the lane open for data transactions.

It's mostly about space management. I have a set of production servers which generate 100 GB of log files before the log rotation begins, as literally that much information is needed to capture some extended transaction data. (A single "transaction" can trigger 10,000 unique subtasks, which all of them need to have full transactional status maintained.) If development expands this requirement, I can opt to do a service pause/halt, remount the new path, and start - instead of having to shift 100 GB of logs around....

I can't risk the OS taking a dive from a disk space issue, nor the database to wait for a write to do a commit, so we can expand the space out to a separate disk (and controller) in the future. If I have a box with a huge data store, and I want to use SSD for the OS and application layer, hybrid is a viable choice for me. Again, easiest to migrate partitions of data, versus entire disk drives. (and yes, I do use old school "dd" for this.)

Bee Kay
  • 164
  • 7