Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'Why UNIX partitions exist ....' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Why UNIX partitions exist ....
Authored by: lerici on Jun 24, '07 07:33:55PM

I found your note about the use of swap partitions interesting ...

yet ...

Having used UNIX systems for nigh on 25 years + ...
I would ask you the following:

1. Do you think its secure to have constantly changing, dynamic data
on the same partition as your "crown jewels"? The static root files, your
root partition's vm kernel, critical shared libraries and applications?

2. Ask yourself given the nature of the beast (i.e. hard disks) if this
is a safe thing to do? Have this dynamic area on the same partition with
your critical user specific data as well? VM unix and root entities are easily recreated from install disks ... separate from the security issues.

3. Do you trust HFS+ journaled case sensitive or insensitive file systems? I sure don't.

So ... that said one should at least put the User directory on a separate partition. If you have enough expertise so should /private/var. /tmp should be linked to /var/tmp on that separate partition. Finally swap should live separately allowing the root entities, the "crown jewels" to
remain reasonably static. You should also try to use UFS partitions where and when you can.

Finally think about what you said ... that VM swap uses all the rest of the free space on the volume ... do you think that is safe? Make a swap partition at least 2-3X times the size of your physical memory. Better safe than sorry ... especially if you own a macbook or powerbook.



[ Reply to This | # ]
OS X Partitions: UFS vs. HFS+
Authored by: lerici on Jun 27, '07 02:26:56PM

The problem with the single partitions assumption it appears to fail to take into account Mac OS X virtual memory system. It takes advantage
of empty space on the single partition most users have for paging activities. This is very similar to what Apollo Domain/IX used to
do. IN fact the empty regions of the disk were used to turn the entire network of nodes into a sort of VM area. Access to remote
node's disks would it to be mapped to the local node's VM area. Very, very "kewl" for 1980's technology. Fairly object oriented
as well.

What happens when the disk becomes full of files? Wouldn't it then begin to slow down? The bottom line on this sort of VM
system is that you can really only use 80% of the disk before performance degradation, and perhaps even failure might occur.

Thus making the use of non-fragmenting UFS file system enticing.

A better "disk utility" would take full advantage of UFS file systems and the inherent tuning associated with them. Perhaps it would
create special small partitions for swap and /private/var. Var means VARIABLE and thus constantly changing. The same would
be even truer for the swap / paging area. Swap may be a misnomer as paging of small blocks occurs. Actually swapping the entire
physical memory out could possibly occur through the use of very large applications and associated data files. Its hard to know
when the memory management algorithms would decide to do this.

Reliability is an issue. HFS+ file systems can be fragile and easily corrupted when they become full because of the way they
are organized. And the performance in the age of large file systems, many, many small files plus large files does not appear
to be significantly better than UFS.

IN my humble opinion the only way to take full advantage of Mac OS X incorporating both performance AND reliability would be
to judiciously mix and match HFS+ journaling (case sensitive preferably) with the fast Berkeley fast file system.

Plus smaller partitions take less time to defrag. And to backup. One can alter the rc scripts to take advantage of hfs_fsck and fsck to prune and repair the file systems between reboots. I have found that this makes the use of utilities such as Disk Warrior less frequent. For UFS file systems they aren't required at all.

One could also assume that striping across file systems would be safer using UFS as opposed to HFS+.

Disk utilities NEED to TAKE advantage of UFS particularly with advent of technologies like XSan on the server side. I believe
that someone should study this issue. Since the issue of NIH is a deal breaker within Apple it would be best done through
a research grant to some University such as Berkeley or Carnegie Melon.

- Peter Brewer



[ Reply to This | # ]