Which filesystem?
- Thread starter Verres
- Start date
HFS+ is almost certainly the right choice, unless you basically plan to use only Darwin.
Many Mac applications (even current ones, not just Classic apps) make assumptions about things like case-insensitivity. You will run into a number of small things which break or which you cannot install if you are using exclusively UFS.
There are a small number of unix tools which will break if you're using HFS+, again because of case issues. In particular, LWP installs a tool called HEAD, which it expects to not conflict with head. And as part of the compilation process, python briefly wants to have items named Python and python in the same directory.
The things which are broken by case insensitivity are fewer and more easily fixed. And, fundamentally, (and speaking as an eight-year unix sysadmin) a case preserving, case insensitive filesystem is simply more correct. There is no reasonable reason for which one would want to have File and file be different objects in the same location; people who write software with such dependencies simply deserve to have their crap break.
That being said, here are some benchmarks with which I attempted to compare speeds of the two filesystems. These were performed last April, so keep in mind that they may no longer be accurate.
<pre>
ufs hfs+
____________________________________________________________
copying a lot of small files (~150k)
real 22m0.811s real 26m36.089s
copying one big file (3.9G)
real 8m42.560s real 13m32.281s
removing one big file (3.9G)
real 0m23.894s real 0m0.556s
simple listing of ~150k files (ls -U)
real 0m9.958s real 0m14.998s
attribute listing of ~300k files (ls -lUin)
real 1m30.774s real 1m29.408s
attribute changing of ~300k files (chown conner.wheel, chown root.operator)
real 5m2.574s real 2m38.293s
real 4m59.695s real 2m40.386s
</pre>
The upshot of this is that the each have moderate advantages for some applications, but turn out to be comparable overall.
Methodology for the tests:
This was a 400MHz g4, with a 20G drive on which the system, test script, and
test log were stored, and a 10G drive dedicated to this test. The 10G was on
the same ide channel as the system drive, was initialized as one 10G
partition of the appropriate type before the test, and was empty aside from
the test files.
The 3.9G file was a bunch of mp3s smooshed together. The 300k files were a
bunch of old maildirs, split up into 48 directories, and totalling about 2G.
Both of these are substantially larger than available ram (though the
attributes themselves of the files are probably not).
Many Mac applications (even current ones, not just Classic apps) make assumptions about things like case-insensitivity. You will run into a number of small things which break or which you cannot install if you are using exclusively UFS.
There are a small number of unix tools which will break if you're using HFS+, again because of case issues. In particular, LWP installs a tool called HEAD, which it expects to not conflict with head. And as part of the compilation process, python briefly wants to have items named Python and python in the same directory.
The things which are broken by case insensitivity are fewer and more easily fixed. And, fundamentally, (and speaking as an eight-year unix sysadmin) a case preserving, case insensitive filesystem is simply more correct. There is no reasonable reason for which one would want to have File and file be different objects in the same location; people who write software with such dependencies simply deserve to have their crap break.
That being said, here are some benchmarks with which I attempted to compare speeds of the two filesystems. These were performed last April, so keep in mind that they may no longer be accurate.
<pre>
ufs hfs+
____________________________________________________________
copying a lot of small files (~150k)
real 22m0.811s real 26m36.089s
copying one big file (3.9G)
real 8m42.560s real 13m32.281s
removing one big file (3.9G)
real 0m23.894s real 0m0.556s
simple listing of ~150k files (ls -U)
real 0m9.958s real 0m14.998s
attribute listing of ~300k files (ls -lUin)
real 1m30.774s real 1m29.408s
attribute changing of ~300k files (chown conner.wheel, chown root.operator)
real 5m2.574s real 2m38.293s
real 4m59.695s real 2m40.386s
</pre>
The upshot of this is that the each have moderate advantages for some applications, but turn out to be comparable overall.
Methodology for the tests:
This was a 400MHz g4, with a 20G drive on which the system, test script, and
test log were stored, and a 10G drive dedicated to this test. The 10G was on
the same ide channel as the system drive, was initialized as one 10G
partition of the appropriate type before the test, and was empty aside from
the test files.
The 3.9G file was a bunch of mp3s smooshed together. The 300k files were a
bunch of old maildirs, split up into 48 directories, and totalling about 2G.
Both of these are substantially larger than available ram (though the
attributes themselves of the files are probably not).