Apple hired the BFS creator (I can't remember his name right now) over a month or two ago; so, many of us have been hoping we'll start seeing some developments over the next year. There are many bottlenecks introduced to OSX by using HFS+, but these aren't the major flaws causing it to *look* so slow. That's the fault of Quartz, Finder, Carbon Services, and a few others. I new file system, though, *should* speed up a number of things such as file access and reduce or even eliminate corruption. I'd just *love* to bid farewell to fsck!
Remember, a file system is not an easy thing to create! I really doubt you'll see a change as early at, say, WWDC or MWNY, but it would be nice to hear if there are *plans* for a new FS.
You can call him Sue for all I care. Just as long as he fixes the file system, he's all right in my book. I'm sick of having to Disk Warrior my hard drive every three weeks because of fragmented directories. It kinda defeats the purpose of having an OS that can last for months without a reboot.
Yeah, Giampaolo is the guy... Progress has already shown in 10.1.4, with much improved FS searching.
I'm pretty confident this guys will single handedly adress most of the meta-data/FS related requests. His hiring is probably the best OSX-related news this year.
Yes, Apple is tied to some derivative of HFS as long as Classic exists -- its so dependent on resource forks which are a central part of that filesystem. I imagine something will happen like what Amorph is mentioning -- a kind of HFS++ or Super HFS or something that might be possible(we're getting into the pipe dream of Copland here: "Just add protected memory and preemptive multitasking to OS 9 and you're done!"). If There's some way to add journaling, better throughput and a few other XFS/JFS/UFS/BFS features to HFS+, I'm sure they're working on it.
<strong>I was not aware of that. Ok, I give up then. Why HFS+?</strong><hr></blockquote>
Because UFS is slow and doesn't add anything, other than case sensitivity which is useful for developers but not users.
HFS+ sucking is largely a red herring - someone was doing a test on one of the OS X lists to see how many directories you could create in another directory (something like that) and HFS+ absolutely crushed UFS. OS X has *a lot* of files, way more than exist on the same drive in an OS 9 installation. Every application now consists of a folder filled with hundreds to thousands of other little files and that stresses the shit out of the file system. What would help is some method of serializing (probably not a word, oh well) a package so it is treated by the file system as one contiguous chunk of data. Hmm, kind of like the resource for... Er, nevermind.
<strong>HFS+ sucking is largely a red herring</strong>
Or a hangover from the uniformly poor implementation in the older MacOS. It's a pretty nice FS, although lacking in a few areas.
[quote]<strong>What would help is some method of serializing (probably not a word, oh well) a package so it is treated by the file system as one contiguous chunk of data. Hmm, kind of like the resource for... Er, nevermind.</strong><hr></blockquote>
Serializing is a word, and you used it correctly (although I prefer the Python terminology - "pickling" - just because it's funnier). I'm all over the idea of more robust metadata support, though, and packages are a great, portable way of handling rich metadata.
The problems I can see with serializing are: In exchange for less burden on the FS, you have more overhead in the layer between the FS and the applications - if an app decides to add a file to a bundle, something has the burden of figuring out how to do so (the brute-force way - deserialize, add file, reserialize - would be time-consuming), and; bundles can be (and are) used for version control, which means that one bundle could contain six or seven versions of the same framework (or document, or application). Do you really want to load every single one at the outset, and then pick the one you want? That could mean reading and writing megabytes of data that you don't need.
Unless I'm missing something, anyway. I should add the disclaimer that I'm an applications, not a systems, guy.
Comments
Apple hired the BFS creator (I can't remember his name right now) over a month or two ago; so, many of us have been hoping we'll start seeing some developments over the next year. There are many bottlenecks introduced to OSX by using HFS+, but these aren't the major flaws causing it to *look* so slow. That's the fault of Quartz, Finder, Carbon Services, and a few others. I new file system, though, *should* speed up a number of things such as file access and reduce or even eliminate corruption. I'd just *love* to bid farewell to fsck!
Remember, a file system is not an easy thing to create! I really doubt you'll see a change as early at, say, WWDC or MWNY, but it would be nice to hear if there are *plans* for a new FS.
[ 04-29-2002: Message edited by: starfleetX ]</p>
On the other hand, I don't think it would be too hard for them to pull that off. Not now that they have Mr. BFS on board.
I'm pretty confident this guys will single handedly adress most of the meta-data/FS related requests. His hiring is probably the best OSX-related news this year.
[ 04-29-2002: Message edited by: SYN ]</p>
Once Apple stops producing OS 9, then maybe.
<strong>I was not aware of that.
Because UFS is slow and doesn't add anything, other than case sensitivity which is useful for developers but not users.
HFS+ sucking is largely a red herring - someone was doing a test on one of the OS X lists to see how many directories you could create in another directory (something like that) and HFS+ absolutely crushed UFS. OS X has *a lot* of files, way more than exist on the same drive in an OS 9 installation. Every application now consists of a folder filled with hundreds to thousands of other little files and that stresses the shit out of the file system. What would help is some method of serializing (probably not a word, oh well) a package so it is treated by the file system as one contiguous chunk of data. Hmm, kind of like the resource for... Er, nevermind.
<strong>HFS+ sucking is largely a red herring</strong>
Or a hangover from the uniformly poor implementation in the older MacOS. It's a pretty nice FS, although lacking in a few areas.
[quote]<strong>What would help is some method of serializing (probably not a word, oh well) a package so it is treated by the file system as one contiguous chunk of data. Hmm, kind of like the resource for... Er, nevermind.</strong><hr></blockquote>
Serializing is a word, and you used it correctly (although I prefer the Python terminology - "pickling" - just because it's funnier). I'm all over the idea of more robust metadata support, though, and packages are a great, portable way of handling rich metadata.
The problems I can see with serializing are: In exchange for less burden on the FS, you have more overhead in the layer between the FS and the applications - if an app decides to add a file to a bundle, something has the burden of figuring out how to do so (the brute-force way - deserialize, add file, reserialize - would be time-consuming), and; bundles can be (and are) used for version control, which means that one bundle could contain six or seven versions of the same framework (or document, or application). Do you really want to load every single one at the outset, and then pick the one you want? That could mean reading and writing megabytes of data that you don't need.
Unless I'm missing something, anyway. I should add the disclaimer that I'm an applications, not a systems, guy.
[ 04-30-2002: Message edited by: Amorph ]</p>