All I know about this topic is that a long time ago Vista was going to have a new Filesystem
No, this is simply inaccurate. I'll only give the quick run-down on it.
WinFS, which is short for Windows Future Storage, is a database layer (using a slimmed version of MSSQL/MSDE) for the file system, on top of NTFS (the New Technology File System). Vista was to continue using NTFS (with the typical slight enhancements, but nothing groundbreaking), but add WinFS as an option. Several Longhorn alphas, including one I've tried, did in fact sip with this.
WinFS is a lot like Spotlight in that the database nature enables you to very quickly and very thoroughly search through files, by many criteria. But modern, efficient Metadata search is not all WinFS would have offered. The much more important aspect is one whose possible impact we simply cannot imagine now that there is no more such technology (in widespread use), nor hope for one to come soon (to widespread use).
Basically, WinFS lets you treat files as objects (for example, a vCard .vcf file would be a "contact"-type object), and would let you define relationships between such objects, such as connecting that contact to a calendar event, represented in the file system as an iCalendar .ics file. So, now you could say "this contact has something to do with this event", e.g., the contact is invited for it, hosts it, etc.
What's novel about this is the fact that this happens right above the file system. It's completely transparent from any particular application (unlike Apple's implementation, which is implemented specifically in iCal).
It would give you a completely different kind of view of your file system.
All this has been in the works since some point in the early 1990s. It was a long-time vision of Allchin. Then around 2004, it was delayed for a post-Vista release, to be available as a free download for existing Vista users. A few weeks ago, however, it was rather quietly and rather hypocritically announced that this would be cancelled altogether. The remains of WinFS work goes into different areas which have nothing to do with Windows itself any more.
But anyways, the reason I responded to your post was the common misconception that WinFS is a file system, or that Vista was going to have a different file system; that is simply not true. Vista was always to continue using NTFS, which I dare say is so comprehensive, extensible and modern that Microsoft will probably continue using it for years to come. They have no reason to change.
And likewise, Apple has no reason to change either. HFS+ is excellent.
Um, no it's not. It does the job, and is better than nothing, but it's not exactly a leader in:
Performance
Features (eg: journalling, scheduling, etc)
Anything
If you've ever looked at Reiserfs or XFS or BeOS's fs etc, I don't think you remark on HFS+ being excellent. Several Be enginners for their FS were hired by Apple (and worked on Spotlight) let's hope they contribute some cool stuff to Apple.
I personally would like to see Apple make OSX FS-independant so all resource BS is handled by .invisible files and end users can choose a FS based on their needs, eg: XFS for video editors, etc.
If Apple goes with ONE FS, I'd like it to be ZFS, which seems to strike a sweet spot in FSes.
If you've ever looked at Reiserfs or XFS or BeOS's fs etc, I don't think you remark on HFS+ being excellent. Several Be enginners for their FS were hired by Apple (and worked on Spotlight) let's hope they contribute some cool stuff to Apple.
Dominic (writer of BFS and author of a book on file systems) seems quite fond of HFS+.
Quote:
I personally would like to see Apple make OSX FS-independant so all resource BS is handled by .invisible files and end users can choose a FS based on their needs, eg: XFS for video editors, etc.
Your classification of the resource fork as "BS" tells me that you might not know nearly as much about good file system design as you claim to.
Quote:
If Apple goes with ONE FS, I'd like it to be ZFS, which seems to strike a sweet spot in FSes.
I still have yet to see a concrete thing that ZFS does for the average user that's so amazingly great that it couldn't simply be added on to HFS+.
I'd much rather see Apple move to NTFS if they really have to move to a different fs. NTFS, fortunately, supports streams, which can be made mutually compatible with HFS+ forks.
HFS was actually one of the first modern file systems to appear on personal computers. Yeah, it shows its age, but it's better than a lot of the alternatives. NTFS doesn't strike me as much of an improvement: If there's going to be a change, might as well go for broke.
With that said, I will re-iterate that I'd like to see Apple build their next filesystem from Reiser. ZFS just doesn't seem like it would be useful to most people. In time, it may influence surrounding technologies, the way Java did, but until then it just doesn't seem like a great product for anything besides high-hit-rate server storage.
Well, NTFS is much more complex, which I suppose is rather negative than positive, but it has some features like transparent encryption and compression going for it.
Dominic (writer of BFS and author of a book on file systems) seems quite fond of HFS+.
That's an interesting claim.
Excerpts from Dominic Giampaolo's book Practical File System Design seem to point the other way. Note that some extensions (e.g. journaling) have been added by Dominic, or the team that he's on, to address some concerns, but here's what he had to say about HFS/HFS+ (page 38 for those of you who read the PDF). Bold emphasis is mine; I've clipped out a lot, so for full context it's probably a good idea to read the original, especially compared to the comments he gives for XFS.
Quote:
Because it keeps all file and directory information, it forces serialization of the file system ? not an ideal situation when there are a large number of threads wanting to perform file I/O. In HFS, any operation that creates a file or modifies a file in any way has to lock the catalog file, which prevents other threads from even readonly access to the catalog file. Access to the catalog file must be singlewriter/multireader.
[...]
As with the catalog file, the extent overflow file stores all extents for all files in the file system. This again forces a singlewriter/multireader serialization of access to the extent overflow file. This presents serious limitations when there are many threads vying for access to the file system.
[...]
A recent revision to HFS, HFS+, removes some of the original limitations of HFS, such as the maximum number of blocks on a volume, but otherwise makes very few alterations to the basic structure of HFS.
[...]
HFS set the standard for file systems supporting a GUI, but it falls short in many other critical areas of performance and scalability.
Note that I have absolutely no idea what Dominic Giampaolo thinks of the current state of HFS+, but his historical perspectives are clearly documented, and HFS+ hasn't undergone any huge architectural changes since his original comments were written.
Um, that was years ago. When Giampalo joined Apple, HFS+ was quite different. And I think the "scalability" concern can be put to rest, seeing as HFS+, when released, was used mainly on hard drives with a single-digit amount of Gigabytes, when it is now easily used on partitions with single-digit amounts of Terabytes. (And anything beyond that won't be necessary for HFS+'s purposes any time soon. HFS+ isn't designed to be, nor claims to be, a file system for huge file system grids. Apple has a different file system for that, Xsan.)
Excerpts from Dominic Giampaolo's book Practical File System Design seem to point the other way. Note that some extensions (e.g. journaling) have been added by Dominic, or the team that he's on, to address some concerns, but here's what he had to say about HFS/HFS+ (page 38 for those of you who read the PDF). Bold emphasis is mine; I've clipped out a lot, so for full context it's probably a good idea to read the original, especially compared to the comments he gives for XFS.
Note that I have absolutely no idea what Dominic Giampaolo thinks of the current state of HFS+, but his historical perspectives are clearly documented, and HFS+ hasn't undergone any huge architectural changes since his original comments were written.
While I agree with what he's saying. what he doesn't say there (at least in your excerpts), is that this methodology they use adds to reliability. And sometimes, that's what it comes down to, speed, or reliability.
ZFS isn't slow, as some seem to think it is. But, it's reliable, particularly if you have two drives, or even two partitions. HFS+ isn't slow in all areas, but some of the areas in which it is slow are very annoying. While it's not as reliable as ZFS, it's good.
A lot of the perceived slowness comes from the Finder... Copying files and deleting them are two examples where it wastes time. Doing the same commands via command-line is near-instantaneous.
A lot of the perceived slowness comes from the Finder... Copying files and deleting them are two examples where it wastes time. Doing the same commands via command-line is near-instantaneous.
Try deleting hundreds of thousands of files. I once made an experiment to unpack the FreeDB database on an HFS+J volume in Panther. Mac OS X literally died. Deleting the files was possible only in single-user mode and took several hours on a G5.
Quote:
Originally posted by 1337_5L4Xx0R
That said, Reiserfs is hella-faster than HFS.
Perhaps, at least everybody says so. However, I heard that the said FreeDB database is a tough challenge for most OSes and file systems.
Well, if I still had gentoo linux installed on my trusty TiBook, I'd have a go at unpacking freedb on reiserfs 3, but alas, I had to make more space for my MP3 collection... sniff...
Bazillions of teensy little files is actually precisely reiser's strength. It plows through them at blazing speed.
Comments
Originally posted by Frank777
All I know about this topic is that a long time ago Vista was going to have a new Filesystem
No, this is simply inaccurate. I'll only give the quick run-down on it.
WinFS, which is short for Windows Future Storage, is a database layer (using a slimmed version of MSSQL/MSDE) for the file system, on top of NTFS (the New Technology File System). Vista was to continue using NTFS (with the typical slight enhancements, but nothing groundbreaking), but add WinFS as an option. Several Longhorn alphas, including one I've tried, did in fact sip with this.
WinFS is a lot like Spotlight in that the database nature enables you to very quickly and very thoroughly search through files, by many criteria. But modern, efficient Metadata search is not all WinFS would have offered. The much more important aspect is one whose possible impact we simply cannot imagine now that there is no more such technology (in widespread use), nor hope for one to come soon (to widespread use).
Basically, WinFS lets you treat files as objects (for example, a vCard .vcf file would be a "contact"-type object), and would let you define relationships between such objects, such as connecting that contact to a calendar event, represented in the file system as an iCalendar .ics file. So, now you could say "this contact has something to do with this event", e.g., the contact is invited for it, hosts it, etc.
What's novel about this is the fact that this happens right above the file system. It's completely transparent from any particular application (unlike Apple's implementation, which is implemented specifically in iCal).
It would give you a completely different kind of view of your file system.
All this has been in the works since some point in the early 1990s. It was a long-time vision of Allchin. Then around 2004, it was delayed for a post-Vista release, to be available as a free download for existing Vista users. A few weeks ago, however, it was rather quietly and rather hypocritically announced that this would be cancelled altogether. The remains of WinFS work goes into different areas which have nothing to do with Windows itself any more.
But anyways, the reason I responded to your post was the common misconception that WinFS is a file system, or that Vista was going to have a different file system; that is simply not true. Vista was always to continue using NTFS, which I dare say is so comprehensive, extensible and modern that Microsoft will probably continue using it for years to come. They have no reason to change.
And likewise, Apple has no reason to change either. HFS+ is excellent.
Performance
Features (eg: journalling, scheduling, etc)
Anything
If you've ever looked at Reiserfs or XFS or BeOS's fs etc, I don't think you remark on HFS+ being excellent. Several Be enginners for their FS were hired by Apple (and worked on Spotlight) let's hope they contribute some cool stuff to Apple.
I personally would like to see Apple make OSX FS-independant so all resource BS is handled by .invisible files and end users can choose a FS based on their needs, eg: XFS for video editors, etc.
If Apple goes with ONE FS, I'd like it to be ZFS, which seems to strike a sweet spot in FSes.
Originally posted by 1337_5L4Xx0R
If you've ever looked at Reiserfs or XFS or BeOS's fs etc, I don't think you remark on HFS+ being excellent. Several Be enginners for their FS were hired by Apple (and worked on Spotlight) let's hope they contribute some cool stuff to Apple.
Dominic (writer of BFS and author of a book on file systems) seems quite fond of HFS+.
I personally would like to see Apple make OSX FS-independant so all resource BS is handled by .invisible files and end users can choose a FS based on their needs, eg: XFS for video editors, etc.
Your classification of the resource fork as "BS" tells me that you might not know nearly as much about good file system design as you claim to.
If Apple goes with ONE FS, I'd like it to be ZFS, which seems to strike a sweet spot in FSes.
I still have yet to see a concrete thing that ZFS does for the average user that's so amazingly great that it couldn't simply be added on to HFS+.
I'd much rather see Apple move to NTFS if they really have to move to a different fs. NTFS, fortunately, supports streams, which can be made mutually compatible with HFS+ forks.
With that said, I will re-iterate that I'd like to see Apple build their next filesystem from Reiser. ZFS just doesn't seem like it would be useful to most people. In time, it may influence surrounding technologies, the way Java did, but until then it just doesn't seem like a great product for anything besides high-hit-rate server storage.
Originally posted by Splinemodel
NTFS doesn't strike me as much of an improvement:
Well, NTFS is much more complex, which I suppose is rather negative than positive, but it has some features like transparent encryption and compression going for it.
Originally posted by Chucker
Dominic (writer of BFS and author of a book on file systems) seems quite fond of HFS+.
That's an interesting claim.
Excerpts from Dominic Giampaolo's book Practical File System Design seem to point the other way. Note that some extensions (e.g. journaling) have been added by Dominic, or the team that he's on, to address some concerns, but here's what he had to say about HFS/HFS+ (page 38 for those of you who read the PDF). Bold emphasis is mine; I've clipped out a lot, so for full context it's probably a good idea to read the original, especially compared to the comments he gives for XFS.
Because it keeps all file and directory information, it forces serialization of the file system ? not an ideal situation when there are a large number of threads wanting to perform file I/O. In HFS, any operation that creates a file or modifies a file in any way has to lock the catalog file, which prevents other threads from even readonly access to the catalog file. Access to the catalog file must be singlewriter/multireader.
[...]
As with the catalog file, the extent overflow file stores all extents for all files in the file system. This again forces a singlewriter/multireader serialization of access to the extent overflow file. This presents serious limitations when there are many threads vying for access to the file system.
[...]
A recent revision to HFS, HFS+, removes some of the original limitations of HFS, such as the maximum number of blocks on a volume, but otherwise makes very few alterations to the basic structure of HFS.
[...]
HFS set the standard for file systems supporting a GUI, but it falls short in many other critical areas of performance and scalability.
Note that I have absolutely no idea what Dominic Giampaolo thinks of the current state of HFS+, but his historical perspectives are clearly documented, and HFS+ hasn't undergone any huge architectural changes since his original comments were written.
Originally posted by Zarafa
That's an interesting claim.
Excerpts from Dominic Giampaolo's book Practical File System Design seem to point the other way. Note that some extensions (e.g. journaling) have been added by Dominic, or the team that he's on, to address some concerns, but here's what he had to say about HFS/HFS+ (page 38 for those of you who read the PDF). Bold emphasis is mine; I've clipped out a lot, so for full context it's probably a good idea to read the original, especially compared to the comments he gives for XFS.
Note that I have absolutely no idea what Dominic Giampaolo thinks of the current state of HFS+, but his historical perspectives are clearly documented, and HFS+ hasn't undergone any huge architectural changes since his original comments were written.
While I agree with what he's saying. what he doesn't say there (at least in your excerpts), is that this methodology they use adds to reliability. And sometimes, that's what it comes down to, speed, or reliability.
ZFS isn't slow, as some seem to think it is. But, it's reliable, particularly if you have two drives, or even two partitions. HFS+ isn't slow in all areas, but some of the areas in which it is slow are very annoying. While it's not as reliable as ZFS, it's good.
That said, Reiserfs is hella-faster than HFS.
ZFS for Xserves, and Reiser for everything else?
Originally posted by 1337_5L4Xx0R
A lot of the perceived slowness comes from the Finder... Copying files and deleting them are two examples where it wastes time. Doing the same commands via command-line is near-instantaneous.
Try deleting hundreds of thousands of files. I once made an experiment to unpack the FreeDB database on an HFS+J volume in Panther. Mac OS X literally died. Deleting the files was possible only in single-user mode and took several hours on a G5.
Originally posted by 1337_5L4Xx0R
That said, Reiserfs is hella-faster than HFS.
Perhaps, at least everybody says so. However, I heard that the said FreeDB database is a tough challenge for most OSes and file systems.
Originally posted by 1337_5L4Xx0R
How about Apple hires you and gives you a raise?
That would be awesome.
Bazillions of teensy little files is actually precisely reiser's strength. It plows through them at blazing speed.
Originally posted by 1337_5L4Xx0R
Bazillions of teensy little files is actually precisely reiser's strength. It plows through them at blazing speed.
Which is precisely why it's such a good fit for Mac OS X (or Linux, for that matter).