Hello,

Thank you for reading my post.

I need to create a "good" partition scheme for a new machine.
I've thought about creating the following partitions.

On another running Debian system I have the following results:
Which could be re-written like this:
Do you think it is a reasonable choice to apply these percentages to another hard disk drive of size D?
If not, can you make some suggestions?

Thanks for your expertise and best regards,
--
Léa

No.

The size of the partitions should not be determined by the size of the disk at all.
For example: You have OS A on the old smaller disk and OS B on the new larger disk. Both OSes have the same packages installed, so both OSes are very likely to have the same amount of space used in /usr. So why should /usr be larger in OS B as in OS A? And if you run the same workload on both OSes, why should the /tmp-partitions be of different size? As a short example: I have a 40GB SSD in my laptop and 1,5TB of disk-space in my main rig. The laptop has a 10GB /-partition on the disk, which are 25%. That does in no way mean that I should set up a 375GB /-partition on my main rig, that would be simply wasted space. Since I have a totally different type of usage for both machines I have setup a 50GB /-partition (which still is to large, but I want to have some reserved space for experiments).

In short: You should determine the size of the partitions in regards to the usage of that machine, not a ratio you got from a different machine.

Moved: This thread is more suitable in the Linux General forum and has been moved accordingly to help your thread/question get the exposure it deserves.

No.

What are the systems used for?

Why do you think it would be helpful to have all those as separate partitions rather than just directories in / ?

How much swap space will you allocate?

I don't know why someone might want /usr in its own partition. I think reasons for /var and /home in their own partitions tend to be bogus anyway, but also tend to be relevant more for unattended server systems rather than single user systems.

Some activities (such as software development, which I do) may create and delete a lot of very short lived files in /tmp. If you do that, then making /tmp a tmpfs is more efficient than a true partition (or ordinary directory of /). As a tmpfs, /tmp will use ram if it is available and swap otherwise. Be sure to allow for /tmp use when planning swap size if you make /tmp a tmpfs.

If you don't make /tmp a tmpfs then making it a separate partition (rather than just a directory in /) usually makes sense on some unattended systems but not on single user systems nor stable systems nor closely monitored systems.

For /usr, /var, /home etc. if you don't have a good understanding of why they should be partitions in your use of Linux, you're better off not making them separate partitions.

The main purpose of splitting into partitions is to represent differing levels of severity for the fault of running out of disk space. The split into partitions increases the probability that some operation will fail due to lack of disk space, so the direct effect is negative. If you split into partitions wisely and accurately, you decrease the probability that a really important operation will fail due to lack of disk space (by increasing the probability that a less important operation will fail). But an unwise split just increase the probability of such a failure without reducing the probability that the failure will be important.

The best way from a flexible standpoint would be to use LVM, this way you could expand a logical volume and/or shrink it.

For example a web server I split out /var because you may want different mount options like 'noatime'. I create a separate /home directory so I can enforce quota management and acl's on files.

On a new server, it is best to sit down and calculate long-term the storage needs and locations of the data and the day you have to migrate the data to a new system.

One thing is to keep in mine how hard it will be to migrate the system to a newer release, splitting out /home /var /opt is easier in my opinion since you can actually dismount the file system and tar/rsync data to the server. You can do this with it mounted as well, but I find it easier to manage.

With everything in / then you can run into problems with quota management, since home is under / in the logical volume.

One last note I always calculate using 1024 * size needed.

Lastly, think long-term once it is in place there is no way to go back in time.

@TobiSGD & @johnsfine & @rhbegin : Thank you for your answers.

Ok. You're right.
I thought percentages were interesting to get an idea of the suitable relative sizes for the different partitions: which one has to be big, which one has to be small...
I am not responsible for the whole disk space filling: the OS put its things wherever it wants whithout me being aware of everything.

I chose the "Security" sub-forum because my partitioning scheme problem is related to security. Otherwise I would have created a partition for "/" and a swap partition and that's all.

It's going to be an applications server, a Web server with databases + files storage.

I've been reading the "Securing Debian Manual" and specially the section about "Partioning the system". (Cf. http://www.debian.org/doc/manuals/se...3.en.html#s3.2) and it looks like this is what is being suggested... but I may be wrong.

Two times my RAM size.

I think it's for "/usr/local" which may contain user installed programs.

Why is that?
"/var" => It's for "/var/log".

It's not going to be a multi-users system.

I'm not using "/tmp".


New question: I am also wondering where I should put the databases and the files repositories on the filesystem.

Thanks and best regards,
--
Léa