How necessary is it to reserve 15% disk space?

scruffy said:
This is why I would never run OS X as a production server that I relied on to make a living - if the log files can steal my swap space, this is a real problem.
Curious... the worse case I've seen happened on a system running Mac OS 9 with AppleShare IP 6.3. This is an HFS+ issue and not a Mac OS X issue.

Further, I would never set up a Mac OS X Server system with the OS installed on a partition that was being used for file sharing... that is just asking for problems.

As for the reliability of Mac OS X Server, it is leaps and bounds beyond what I've seen with AppleShare IP and Windows NT servers.

I have two Mac OS X Server systems (10.2.8) that have been running flawlessly for more than two years in a production environment. Now I know I have a ton more experience with Mac OS X Server than most people, but these systems are running unattended and are completely problem free.

I don't know what kind of work you do for a living, but I highly doubt it would tax Mac OS X Server.
 
IMHO, Apple should ditch HFS+ and use UFS. Sure, UFS on OS X is slow, but that's because it's v1 (or something ) instead of V2 as used by FreeBSD. Also, there's ReiserFS that's free and performs very well. It's also B-Tree based so that should make it more similar to HFS+.
 
I only have 6GB at the mo.

It's really odd. Everytime I wake up the laptop from it's forced sleep (still won't sleep when I close the lid) it's missing a few GB...
 
RacerX is it a problem on HFS as well or just HFS+? Does Apple admit to this problem? Is the root cause known? i.e. is it the autodefragging as an example.

It baffles the imagination that a problem of this nature has existed for years without correction or at least a safety net to prevent catastrophic data loss. I have no reason to doubt it though, a little searching shows that it is a commonly held opinion. Of course Apple does have a bit of history of ignoring problems in the hopes that they will go away. (iBook mainboard problems, the light spots on the LCD, etc...)
 
Convert said:
I only have 6GB at the mo.

It's really odd. Everytime I wake up the laptop from it's forced sleep (still won't sleep when I close the lid) it's missing a few GB...

I think that's because Macintosh systems that support "deep sleep" operate similarly to Windows' "Hibernate" function -- that is, any data in RAM is written to the hard drive (so if you've got 1GB of RAM, I would assume about 1GB of data is written to disk, presuming all 1GB is being used) and electricity does not flow through certain systems (RAM, processor, etc.). When you wake up, the data is read back into RAM from the disk, and I don't know if it's erased after that or remains around a while afterward...

Can anyone confirm this?
 
Mephisto said:
RacerX is it a problem on HFS as well or just HFS+? Does Apple admit to this problem? Is the root cause known? i.e. is it the autodefragging as an example.

It baffles the imagination that a problem of this nature has existed for years without correction or at least a safety net to prevent catastrophic data loss. I have no reason to doubt it though, a little searching shows that it is a commonly held opinion. Of course Apple does have a bit of history of ignoring problems in the hopes that they will go away. (iBook mainboard problems, the light spots on the LCD, etc...)

If you refer to the thread I pointed to at the start of this topic, you'll see that HFS was even worse than HFS+. No idea if Apple thinks this is a problem or not. It definitely is inconvenient and I wish Apple would move to a different filesystem.
 
I read it yesterday when you first posted it, then did further research to corroborate the statements. I saw the comments to the effect that HFS suffered from the same problems but saw little backing that up elsewhere. Given the average Apple user's use of voodoo mechanics to diagnose errors I asked someone who seems to have experience and technical ability (RacerX) his opinion. I do not doubt your technical ability but the fact that you asked the question tends to suggest to me that you have little useful to say in the matter.

I would rather see Apple correct the problem than dump HFS+. ReiserFS might be better but that does not mean porting the FS to Mac would not cause new problems. I have never been fond of dumping a technology just because it has a likely fixable flaw.
 
Yeap. I've got very little useful things to say on HFS+ since I've never really had reason to delve too deeply into the underlying kernel of OS X. What makes things more frustrating is the lack of documentation on Apple's part too. So unless someone goes through the Darwin source code, we may never know for certain.
 
Viro said:
What makes things more frustrating is the lack of documentation on Apple's part too.
Maybe this will help on the documentation side of things.

Viro said:
IMHO, Apple should ditch HFS+ and use UFS. Sure, UFS on OS X is slow, but that's because it's v1 (or something ) instead of V2 as used by FreeBSD. Also, there's ReiserFS that's free and performs very well. It's also B-Tree based so that should make it more similar to HFS+.
The problem is legacy applications. Pretty much anything done using Carbon is going to require HFS+ (that includes the Finder). What is worse is that there is now enough mixing between Carbon and Cocoa that even Cocoa apps have enough Carbon calls to slow them down on anything other than HFS+.

As for the UFS that Apple is currently using, it was developed from NeXT's UFS. There were a number of versions, each different from the previous version. The first Rhapsody systems used a file system that was not compatible with OPENSTEP systems (and the PowerPC version was not compatible with the Intel version). Apple then made another step with the next release of Rhapsody, but hadn't gotten what they wanted (something like HFS+ was what they were aiming for). With the release of Mac OS X Server 1.0 (the first public version of Rhapsody) they ended development of their UFS and turned back to HFS+ with Mac OS X.

I love my Rhapsody systems (as most people know) but UFS (even after all of Apple's work with their version) is no where near as advanced as HFS+. I think Apple made the right choice. In the end the benefits of HFS/HFS+ far out weight the draw backs.

When discussing this with other consultants, the thing we would like to see Apple add to Mac OS X for now is a space warning when the disk is starting to fill into that danger zone.

Having read the thread that was linked, I would concur with their assessment... keeping in mind that the 15% rule is a soft limit and not a hard barrier.

My main system is short on space, it has two drives, 8 GB and 4 GB, and I have to burn stuff off or move things to my servers regularly. Still, I have a wonderful system that has had a perfect performance record over the last two and a half years. I have not had to do any maintenance on it at all. Yes, I sometimes run short of the 15% limit, but I try to not do it too often or for too long.
 
Down to 3GB this morning, now back up to 7GB. Rebooted to get a 'fresh' number, I have 4.13GB apparently. This is bugging me.
 
adambyte said:
How necessary is it that you have your data? ;)

Now now, no need to be cheeky ;) it turns out that 15% is a soft limit anyway, more like a recommendation than a requirement.
 
Kind of like the speed limit, right? You can go over it if you like, but you then you'd be out of place to complain when you're stopped and ticketed. ;)
 
I usually store my files on external drives so I can leave my working/internal drive with as much free space as possible. Seems to make things perform better.
 
It looks like the solution is to keep the drive defragged, make backups, and leave a reasonable amount of free space.

Doesn't seem unreasonable.

Doug

EDIT: Or get a Windows machine, right Viro? ;) That'll solve ALL your problems.
 
dktrickey said:
It looks like the solution is to keep the drive defragged, make backups, and leave a reasonable amount of free space.
I'd say defragging a drive is a bad idea. HFS+ (and Mac OS X) is designed to have a certain amount of disk fragmentation to protect against file fragmentation. Defrag utilities only care about making the drive look good, your actual files it could care less about.

Yep, if you don't have problems now, defragging is as good a way as any to create some.

Oddly enough, over the past 6 years the only people I work with who have had file system issues have been those who (against my recommendations) defrag their drives. Could be a coincidence... and then again. :rolleyes:
 
I gotta agree with RacerX. I think more problems than most think are created by being too proactive. Defragging a drive is useful for media drives, like those used to store/capture large, high-quality video/audio files... access time can be sped up, and in some cases of very high-definition video, is beneficial.

However...

Defragging a system drive is a bad thing in my opinion. The files that the system accesses aren't in sequential order on the disk drive, but OS X has built-in mechanisms to make sure that commonly used files are located together on the drive ("adaptive hot-clustering"). Defragging the drive screws up that system, leading to possibly decreased performance. OS X will put the files where it likes them -- fragmented across the drive, if it feels the need. Defragging the drive just puts the files somewhere else, and OS X starts the whole moving-files-around-the-boot-drive process again. Why work against the OS?

OS 9 didn't have adaptive hot-clustering (or whatever), so defragging the drive could possibly lead to increased performance. If you never copied any files or deleted any files, the drive would stay fairly unfragmented for quite a period of time afterward. Not so in OS X. Defrag an OS X drive, and you'll find it quickly reverts back to a more fragmented state in a matter of days.

Don't do it, people. Repair permissions once in a while, repair the disk once in a blue moon, and use quality RAM. While my experiences may be atypical, I use no anti-virus software, haven't repaired my drive in almost 8 months, repaired permissions only after a software update, reboot only when software updates require it, keep 15GB of a 40GB boot drive free, and I log out when I'm not using the computer (I also let it sleep all night, and run the daily/weekly/monthly cron jobs only about once every two months or so... maybe longer). No problems, whatsoever, at all.
 
RacerX said:
Curious... the worse case I've seen happened on a system running Mac OS 9 with AppleShare IP 6.3. This is an HFS+ issue and not a Mac OS X issue.

No, it's a partitioning scheme issue, completely independent of the filesystem used.

The problem is, swap space exists in the same filesystem as regular files - /var/vm is in the same disk partition as /var/log. That means an attacker who could cause lots of logfile entries, could eventually cause you to lose that magic 10 or 15 percent of the disk - they could even cause the OS to be unable to allocate more memory, period.

In other Unix OS's, (including FreeBSD, incidentally), the swap space is completely separate from the filesystem space on the disk - it doesn't show up at /var/vm, or anywhere else either.

A typical partitioning scheme will also separate /var from the rest of the filesystem altogether (as /var is given to growing suddenly and unpredictably), an usually /home or /Users or whatever (as users' storage needs always grow and never shrink).

Now, as I mentioned, I don't know what partitioning options Server gives you. If you can easily designate a separate disk partition to mount at /var/vm, great - no worries.

I'm sure your servers have been working fine for you, and for most or all of the thousands of other people who use OS X Server in production. That's the thing with security - the problems don't show up at random, they only show up when someone reaches out and _makes_ them show up, which could be tomorrow or never.
 
Is there any way to make /var/vm a partition on it's own? I remember on Windows I used to have the swap file on a different partition, and at a fixed size. If I could either a) fix the size of the swap file or b) more the swap file to a different partition, I'm certain this issue will be minimized and I won't have to worry about this 15% hard limit.
 
Back
Top