Slashdot Mirror
Unix File System Issues on Mac OS X?
rlthomps-1 asks: "I've been thinking about reformatting my Mac's hard drive in UFS, since I've seen the option on the install screen. I was looking for advantages of the Unix file system since it sounds like it would have better performance over HFS+. After viewing this Apple kbase article I wasn't so sure. A test system at work won't install software correctly because the drive name is stuck as '/' among other problems. Why would Apple include the UFS option if it offers such reduced functionality, and is anyone out there using it for non-server applications? What for? Are there advantages to UFS on the desktop Mac OS?"
To my understanding, it's for porting apps that expect UFS.
Also understand that many carbon applications have trouble coping with non-HFS+ file-systems. Here in the lab, I mount my solaris home directory thru NFS, and some carbon apps cannot start from my home directory because of this. Some carbon applications even have trouble with files in this file-system (on bad days Acrobat Reader tells me the file does not exist).
As applications and system frameworks become more file-system agnostic. I suspect Apple will probably put less emphasis on HFS+ and put more effort in other file-systems.
When Darwin was built, Apple used FreeBSD 3.2 has its core BSD os, since then many changes where applied in the UFS code in FreeBSD (softupdates are the ones comes to mind). Since then Apple's version of UFS has not change too much.
HFS+ is Apple's MacOS native enhanced file system. So if you need to run Classic, if you need to run carbonised application that do have a resource fork then you need an HFS+ partition (see Mozilla's readme).
If you're more a unix guy like and want to compile OSS, host some CVS reposiroty then you 'll need UFS.
UFS is case sensitive. HFS+ is not (it might seems to be but is not). I'de say for all macos Apps use HFS+ an create a second UFS partition where you'd put all your unix apps and other unix related stuff (CVS etc
Other references can be found
none Yet.
If you are running a server you most certainly want some form of security. HFS+ is not case sensitive. If you restrict certain files like "Hello" outsiders may be able to get to the same file by calling it "HeLlO" or "HELLO". UFS is case sensitive.
OpenDarwin.org is looking into getting up-to-date UFS with FreeBSD and then maybe UFS2 from FreeBSD -current. I have been one of few people on the opendarwin.org list to respond and the exchange has been good about how to begin. Jordan Hubbard has provided good guidance.... now I just need the time and some help I am sure.
If you are interested... please sign up.
it is primarily to be used if you are running a web server. Apache is better tuned for UFS than HFS+.
Use HFS+ if you are going to use it as a desktop. Many apps including Office will have problems because they expect a HFS+ system supporting Type/Creator info.
I remember back in the day when HFS+ was first introduced... People were wondering if it was worth it. Of course, back then, HFS+'s attraction wasn't speed at all, it was space, since it uses smaller allocation blocks than HFS... Which is almost a non-problem these days with such large harddrives available so cheap. In fact, I question the original HFS, who would design a file system that required a new incompatible file system just to have a different size of allocation blocks? Regards, Adam.
I have UFS for my User partition, and all of the rest of my partitions are HFS+. The reason for this is that, if you boot in OS 9, all of your permissions are ignored, and anyone can waltz into your hard drive and play around. UFS isn't readable by OS 9, so no worries there.
I haven't really had any problems with my setup. Maybe there are some things I'll find the more I use it, but I've had this setup for months, and I haven't really noticed anything. But I certainly wouldn't format my system partition UFS. I tried that once, and it didn't work for non-server use at all. Mostly because, if something went wrong with the hard drive, I didn't have a boot disc that could do anything about it. That probably isn't a problem with things like the new HD tool from Micromat, but at the time it was a pain.
=Brian
There is nothing so good that someone, somewhere, will not hate it.
Do you have a link to CVS issues? I have been running into strange issues with CVS and ssh on my computer... if I run CVS it kills my ability to ssh. If you can explain this I would be overwhelmingly pleased. Link?
o sx/cvsover view.html
Apple:
http://developer.apple.com/internet/mac
led me to belive this should work... but I have been having wierd issues.
I thought along the same lines... It is Unix, so UFS should be better... So, I formatted my iBook and went with UFS.
I was wrong. All of the mac applications run much better under HFS. Things like Appleworks need an HFS partition so they work with OS 9 as well as X. And mozilla still won't run in a UFS partition. As of version 10.1.3 (not exactly sure which one I tried) there were still a LOT of problems with UFS. I got a lot of data corruption on my UFS partition. Also, disk IO seemed a lot slower than with an HFS partition. The system kept getting slower and slower.
Finally, I reinstalled again with HFS. All of my troubles went away. In my opinion, don't use UFS unless you have a really important reason to do so.
The most important reason to stick with HFS+ is that a UFS drive cannot boot back into OS 9, and does not support Classic. (Also, HFS+ is faster)
Reality has a liberal bias
This is qualitative, not quantitative, unfortunately, but I installed OS X on my powerbook G4 with ufs once. The install alone took over an hour. Booting OS X took forever, things started up slowly, I thought OS X was a dog.
Later I was reinstalling OS X (repartitioning the disk a bit) and decided to go to HFS+ because a friend said OS X on his powerbook with the same hardware wasn't nearly as slow as I was describing. I re-installed onto HFS+ and the install only took 20 minutes this time and things ran noticably faster.
Next time, I'll run bonnie++ on both and find out for sure how much slower ufs is than HFS+. Regardless, my qualitative feeling is that OS X's UFS sucks performance wise.
in term of performances HFS+ is better than UFS. In fact, from the quick benches I've done with my FreeBSD's, HFS+ is faster than UFS, and slower than UFS+softupdates (witch is approximatively equivalent to ext2 FS in term of read-write perf.).
Ones should definitively choose HFS+ for OSX, a secondary partition using UFS can be a good idea for UN*X addict, but is absolutely useless for everyday desktop use.
My advice: Do *NOT* use UFS on Mac OS X unless you are running a server. If you plan on using applications besides Apache or database software, use HFS+. I bought a new Powerbook several months ago and went with UFS, assuming it would be faster, superior, etc. I found that many programs (even Mozilla!) would not run on UFS. They'd simply crash or spit out strange error messages. After getting frustrated, I reinstalled using HFS+. I was *AMAZED* at the speed difference. It really is a lot faster: Apps load faster, file copying is faster, everything just seems more responsive. And, I no longer have trouble with software such as Mozilla, Toast Titanium, Dreamweaver, etc.
The bottom line: Stick with HFS.
Why isn't there an effort underway to port XFS to OS X (and NT)?
This would afford one common file system across all modern operating systems. Regardless of architecture, this permits transfer of data from machine to another machine by simply connecting the hard drive (particularly useful for Firewire drives). For common architecture machines, this permits dual booting or simplified data migration. And, it leverages across all operating systems improvements to the XFS file system and file system utilities.
Given Mac OS X's Unix underpinnings, it would seem relatively trivial to port XFS to the OS. The technology is fully journaled, and proven for many years in Apple's target media market.
Here is the issue as I understand it. If you use UFS, you are limited, because UFS doesn't recognize resource forks, therefore you can't use Cocoa or Classic apps. For those of you who don't know, previous to Cocoa, all mac applications (and lots of other files - anything with an icon or that stores a PICT or AIFF for example) had separate resource and data forks. If you put one of these files onto a FAT volume, you will see a hidden folder for resource forks. Since UFS doesn't recognize resource forks, you can't use Classic at all, and can't use Carbon apps. You can use Cocoa everything. The only advantage that I know of for UFS is that it doesn't get fragmented, where HFS+ does. However, this does make it slower in my experience, and you're still stuck using either Cocoa apps, or Darwin, which means that you can say goodbye to most users favorite apps. No Photoshop, no MS Office, no iTunes (The last time I checked, not only was iTunes Carbon, it still had some Pascal code in it). So I guess it could reduce your downtime for maintenance in a server situation, but it's totally impractical for most users.
Karma: Ran over your dogma.
I first installed OS X on a beige G3/300 minitower on March 23rd, 2001. My OS X drive was formatted as UFS and my classic drive was formatted in HFS+.
My private user data was secure when the system was booted to classic plus I never had to optimize the hard drive!
I used this configuration until 10.0.4 when my system began to act eratically. A little poking around reveal that I had no files on my system. All apps, configuration files, library files, user files -- everything but folders -- were gone.
Tens of thousands of files, gone.
I returned to classic, but last fall I decided to troubleshoot my daughter's iBook. She was running ten, standard install, and was happy with it, so I upgraded her to 10.1.1.
I was impressed and thought that the data loss bug had been fixed, so I re-installed OS X 10.1.1 on TWO identical G3/300 minitowers.
I was a very happy users and eventually upgraded both machines to 10.1.4.
Then one Sunday night when I wasn't even home, all the files on my personal computer disappeared, same as the previous summer.
One day later, I remembered that my server was configured exactly like the workstation that lost all its files, so I started poking around.
It, too, had lost all its files except two, which I had recently accessed. More significantly, file losses included mounted HFS+ file systems!
Incidents like these were echoed by Apple customer support staff, unofficially.
I'm not saying every system will have problems like I had with my old computers running UFS, but some machines do.
I lost over 40-gigabytes of files off of six hard drives. The problem is REAL.
I'm now using Red Hat as my full-time personal computer OS.
Retrospect (the backup tool) doesn't support UFS. It silently omits files from the backup if either the source or destination partition are UFS. No warnings, no errors, just a backup disk missing random files.
Apple includes UFS becuase all Cocoa applications will run correctly with UFS, and Carbon applications (if written correctly) will also run correctly. Apple uses its previously published standards (see Netatalk list archive for a discussion) to seperate the data and resource forks. The problem is that many MacOS applications--and the entire classic environment--require HFS compatibility. Many applications will not even install onto a UFS drive. If your environment is mostly Unix, and you are a developer or a web designer, having the same case-preserving, case-sensitive file system symantics that other Unix implementations may be a benifit. Otherwise, stick to HFS+. I, for one, have signed and recommend that other sign the Metadata petition which calls for Apple to move towarsd a modern file system which has multiple streams (as apposed to two fixed streams) and a generalized metadata implementation a la BeFS or Attributed FS to provide the core HFS compatible metadata with the ability to extend the metadata use into new areas. A journaled file system would also be a plus. HFS+ is a reasonably efficient and Unix like file system. The only difference is the case-preserving, case-insensitive file symantics, which is arguably (many discussions abound) is preferable for a GUI, and human UI in general.
A big bonus would be implementing posix compliant multiple stream bsd userland commands like cp so that you don't axe your resource fork when you cp a file from the command line, etc.
When Mozilla 1.0 became available, I formatted my HD as UFS...I had been waiting and waiting to do this just to play around with it. Anyway, it turned out to be a BIG mistake. The first thing I installed was Mozilla. It installed fine, but when I tried to run it, it would quit before the launch was finished. The same happened with Netscape...I thought maybe it was just a "Mozilla-type" thing...I was wrong...I then tried installing MS Office (sorry I turned to Microsoft...I need the compatibility for school)...that installer wouldn't even run...it wouldn't give me permission to install on UFS formatted "/" So then, I reformatted back to HFS+. I reinstalled everything, and since, everything has worked fine...I have even installed mySQL and PHP, and both of them seem to work wonderfully as well. I'm not sure if this will help or not, but when I reformatted as HFS+, I named my HD "/" just like it would have been if I had formatted it as UFS. You may also want to check out the postings by SandSpider and Nachoman...they seem like they ran into problems similar to mine...one of them suggested (along with some others) that you partition the HD so you can have both a UFS partition and a HFS+ partition. Anyway, good luck!
I was trying to get UMN Gopherd running on my OS X box awhile back, and one neat trick that was suggested to me by the maintainer of the package that helped was to use the Disk Copy application to create a virtual UFS device. I dragged the files I wanted to compile into my virtual drive, cd'ed into it, did the make thing, and presto: it compiled beautifully. Even neater is that I could still install it into the standard hierarchy, which was hfs+ formatted, and it still ran just smooth.
So my advice is this: format your drive hfs, and when you need to do a project that requires UFS, simplly create a big enough blank UFS drive using Disk Copy, and do your work in it. Talk about having your cake and eating it too!
...mmmm... cake.....
Something journalled, like ReiserFS. Something cool, like BeFS.
do not use ext2.
HFS+ blows. Im sorry.
You asked about a JFS. Does UFS have soft updates?
one for the line reaper.
That's the most idiotic reason for case-sensitivity I've ever heard. If someone has enough access to your system to get a file in one case situation, they've got enough access to get to anything else in the same directory.
The fact is, I've never heard anyone come up with a good idea for case sensitivity. The only one anyone ever comes up with is, "Well, with case sensitivity, I can have a file named 'Hello' and one named 'HELLO', etc." Hello, that's not an advantage - it's confusing as hell!
Case insensitivity with case-retention is the ideal - and that's what HFS+ has. If Apple would just fix their slow-ass hardware, I'd change over in a heartbeat (assuming I had the $).
The problems of UFS and HFS+ and different types of software stem from the way they deliniate directories. HFS has always deliniated directories with a colon. Your Applications folder is SystemDisk:Applications and home is SystemDisk:Documents or whatever arrangement you have. UFS deliniates directories with a slash. Apple is working towards ditching HFS entirely so they can switch to a more Unix friendly file system when they finally drop support for Classic applications in OSX.
/opt or something. The default BSD tools work fine with HFS+ but third party stuff might not work as well so putting them on a separate partition you know they will work on might be your best bet.
In many cases Darwin project Ports and Fink packages work much better with a UFS partition than they do with an HFS+ partition because they contain absolute paths using slashes for directories rather than colons. Classic and some Carbon applications do the opposite, they use absolute paths with colons. Your best bet is to make an HFS+ partition for your Mac software and then a smaller separate UFS partition to mount as
I'm a loner Dottie, a Rebel.
I'd just point out that many of the "gotchas" referred to in that article refer specifically to problems in 10.0 that have been fixed in 10.1.
echo Prpv a\'rfg cnf har cvcr | tr Pacfghnrvp Cnpstuaeic
OSX's HFS+ and UFS seem a bit antiquated, and they are a pain to read from other machines as well. It would be great if OSX could support ReiserFS. Ext3 would also be a reasonable choice.
while trying to install OS 10.1 on my ibook, i ran into a peculiar problem. i had a UFS partition for the OS X system, and an HFS+ partition which would later become linux. after installing OS X, the machine refused to boot off the UFS partition.
looking back, i'm glad i tried HFS+.
--Muncus.
Don't matter on OS X. :'s it will work. /'s in it's name. If i go to a bash prompt and perform a ls, Darwin knows that the shell can't handle /'s in a pathname and automagically displays them as :'s. /'s and unix apps will see :'s in directory/file names and it doesn't matter what type of file system they live on.
If a carbon app uses a hard-coded path with
If i make a folder on an HFS+ volume called, say, "Documents 15/06/02" it will be saved with the
Basically, it all just works.
Mac apps will see
The only difference you will notice is that files with resource forks can't be stored on UFS volumes and some other apps (ported from unix) prefer to be on UFS volumes so they can play with inodes and other UFS features.
Specialist Mac support for creative pros, Melbourne
Second, I cannot recommend UFS for a root partition. Too many installers rely on the root partition being HFS+. They give errors about not being able to install on a "network file system" (which should be possible regardless). I had my system set up with several UFS partitions and no HFS+ partition at all, and ran into problems trying to install a bunch of stuff I genuinely wanted. So I gave up and made my root partition HFS+.
What I recommend, however, is that only the root be HFS+. My /Users partition is UFS. A couple of other partitions are UFS. I ordered an external FireWire drive and the several partitions I will be putting on it (including /Library, /Applications, and /Developer) will all be UFS.
(For those who are worried about /Library being externally mounted -- I haven't figured out what difference Apple intends there to be between /System/Library and /Library since both seem to be used identically, but I have chosen to treat /System/Library as containing things central to the running system such as StartupItems and Extensions, and /Library to be things related to applications, such as Application Support and Fonts.)
To maintain my various UFS partitions, I have an /etc/fstab and run fsck -p in the Disks StartupItem. I've been doing things this ways for months and it seems to work quite nicely. I will mention that I do not use any Classic applications, so having partitions (such as my home directory) visible from Classic is not a concern. YMMV.
Apple's going to support UFS and HFS+ for years to come, obviously, but by the same token, it should be obvious that apple would be working on a replacement (they hired that beos filesystem guy a few months back, iirc).
Now apple's not going to support a multiplicity of file systems, so they're only going to work on one system; i doubt they'd write their own filesystem, so i'd say that will integrate XFS.
UFS was included for those few people who needed a real, genuine, Unix file system. It has the "real inodes" and the case sensitivity that Unix apps expect. But (as far as I know), directories are stored as files with a special attribute, all over the disk, just like the MS-DOS FAT file system does. It does things this way after all this time because that's the way Unix has always done things.
HFS+, however, is an extension to HFS to give it a few extra things that it needed to become a serious file system. Stuff like support for volumes larger than 2G, really long file names, Unix file attributes, etc. HFS stores directories in a B-tree file. In other words, it uses a database. This is much more efficient than a bunch of scattered files and inodes holding directory information.
Basically, if you don't know a specific reason why you need UFS, don't use it.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
I got myself a G4 as a workstation about six months back. Being new to both OS X and the Mac world, I chose to format my partitions as UFS. BAD move. A lot of software simply refused to work (Mozilla being an example) if started from an UFS partition. Others (like the Harpoon 3 Demo) worked if I did some tweaking. Since OS9 doesn't know anything about UFS volumes, I was deprived of Classic apps as well (not that I have really needed any, but anyway). All this was a pain in the ass, though. For a long time I thought the software I tried was badly coded, but soon realized that it was due to my partitions being UFS only.
Today I finally found the time to repartition as HFS+ and everything works like a charm. Finally I have a decent browser instead of that Microsoft crap. :-)
To summarize: don't do it, unless you really, REALLY, REALLY know what you are doing.
Just my .02 €
From the 1.1a release notes:
Mac OS X: Mozilla will not run when the application is installed on a UFS partition. The workaround is to move the application folder to an HFS+ partition and it will run correctly.
So you could just make a HFS+ Disk Image, but that's just a pain. And what about mounting your hard disk in OS 9? No dice. I say keep the HFS+ scheme.
Orange
I can think of for most users to use UFS is if they want to make absolutely sure nothing in their OS X volume can be accessed by booting in 9, since 9 can't read UFS. But with all the other issues, it might not be worth it...
I've read all the usual arguments to use either UFS or HFS+, but the main reason I use HFS+ is it supports FileIDs. Thus Aliases don't break when you move or rename the original file. This is a huge human interface advantage.
I also suspect iterating directories is faster with HFS+.
I'm hopeful somebody will develop a better filesystem which also supports FileIDs. HFS+ has a couple problems like fragmentation and corruption when interrupted. However Disk Warrior and Plus Optimizer fix those problems.
>80 column hard wrapped e-mail is not a sign of intelligent
>life
when Office X first came out, I tried to install it onto my UFS beige G3 and the installer said I couldn't install onto that machine because it was a server, but a more recent version went on OK.
Just a warning, if you do want to use UFS there is a bug in the mozilla code base that will prevent mozilla and netscape 6 from running on a UFS partition. Also various apps have little problems i have run into, for instance the quicken installer doesnt work, but the app does. Chimera and omniweb work tho, so at least you wouldnt be stuck with ie!
Later,
Phil
One example of why cas is important. The http interface perl scripts 'HEAD', 'GET', and 'POST' get installed with a number of packages. The 'head' command is used for reading the first few lines of a file. I use 'last|head' to see who has logged in recently. After installing the perl mods, that command freaked. It took a while to realise that 'HEAD' had replaced 'head' -- forcing me to find a new 'head' from another system. I renamed 'HEAD', 'GET', and 'POST' be preceding their names with 'HTTP_'.
t'nera semordnilap