Quoting Didier Kryn (kryn@???):

>     Files are stored in different directories, that's it for
> clean bookkeeping. Making these directories mountpoint does not add
> any sort of ordering. Only the impression they are more secure.

Here's a real-world example of ordering using filesystem divisions.
Let's assume a system using spinning rust -- a jocular term for hard
drives, where 'seeking', the process of moving heads between cylinders,
is by orders of magnitude the slowest read or write operation, as
opposed to SSDs, where the concept of 'seeking' doesn't even apply, and
all sectors are equally reachable in the same ultra-quick amount of
time, with no seek delay ever.

Ordering the file trees to minimise average seek distance and time
will thus both speed disk access and reduce wear.

Based on a lot of experimenting by me and others, and occasional but
seldom systematic measurement, a _reasonable_ general scheme for each
spindle is as follows:

Near the middle of the set of cylinders, you put the spindle's swap
partition. On _either_ side of the swap, you put a filessytem tree that
has a high percentage of the system's reads and/or writes_. /var is
one obvious candidate. Others might depend on the role of the machine,
e.g., I tend to have a Web server's public HTML root mounted as /var/www
(as I disagree with recent FHS releases about /srv for this), so it
might go on the other side of the swap. And then, proceeding both
inwards and outwards through the cylinders, other file trees with less
and less average activity. If you have more than one spindle
(unmirrored), then put likewise a swap partition in the middle, and
festoon trees on either side following the same logic.

About the 'impression that they are more secure', the problem with the
word 'secure' in this context is that two speakers will often use it
with entirely different referents in mind.

For example, I might outline for you a partition scheme where /usr is
ext2 and mounted read-only except during package operations and has the
nodev mount option set, /var/lib is mounted nodev, /var/www is mounted
nodev,nosuid, and /, /home /var/spool, and /usr/local have default mount
options -- and your reaction was this gives only the _impression_ of being
more secure, because a system intruder who cracks root can remount
anything as desired to overcome such pitiful obstacles.

But that assumes that 'secure' is intended to mean 'defeats remote
intruders who steal shell and then successfully escalate to system
privilege' -- whereas by 'secure' I might mean, in this context,
something much more modest yet pragmatically useful: The biggest
security threat to any *ix system is a tired and error-prone sysadmin
working at a shell prompt. Anything that makes common blunders less
disastrous without excessive cost is a win, e.g., /usr being normally
mounted read-only averting disaster from an admin recklessly carries out
a command with system authority that crosses into /usr without he/she
intending to. Almost as threatening to systems is misbehaving regular
software. Anything that makes processes going haywire less able to do
harm without excessive cost is likewise A Good Thing. Last, although
it's certainly true that a competent human intruder able to break in and
escalate to root can trivially remount filesystems, most system attacks
and privilege escalation are carried out by fully automated scripts,
and, if they fail because they rely on writing to /usr, it's very likely
they will _not_ be written to debug the problem as mount options and
do a remount and try again.

As usual, words are the problem. Maybe we should switch to interpretive
dance. ;->