Apple readies Panther Server, a forthcoming update to Mac OS X Server. Version 10.3 will feature improved management capabilities and support for Windows networks, add a variety of services including a new edition of the QuickTime Streaming Server. Read the rest at ExtremeTech.
Apple Readies Mac OS X ‘Panther’ Server Upgrade
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
The upgrade will support…file systems up to 16TB, case-sensitive HFS+ and a journaled file system, which made its first appearance in Mac OS X 10.2.2.
Why does Apple continue to hack away at HFS+ instead of simply moving to UFS2 + soft updates? Ignoring the crufty design, the main problem I see with HFS+ is performance, especially with journaling enabled. Contrarily, not only do soft updates bolster performance, they help to maintain filesystem consistency.
Some features have to do with how efficient the file system is—how the underling structure is designed. Other with fetures exposed to the user. For example:
File name:
255 Unicode characters in HFS+. cf 20 ASCII in HFS, 11 ASCII in FAT16
(?). UFS is 255 ASCII I think. Case preserving in HFS+ (like NTFS, FAT and others). cf case sensitive in UFS, ext2/3, ReiserFS and most Unix/Linux FS.
Metadata:
E.g. User/group/system permissions. Creation/modify/access/backup date. Owner (user/group), file type/creator. inode. File ID, etc etc.
This was a big thing in HFS->HFS+. While HFS had file type/creator, it lacked all the Unix ‘ownership’ information. When Apple designed HFS+ they made it able to supoprt all the Unix permissions—long before it was settled that Unix was what the new Mac OS would be based on.
Multiple forks:
I.e. resource and data. NTFS and Novell (NWFS, NSS) also offer this (NTFS allows an arbitrary number of forks). NOT to be confused with Metadata. UFS simulates this with some artful renaming. Mac OS X packages are aiming to obsolete this anyway.
File size:
TB in HFS+. GB in HFS. Depends on whether fields in the file structure are 64 bits or 32 bits. Very difficult to fix without radically changing the file system.
Journalling:
HFS+ supports it, as do ext3 and ReiserFS on Linux, and UFS on FreeBSD (but not on Mac OS X).
File structure:
HFS+ is a B-Tree based system—as was HFS. This is considered a Good Thing and is one of the claims to fame of ReiserFS. The new Novell NSS is also B-Tree, the old NWFS not.
Implmentation:
Sun optimises UFS to make it run very fast, where Linux abandoned it in favour of better (ext2/3, Reiser, xfs) fundamental design. FreeBSD also gets great performance out of ufs, but is replacing it with ufs2. MacOS X suffers from very much less fragmentation than Mac OS, even on HFS+.
In summary—use HFS+ on Mac OS X. The only thing UFS, in the current Mac OS X implementation, offers that HFS+ does not is CaSe SeNsItivitY. HFS+ is, in absolute terms, quite a good file system. Its implmentation could be improved of course, but that is probably a truism for ANY OS
and file system.
1) It has a proven track record at Apple.
2) A lot of of programs expect it.
3) It’s easy to expand: 16TB, Journaling, Unix Security,…
4) It’s DB like. They use a B+Tree file layout which supports extentions and multi-indexes for speed. This combined with the kQueues is the concept behind the new Quick search options in Finder coming with 10.3.
All that aside, they really need to look at improving it’s performance…
Another good FS for them would be Reiser. UFS or UFS2 wouldn’t work verfy well because they would need to build a DB like structure on top of it.
Metadata:
E.g. User/group/system permissions. Creation/modify/access/backup date. Owner (user/group), file type/creator. inode. File ID, etc etc.
Yes, but nothing of modern extended attributes such as ACLs, which are quite a common feature nowadays.
Journalling:
HFS+ supports it, as do ext3 and ReiserFS on Linux, and UFS on FreeBSD (but not on Mac OS X).
Solaris supports UFS journaling. FreeBSD does not. FreeBSD uses soft updates, which are essentially the diametrical opposite of journaling, to maintain filesystem consistency but also to improve performance on metadata intsenive operations.
File structure:
HFS+ is a B-Tree based system—as was HFS. This is considered a Good Thing and is one of the claims to fame of ReiserFS. The new Novell NSS is also B-Tree, the old NWFS not.
ReiserFS uses a b+tree. In b-trees, data and forward pointers stored in all of the nodes of the tree (with the exception of leaf nodes, which have no forward pointers). In b+trees all data in the leaves. Because of this, b+trees have far greater fanout, as the internal nodes are purely pointers with no space in them consumed by data. B+trees also have far fewer internal nodes, and this means that internal nodes are far more effectively cached in a typical computer configuration. B+trees are much higher performance than b-trees for that reason.
FreeBSD uses the Berkeley Fast Filesystem, which organizes data into cylinder groups. Files that are likely to be accessed together, based on their locations in the filesystem hierarchy, are stored in the same cylinder group. Space was conserved through block fragmentation, and the algorithms were improved to prevent fragmentation of the free list. Overall filesystem throughput was improved, as was space utilization.
FreeBSD further improves performance by maintaining a throw-away in-core data structure for large directories, allowing all operations to be performed quickly without the need for linear searches. It uses a hash array that maps filenames to the directory offset at which the corresponding directory entry exists. A simple spillover mechanism is used to deal with hash collisions, and some extra summary information permits the quick location of free space within the directory itself for create operations.
And HFS uses a b-tree… isn’t that great…
Sun optimises UFS to make it run very fast,
Unless journaling is enabled
where Linux abandoned it in favour of better (ext2/3, Reiser, xfs) fundamental design.
ext2 is one of the most atrocious filesystems ever created.
FreeBSD also gets great performance out of ufs, but is replacing it with ufs2.
UFS2 doesn’t alter the filesystem design itself that fundamentally. It provides for enhanced soft updates (i.e. the filesystem’s virtual state is kept consistent with what operations have been performed in userspace, as opposed to UFS where the filesystem’s apparent state changes as metadata operations are actually flushed to disk). UFS2 also provides a fully 64-bit filesystem implementation with better support for extended attributes like ACLs.
MacOS X suffers from very much less fragmentation than Mac OS, even on HFS+.
But you think it’s on par with FFS?
The amount of design work that has gone into UFS2 (and historically in UFS) greatly transcends the work that Apple has put into HFS+. Apple does have Dominique Giampaolo, one of the best and brightest minds in filesystem design, working for them. However, to leverage him properly Apple needs to scrap HFS+ entirely and allow Dominique to design a modern, 64-bit journaling filesystem with proper support for extended attributes.
At the present time they are only fighting their own legacy. HFS+ journaling is tacked on as an afterthought, as are many of the other modifications Apple has been making. As I stated before, HFS+ is simply slow. Its design and implementation are not the least bit performance minded, especially in regards to journaling.
Thus I will still regard HFS+ as one of the biggest drawbacks to OS X, especially for use on a server.
1) It has a proven track record at Apple.
It has a terrible reputation.
2) A lot of of programs expect it.
On OS X server?
3) It’s easy to expand: 16TB, Journaling, Unix Security,…
Yet it lacks ACLs…
4) It’s DB like.
In exactly what way is HFS database like? Please give an example of a database-like operation that you would perform on a filesystem.
They use a B+Tree file layout which supports extentions and multi-indexes for speed.
Nothing I can find shows that HFS uses a b+tree implementation. Most everything states that it uses a b*-tree, which simply alters the behaviour in dealing with a node that contains an excess of data (which isn’t possible in a b+tree, as b+trees only store data in the leaves)
This combined with the kQueues is the concept behind the new Quick search options in Finder coming with 10.3.
kqueues provide a mechanism for passing events from kernel to userspace. The fast searching would be provided by maintain a separate structure representing the filesystem’s contents optimized specifically for searching. kqueues would be used to ensure that this structure is kept consistent with the underlying filesystem by monitoring VFS events for metadata changes and updating the structure accordingly.
All that aside, they really need to look at improving it’s performance…
Why not improve the performance and add modern features like ACLs and soft updates by supporting UFS2?
UFS or UFS2 wouldn’t work verfy well because they would need to build a DB like structure on top of it.
The main issue with UFS, the handling of resource forks, was solved by Apple, who stored them in dotfiles. This is actually advantageous in some respects, as Unix archiving utilities like tar will actually be able to store resource forks when using UFS, as opposed to HFS+ where tar would simply discard them.
Regardless, resource forks are a bizarre and antequated concept. Can you name any software for OS X server that depends on them?
Before Mac OS Xand Carbon, application resources were put in the resource fork of the application executable. That policy has now changed. In Mac OS Xand for Carbon applications generally, resources should be put in the data fork of a separate resource file, not the resource fork of the executable.
The Carbon APIs now read and process resources in a resource file’s data fork as if they were in the resource fork. (In fact, the system routines that read resources—which are primarily Resource Manager functions—now do most of the work for you.) If application resources are stored in the resource fork, you can use these APIs to access them, but now you must explicitly specify the resource fork in order for this to happen.
The primary reason for moving application resources out of resource forks is to enable applications to be seamlessly moved around different file systems without loss of their resources; this would include methods such as BSD commands, FTP, email, and Windows and DOS copy commands. Most other computing environments, including the Web, recognize single-fork files only, and tend to delete the resource fork of HFS and HFS+ files.
Even though Apple now recommends storing resources in the data fork of a resource file, this—by itself—is an incomplete solution.
Although Apple supports the all-resources-in-one-file model, it strongly recommends that developers put their resources in separate files. One consideration behind this is the emerging use of XML as a way to specify resources. Carbon has an XML-based runtime that tools such as Interface Builder use to export user interfaces as XML.
As with applications, documents on Mac OS Xshould have their resources put in the data fork. The reasons for this are the same as the reasons for having application resources in the data fork. It makes it possible to exchange these documents, without loss of resource data, between Macintosh and non-Macintosh systems, including most Web servers.
Files residing on HFS and HFS+ file systems have their Finder attributes stored in a private fork separate from both resource and data forks . These attributes include type and creator codes. Mac OS Xmaintains these attributes because they enable the Finder to enhance the user’s experience. At the same time, however, Apple strongly encourages developers to use file extensions as alternative means for identifying document types. Mac OS Xdoes a very good job of recognizing and handling document extensions.
If you copy an HFS or HFS+ document to a different platform (including Web servers), file extensions help ensure that the document’s type information is preserved.
If microsoft did this of upgrade scam there would be an uproar. But apple zealots will be quick justify anything that apple does.
The software and features get better with each iteration and MacOSX Server is very cheap when you factor in the expensive client license access fees that MS charges.
“If microsoft did this of upgrade scam there would be an uproar. But apple zealots will be quick justify anything that apple does.”
You make it sound like Panther isn’t going to be a massive update.
Sounds like an interesting product, and for primarily Mac networks, it sounds like it could be a good thing.
However, for an admin that knows what he (or she)’s doing, something like FreeBSD, or NetBSD if you have only Mac hardware laying around, seems like the better choice for a server operating system.
I just don’t see any advantage to using this unless:
1.) You don’t know UNIX very well
2.) Your network is almost entirely Mac
3.) You’re an Apple Zealot
To each their own
4.) You don’t have much time to set up a server
“2.) Your network is almost entirely Mac”
Why would this make any difference?
Apple’s providing a very cost effective, powerful server that offers the GUI advantages that Microsoft brings to the table, with the stability advantages that Unix brings to the table.
A better numbered listed would be why you shouldn’t use it.
A better numbered listed would be why you shouldn’t use it.
Okay, I’ll oblige…
1.) Unproven
2.) Slower than alternatives
3.) Less powerful
4.) Less scalable
I forgot one…
5.) More expensive than *BSD/Linux
“2.) Slower than alternatives”
Sorry bud, this has been proven otherwise.
“3.) Less powerful”
More powerful
“4.) Less scalable”
more scalable
“2.) Slower than alternatives”
Sorry bud, this has been proven otherwise.
“3.) Less powerful”
More powerful
“4.) Less scalable”
more scalable
What are you comparing this to? I wasn’t comparing it with Windows if that’s what you’re thinking. I was comparing it with Free/NetBSD and Linux.
And if you can prove that OS X Server is better than those OSes with something credible, I’ll eat my hat.
Ok, this might shock you, but Mac OS X server is a BSD. Tools, libraries, daemons are pretty much all ported from FreeBSD (and some from netbsd). A big chunk of the darwin kernel is ported from FreeBSD, security model, filesystem, networking,..
Exactly how is FreeBSD/NetBSD/Linux more scalable and powerful? Or did you read those nice buzzwords on the internet, and thought it would sound cool in your comments?
And yes, FreeBSD/Linux is cheaper than OS X Server.. If you are a student, and your time is worth nothing.
Ok, this might shock you, but Mac OS X server is a BSD. Tools, libraries, daemons are pretty much all ported from FreeBSD (and some from netbsd). A big chunk of the darwin kernel is ported from FreeBSD, security model, filesystem, networking,..
Exactly how is FreeBSD/NetBSD/Linux more scalable and powerful? Or did you read those nice buzzwords on the internet, and thought it would sound cool in your comments?
Actually, I am well aware that Mac OS X server derives its userland and some of its kernel from BSD. However, much of the kernel is based on Mach, which has never been known to be a performance champion.
All I can say, is that from a strictly technical perspective it appears to be an inferior server.
Ease of use, however, appears to be very nice.
It just depends on what you’re looking for in a server I guess.
A microkernel such as mach is indeed not very performant.
Darwin which is based on mach, is not a microkernel though, using a shared memory space. Thus avoiding the performance trap of the microkernel.
<< “2.) Slower than alternatives” >>
< “Sorry bud, this has been proven otherwise.” >
Sorry bud, you’re wrong.
[i]”What are you comparing this to? I wasn’t comparing it with Windows if that’s what you’re thinking. I was comparing it with Free/NetBSD and Linux.”
“powerful” is a term used to describe how much power one is capeable of wielding. in the case of operating systems its a relative term thats specific to the job at hand. When you simply said it was more or less powerful, i was simply thwoing the overgeneralization back in your face.
“And if you can prove that OS X Server is better than those OSes with something credible, I’ll eat my hat.”
Each OS has their strengths and strongly believe in the strengths that Linux BSD AND OS X has. I was simply trying to minimize the damage that your overgeneralization had made.
It is OK to be critical of any OS. However, this is the best server OS Apple has EVER made. They are new at the server thing, but they are being extremely productive. With many times the resources, it took microsoft a much longer time to get NT ready for serious use. In time, I think it will be a great OS! The first friendly *NIX, that anyone can use. As it stands now, Windows is probably the easiest to use for someone that doesn’t know what they are doing. Apple is trying to make a Server OS usable for non GURU Geeks like ourselves. I think it has a lot of potential.
Steve Jobs also owns Pixar and seems to be interested in moving all of Pixar’s operations (rendering farms, animation desktops, etc.) onto the Apple platform. If XServe doesn’t quite cut it right now in terms of scalability, reliability, etc., it is not going to be very long before it does.
Apple is on the hunt for some of the market that traditionally belonged to SGI, just like this Boxxtech outfit (using Linux)… http://www.boxxtech.com/
Pixar is essentially going to be a big, real-world testbed for the future of Apple’s product capabilities, IMHO, and I am expecting big things from OS X Server in the future.