|
|
Future of HFS on Intel Macs?
|
|
|
|
Forum Regular
Join Date: Feb 2005
Location: Paris, Fr
Status:
Offline
|
|
When OS X was introduced, I remember to have seen many people disappointed with Apple's choice to stick with HFS instead of building a "next generation" file system - or at least something newer, based on UFS. IIRC, the main grief with HFS is that it still has 68X code in it and that it is hardly mulithreaded. On the other side, it seems to have been evolutive enough to build Spotlight on it along modern requisites for filesystems (journaling, case sensivity...).
If it has still older code in it, however, does it mean that HFS will be unusable on intel Macs? The first feedbacks on developer machines mentioned they had a special version of HFS, named HFSX (IIRC). I am no techie but it would seem logical to jump on the occasion of the switch to Intel to build a much more powerful file system, not just to update parts of HFS that are incompatible with x86. Has anyone information on this matter? How is behaving HFS+ next to, say, NTFS? What are HFS shortcomings? How could Spotlight and OSX gain advantage from a new FS? Is still the famous BeFS hero (Dominic Giampaolo, IIRC) working for Apple?
Thanks for your answers!
|
|
|
|
|
|
|
|
|
Addicted to MacNN
Join Date: Jun 1999
Location: Las Vegas, NV, USA
Status:
Offline
|
|
I think you are misinformed. Files systems are not tied to a particular processor any more than html or ascii are. It is what its name says...a "system", a method of storing files. There isn't any code in a file system itself. The operating system implements the file system in code, and that can be written for any processor. Intel Macs will read and write to HFS just fine.
Chris
|
|
|
|
|
|
|
|
|
Addicted to MacNN
Join Date: Aug 2004
Location: FFM
Status:
Offline
|
|
There is no 68k code in Mac OS X. Most definitely the Intel Macs will be able to perfectly read and write HFS+ volumes.
|
|
|
|
|
|
|
|
|
Dedicated MacNNer
Join Date: May 2004
Status:
Offline
|
|
Anyone can access HFS volumes on x86 today. Darwin has always been available for x86, and there are numerous HFS-readers for the dreaded Win32!
|
╭1.5GHz G4 15" PB, 2.0GB RAM, 128MB VRAM, 100GB 7200rpm HD, AEBS, BT kbd
╰2.0GHz T2500 20" iMac, 1.5GB RAM, 128MB VRAM, 250GB 7200rpm HD
http://www.DogLikeNature.com/
|
|
|
|
|
|
|
|
Admin Emeritus
Join Date: Oct 1999
Location: Zurich, Switzerland
Status:
Offline
|
|
HFS+ is a damned good file system. I will grant you that NTFS is a great file system as well (true journaling is a great thing), but HFS+ has scaled well, and its performance is great.
tooki
|
|
|
|
|
|
|
|
|
Dedicated MacNNer
Join Date: May 2004
Status:
Offline
|
|
Originally Posted by tooki
HFS+ is a damned good file system. I will grant you that NTFS is a great file system as well (true journaling is a great thing), but HFS+ has scaled well, and its performance is great.
tooki
Totally agree. Just look what Apple have managed to squeeze into it in Tiger without any modifications. Of course I'm talking about Apple's nascent meta-data efforts.
[FONT=Courier New]mdls[/font] hints at the kind of things that can be squeezed into HFS+!
|
╭1.5GHz G4 15" PB, 2.0GB RAM, 128MB VRAM, 100GB 7200rpm HD, AEBS, BT kbd
╰2.0GHz T2500 20" iMac, 1.5GB RAM, 128MB VRAM, 250GB 7200rpm HD
http://www.DogLikeNature.com/
|
|
|
|
|
|
|
|
Addicted to MacNN
Join Date: Mar 2000
Location: London, UK
Status:
Offline
|
|
Originally Posted by kilechki
IIRC, the main grief with HFS is that it still has 68X code in it and that it is hardly mulithreaded.
YDNRC.
|
|
|
|
|
|
|
|
|
Clinically Insane
Join Date: Nov 1999
Status:
Offline
|
|
A filesystem does not have code in it; it's just a format. In fact, it's not even all that different from an ordinary file format; it's just that the file is as big as the whole disk. This is one of the reasons disk images are possible. Even if the filesystem did have 68K code in it in the OS9 days, that code would have to have been excised by the time of OSX, because OSX does not have a built-in 68K emulator like OS9 did. Classic, of course, still has the emulator, but OSX cannot access it directly.
As for the multithreading issue, you do have a point there. The problem here comes with the structures which HFS uses to store file location data. The bases of these structures date back to 1984, and they were designed for a single-tasking computer with very limited RAM, no hard drive -the original Mac only had a floppy drive- and a very slow processor. As such, certain tradeoffs had to be made. HFS performs very well in certain things; even today nothing beats it for looking up individual files. However, this performance comes at a price, particularly in the fact that the structures do not lend themselves well to multithreaded access.
A next-generation filesystem would be a Good Thing, but only if it comes with the usability advantages of HFS. Yes, there are a few usability advantages built into the filesystem. The biggest is the fact that the filename and location are just two other pieces of metadata; the file's real identifier is hidden from the user and cannot be changed by ordinary means. This is what allows aliases to work without breaking every time the file is moved, unlike Windows shortcuts or Unix softlinks: they depend on a piece of data which remains constant. Embedded type/creator codes are another big advantage; these can be changed, but are not as fragile as filename extensions. Separating type and creator also allow for different apps to be used for different files of the same type, depending on the user's wishes. HFS' four-character codes are not ideal for this -MIME would be a better type code, with something like Java's identification system serving as the creator code- but the ideas behind it are sound, and neither MIME nor Java existed when HFS was first created.
|
You are in Soviet Russia. It is dark. Grue is likely to be eaten by YOU!
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: May 2005
Status:
Offline
|
|
Spotlight depends on the Mac OS filesystem
|
|
|
|
|
|
|
|
|
Dedicated MacNNer
Join Date: May 2004
Status:
Offline
|
|
For what it's worth (probably nothing!) I think MIME codes are an abomination, and are possibly the worst way to classify data that's ever been devised -- with the notable exception of filename suffixes!
They're not extensible (I don't count the hideous vnd- notation), are not hierarchical more than one level (image/* application/* and so on), cannot have multiple parents types.... need I go on?
Of course Apple have created a wonderful typing system that fixes all of those shortcomings and it's available right now in Tiger! (It actually made a sneaky appearance in 10.3, but with limited API support). That's right, I'm talking about UTIs, and we should all be thankful for them! They're light years ahead of filename suffixes, type/creator codes, MIME types or anything else created to date. We're (hopefully) entering a golden age of metadata folks!
|
╭1.5GHz G4 15" PB, 2.0GB RAM, 128MB VRAM, 100GB 7200rpm HD, AEBS, BT kbd
╰2.0GHz T2500 20" iMac, 1.5GB RAM, 128MB VRAM, 250GB 7200rpm HD
http://www.DogLikeNature.com/
|
|
|
|
|
|
|
|
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status:
Offline
|
|
Originally Posted by Dog Like Nature
Totally agree. Just look what Apple have managed to squeeze into it in Tiger without any modifications. Of course I'm talking about Apple's nascent meta-data efforts.
[FONT=Courier New]mdls[/font] hints at the kind of things that can be squeezed into HFS+!
Spotlight's metadata store isn't really related to the filesystem (after all, it still works on UFS, doesn't it?).
|
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
|
|
|
|
|
|
|
|
Clinically Insane
Join Date: Nov 1999
Status:
Offline
|
|
Originally Posted by xira
Spotlight depends on the Mac OS filesystem
Actually, it doesn't. The index files are just that: plain files (they're invisible, but that's not terribly special). Although Spotlight picks up a few file attributes from the filesystem, that's not a necessity; the same sorts of data can be found elsewhere.
Similar projects exist for other filesystems. Google's Desktop Search is a famous example, though it's Windows-only. A better example may be the Beagle project, which aims for a similar system on Linux. Their implementation can work on any filesystem supported by Linux.
Dog Like Nature, I don't see the point behind most of your anti-MIME arguments. They're at least as extensible as the old four-character code system was (which is to say, completely). The utility of multiple levels of hierarchy and of multiple inheritance are dubious at best. This said, I'm curious about UTIs; do you have a link to more documentation?
|
You are in Soviet Russia. It is dark. Grue is likely to be eaten by YOU!
|
|
|
|
|
|
|
|
Mac Elite
Join Date: Feb 2002
Status:
Offline
|
|
There is an minaframe filesystem called HFS also... i've always wondered if that has the same filesystem...
|
|
|
|
|
|
|
|
|
Professional Poster
Join Date: Jun 2001
Location: Northwest Ohio
Status:
Offline
|
|
Originally Posted by Angus_D
YDNRC.
TYVMFYIA.
Originally Posted by Dog Like Nature
That's right, I'm talking about UTIs, and we should all be thankful for them!
UTIs? Urinary Tract Infections?
|
|
|
|
|
|
|
|
|
Mac Elite
Join Date: Nov 2001
Status:
Offline
|
|
Originally Posted by Millennium
As for the multithreading issue, you do have a point there. The problem here comes with the structures which HFS uses to store file location data. The bases of these structures date back to 1984, and they were designed for a single-tasking computer with very limited RAM, no hard drive -the original Mac only had a floppy drive- and a very slow processor. As such, certain tradeoffs had to be made. HFS performs very well in certain things; even today nothing beats it for looking up individual files. However, this performance comes at a price, particularly in the fact that the structures do not lend themselves well to multithreaded access.
I don't really understand the necessity for a multi-threaded file system. I may be misinformed but aren't most Hard Disk controllers built to be single threaded? I know that because HDs have multiple platters, they now have multiple read and write heads. Does this mean that with a multi-threaded controller (or if I'm wrong, just a multi-threaded FS) the heads could be reading different pieces of data off different platters and supplying it to the OS simultaneously?
|
|
|
|
|
|
|
|
|
Grizzled Veteran
Join Date: Sep 2000
Location: London, UK
Status:
Offline
|
|
Originally Posted by Millennium
Dog Like Nature, I don't see the point behind most of your anti-MIME arguments. They're at least as extensible as the old four-character code system was (which is to say, completely). The utility of multiple levels of hierarchy and of multiple inheritance are dubious at best. This said, I'm curious about UTIs; do you have a link to more documentation?
John Siracusa wrote a good primer on metadata, MIME and UTIs in his Ars overview of Tiger.
|
|
|
|
|
|
|
|
|
Forum Regular
Join Date: Feb 2005
Location: Paris, Fr
Status:
Offline
|
|
Originally Posted by chabig
I think you are misinformed. Files systems are not tied to a particular processor any more than html or ascii are. It is what its name says...a "system", a method of storing files. There isn't any code in a file system itself.
I was most misinformed. I used to see a FS as a piece of code but your explanation makes much more sense. Thanks.
Originally Posted by tooki
HFS+ is a damned good file system. I will grant you that NTFS is a great file system as well (true journaling is a great thing), but HFS+ has scaled well, and its performance is great.
I had remained on the impression that HFS had been very criticized in the beginning of the OSX area. Apparently, things have evolved in a good way!
Regarding AT's article: Siracusa's take on UTI is interesting but he seems to forget that file extensions are here to stay on any platform for a while. I think one of the aim of Apple when they forced the use of extensions was to get sure that every document that a non-mac user would get could be properly identified and read instead of spreading the impression that macs are incompatible. As long as Windows and Linux will depend on file extensions, I think we will have to deal with file suffixes - which is not so disturbing on OSX.
But of course, UTIs will have much more uses than just to avoid file extensions.
|
|
|
|
|
|
|
|
|
Admin Emeritus
Join Date: Oct 1999
Location: Zurich, Switzerland
Status:
Offline
|
|
Originally Posted by kilechki
I had remained on the impression that HFS had been very criticized in the beginning of the OSX area. Apparently, things have evolved in a good way!
Yeah, criticized by PC and UNIX folks that were simply attacking the unknown.
A great example is the BSD fans claiming that UFS is the bees' knees, and running their OS X systems with it. In fact, Mac OS X runs substantially slower on UFS than HFS+ -- and HFS+ has far more filesystem features than UFS.
tooki
P.S. Always distinguish between HFS and HFS+. While they share a name and many features, HFS+ is vastly more advanced, and has virtually none of the limitations of HFS.
|
|
|
|
|
|
|
|
|
Mac Elite
Join Date: Aug 2001
Status:
Offline
|
|
Originally Posted by ShotgunEd
I don't really understand the necessity for a multi-threaded file system. I may be misinformed but aren't most Hard Disk controllers built to be single threaded? I know that because HDs have multiple platters, they now have multiple read and write heads. Does this mean that with a multi-threaded controller (or if I'm wrong, just a multi-threaded FS) the heads could be reading different pieces of data off different platters and supplying it to the OS simultaneously?
At a guess, it would allow stuff like pipelining reads (sending the command for read2 while waiting for the data from read1), and it might allow multiple simultaneous reads if the data was in the filesystem cache rather than on disk. I'm just guessing though.
<edit>
What I'd like to see is OSX on ReiserFS 4. It has some really fascinating features, AND is really really fast.
</edit>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Forum Rules
|
|
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is Off
|
|
|
|
|
|
|
|
|
|
|
|