Slashdot Mirror
Tom's Hardware Looks At WinFS
Alizarin Erythrosin writes "Tom's Hardware Guide has an article about the new WinFS file system. The article talks first about some of the problems and advantages with FAT[16|32] and NTFS, then talks briefly about WinFS. Here is the summary: 'Microsoft is breaking new ground with Longhorn, successor to XP. The upcoming WinFS file system will be the first to be context-dependent, and promises to make long search times and wasted memory a thing of the past. Today, THG compares it to FAT and NTFS.' Personally, I still have reservations about using a relational database to keep track of files. Unless they can keep the overhead to a minimum, I can't see it being as efficient as a file system should be."
yeah, but you still get a choice--i don't use mac os x's journaling because of the overhead--you don't hve to use winfs if the performance penalty is too high.
----
http://www.hellection.com
BeOS used indexing for certain attributes, and it is GREAT. Maybe someone is just sour that linux didn't do it first?
As far as i was concerned, WinFS was not actually a real file system but something that just runs on type of an NTFS filesystem.
This was actually confirmed at WinHEC:
"Microsoft has scaled back its 'Big Bang', and its Future Storage initiative will build on, rather than supersede the NTFS file system, when the next version of Windows 'Longhorn' appears in 2005."
"WinFS is not a file system
NTFS will be the only supported file system in Longhorn, from a setup and deployment standpoint, though the OS will, of course, continue to support legacy file systems like FAT and FAT32 for dual-boot and upgrade purposes. The oft-misunderstood Windows Future Storage (WinFS), which will include technology from the "Yukon" release of SQL Server, is not a file system, Mark Myers told me. Instead, WinFS is a service that runs on top of--and requires--NTFS. "WinFS sits on top of NTFS," he said. "It sits on top of the file system. NTFS will be a requirement."
Interestingly, when WinFS is enabled, file letters are hidden from the end user, though they're still lurking there under the covers for compatibility with legacy applications. This reminds of when Microsoft added long file name (LFN) support in Windows 95, but kept using short (8.3) file names under the covers so 16-bit applications would still work. Expect this to be the first step toward the wholesale elimination of drive letters in a future Windows version."
ummm, FAT 32 has enormous cluster sizes for large drives. That does affect the normal user.
Fat 16 was limited to 2GB partitions, that affects the normal users.
Now, the fact that if the database file system works the way I imagine it would it will be a bad thing for the normal user's more tech savy friend.
I have spent years explaining to relatives that the same file name in 2 places is 2 different files.
Now I must spend time explaining that if you brows, documents, taxes, and edit file blah it will effect important stuff, file blah and what not.
People will be confused by this I believe. And I also think the the techies saying it is stupid would benifit from this greatly, I know I would love to organize things with tons of logical ways to browse there.
But I am not some overpaid market researcher so what do I know.
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
I read this article hoping for some real information on the WinFS file system, and instead I got an amature's review of Microsoft file systems I grew up with.
"There has been much speculation"
Uh huh.
"Win FS is modeled on the file system of the coming SQL server"
Uh huh.
"In its latest build (M4), Longhorn contains few hints of the technology's imminent implementation."
Uh huh. You're saying you don't know anything, yeah, I'm getting that part.
"One of those is more than 20 MB in size and bears the name winfs.exe."
Neat.
"In the end, Win FS will probably emerge as an optional file system beside FAT and NTFS. It's also possible that Win FS will supersede its predecessors, however."
So in the end, it'll be A... but it is also possible it'll be B. I see.
"That would most likely produce problems for multi-boot systems"
An astounding feat of logic Mr. Spock!
This is the most uninformative article I've ever had the displeasure of reading on Tom's Hardware. These people know exactly nothing more about WinFS than any of the rest of us have heard in rumors and vague press releases.
Hopefully this will encourage more competitors (including open source) to go for the RDBMS-based filesystem model.
I don't understand the concerns of the poster regarding performance (at least without evidence of truly dismal performance): no one is forcing anyone to use the FS if they are not satisfied with performance.
For most users, they main bottleneck in storage is their own organizational faculties. I used to be exasperated when users didn't know where they put their files, but once you get past the 100GB mark, it becomes very understandable.
Consider what most people use their massive storage for these days: videos, music, multimedia, games. Not only is this the kind of content that SHOULD be stored in a database, it's the kind of content that is ALREADY being handled through a database because the filesystem is not enough: people are using their media players, P2P programs and other software to handle their files, up to the point they rarely ever interact with the filesystem unless they lost a file.
For most users, the performance penalty is well worth the price.
For those for whom it is not, it doesn't take a genius to realize you can use more than a single filesystem, and perhaps rediscover the joy of proper partition organization: keep the OS and applications separate from your data, and you can use your highly efficient filesystem for the first and your metadata-loaded one for the second.
Freedom is the freedom to say 2+2=4, everything else follows...
Relational databases are better than conventional file systems in both performance and transaction management/journalling.
However, the best solution is that used by EROS, which is for the kernel not to provide a file system at all, but instead provide Orthogonal Persistence.
This is a much simpler layer for applications, since it doesn't require them to explicitly access the memory and disk separately. It is also much simpler to recover from because the entire state of the whole disk is always known to be coherent with itself at all given points in time, without an expensive journal.
In terms of performance - it beats the hell out of explicit disk access systems (Both conventional and database systems) because it performs big continuous reads and writes (that don't move the head much) rather than small writes on metadata and file data that forcibly jump the disk head around.
In EROS then, on top of the Orthogonal Persistence, you can create any arbitrary Objects you want easily - because they're just normal processes with normal memory. Conventional File Systems become useless and objects implemented by processes become a much better and more powerful alternative to files.
A relational database of the user objects is then much more powerful than a string hierarchy, but this is all the user's choice - and not hardcoded into a kernel.
I'm looking forward to this! I personally am sick and tired of filesystems as we know them today. Today's filesystems are a strict hierarchy, the existence of which is only necessary in the systems of yester-year.
:+) Maybe the initial implementation wonâ(TM)t get all this right. But at least it stands a chance.
A filesystem based on a relational database will have some characteristics to which today's filesystems can only aspire:
1. ACID - In every way that the underlying database supports Atomicity, Consistency, Isolation, and Durability, so now will the filesystem. In so far as the database is robust, the filesystem will be robust. Please spare me the comments about the supposed unreliability of SQL Server. Itâ(TM)s certainly more reliable than NTFS; which is itself very good.
2. As an offshoot of the above - Imagine multiple file updates to a filesystem which is transactional! Imagine that transaction failing and being able to just rollback the changes without touching every file in your program! Imagine being able to make file changes programmatically without having to worry about locking because the engine will do it for you (just handle any exceptions)! Yeah, you could do all that today if you like. But it takes extensive to make it happen.
3. Operational characteristics - We can run queries against databases. We can index them. We can cluster them. We can replicate them. We can access them easily from any development platform you can imagine. Now your filesystem is a database. The possibilities make me shiver!
4. Another offshoot from #3 - Security. Databases are inherently better than filesystems (IMNSHO) at enforcing security and enabling administration of security.
I only have reservations about one issue with the database as filesystem area: recovery. Currently, all good and low-tech filesystem recovery tools really are based on the filesystem allocation table sort of scheme. Obviously, databases usurp this category of tried and true tools. However, good tools already do exist that allow recovery of relational databases. Itâ(TM)s just a matter of getting easily accessible tools of this sort into the hands of professionals that need them. It's more of a training issue I guess, but it will still need addressing.
I know many people will have a knee jerk reaction to this idea, and I understand why. But I would encourage people to keep an open mind to this. While there will probably be some issues with the idea, there's so much more that could easily be done with a filesystem on top of a database than could be done easily (or well) with a traditional filesystem.
And for you hard-core naysayers out there, you have to ask yourself this: If this is such a bad idea, then why did Oracle provide this as a feature too?
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
Near-Term: this thing should be just as stable as every other MS product prior to version 3.0 of it. (In short, damned lousy). To make it worse, it probably also enables DRM at a file system level...
Mid-Term: FS finally works, and allows easier retrivial by relevance, author, source, etc. in ways that we can just dream of now. It's the kind of thing we didn't realize we needed until we had it...until it inevitably blows up as all MS products must do eventually. But when it works, we will be fairly happy to have it...especially end users, most of whom can't figure out a hierchical file system in the first place.
Far-Term: FS is finally able to use it's relational roots to distribute filesystems over multiple processors in an cluster or over a network. Such a system would support atomic, distributed file updates by threads of processes on differing processors (including HyperThreaded procs). Imagine a virtual filesystem that can span your whole-house network, with a single file system image...in WINDOWS.
So I guess my view is: painful in the near-term, but may be cool to have when they get it right.
Does it matter? HPFS was created at MS. I guess it explains why HPFS hasn't been improved on recent OS/2 beyond HPFS386, and JFS is now an optional FS on OS/2. JFS is probably a much more capable FS than HPFS anyhow.
http://www.cs.wisc.edu/~bolo/shipyard/hpfs.html
I recently installed a Win2K server that is blindingly fast at finding documents and such... but horridly slow at serving up portions of files, for things like legacy database programs. Three of the customer's applications started running at 1/4 speed.
It got so bad, even after all the "fix win2k speed" patches, that we re-introduced the 200MHz NT4 server to feed the database apps, and the dual-processor 2GHz system just serves up documents!
A directory tree is a very useful structure, at least to the software. Similar stuff is grouped together, and easily cached. It provides a very clean and simple way of putting data somewhere and getting it back later. This should not lightly cast aside.
So, you want to use a relational database to keep track of files? Go for it, but instead of keeping track of the files themselves, keep track of their paths. Let the filesystem do the efficient storage, and the database do the efficient lookups. The database can be made faster and smaller, the filesystems can remain as fast as they are, and the files are still there even if the database gets corrupted.
Put hooks wherever necessary to update the database when the filesystem changes. For example, put a database in the root of each filesystem. Use a stacked mount to mount that disk, so when interesting things happen, the kernel tells a userspace process that updates the database. Then, make some standard libraries that use the database. Make file browsers that can query it, but pass the path to programs. Make save dialogs that can also save metadata about the file, and open dialogs that can search for it. Use LUFS or FUSE to make directories that correspond to queries.
This is just as effective as what MS is doing, but it's more efficient, it's more compatible, and it doesn't reinvent the wheel.
Litigious bastards
First, the async, means that not all reads and writes are syncronous which is an incredibly good thing for speed. Try putting your UFS/FFS filesystem into fully sync mode and then talk about performance, I'm willing to bet that UFS/FFS isn't sync by default either. However, calling fsync in the mail server (normally sendmail) in Linux will actually make it sync before returning. So no worries about RFC 1123. It's the SMTP server's job to ensure that it tells the filesystem, make sure the bits are on the disk. If Linux didn't have the ability to ensure bits where actually on the disk nobody would use it. That's why in Moshe Bar's series comparing Linux, FreeBSD, and OS X, he always said he recompiled after removing the fsync calls, otherwise you just compared how fast the disks in each system were.
For goodness sakes, Oracle ships on Linux, if Linux couldn't get the bits on the disk Oracle would have never ported to it. Not a chance. If Linux tells you the bits are on the disk, they are on the disk in my experience.
I've heard of people losing UFS filesystems while running them under NFS, or losing them due to any number of naferious VM race conditions. So what? Welcome to the real world, people lose data, buy a tape drive, make backups. Knew a guy who got really good at rebuilding filesystems by using dd on Solaris to recover email for customers.
Oh, and as I recall, async actually affects directories more then files, if you put the sync modifier on the filesystem, it only affects directories, not the file data for ext2/3. In ext3, directory writes are always journaled as I recall, so it shouldn't make much difference.
Now, from what I've heard of Linux and FreeBSD, is that until the late 2.2.X and early 2.4.X, there we're certain jobs Linux couldn't do like run big Usenet News services, or really disk intensive applications they the filesystem buffering was really hard to get right, and might cause corruption. The guy who ran a local ISP always said FreeBSD never did that when he was running the Usenet server on it, but Linux did with some regularity.
ext2 hasn't lot any data of mine in my 7 years of using Linux, including running a 120GB Oracle Database for the past 30 months. Ext3's never lost any data since I started using it. I've lost disk drives, I've lost mirrors, I've lost files, never lost a complete ext2 filesystem unless the disk just stopped spinning. Lost a couple of ReiserFS filesystems after installing RedHat7.0. Never tried most of the other journalling filesystems.
Kirby
Also, WinFS is no file system like FAT and NTFS. It's just a service running on top of NTFS.
It's really funny how they try to compare it with a file system, since they're just looking at NTFS with a layer giving the user an easier time to do certain things.
Beware: In C++, your friends can see your privates!
I think the performance of WinFS will tell us how serious Microsoft is about really changing the way files are used. Performance is just a question of time and engineering resources - OS X's journaling is slow but HFS+ is an antique filesystem; in contrast BeOS had BFS, a journaled filesystem with all of the indexing buzzwords WinFS claims except free-text context searches and it was also extremely fast.
The difference isn't features - BeFS supported everything HFS+ does and arbitrary attributes, journaling, much larger file/filesystem support, and indexing and it was still faster. Be simply made performance a much higher priority than Apple has so far; fortunately they've hired the BeFS lead developer and perhaps 10.3 will have some surprises.
Another good example is ReiserFS - while some of their choices reflect overall design goals (e.g. targeting large numbers of small files instead of BFS's massive videos) they've largely passed the traditional filesystems in most areas despite having to do more work to keep all of the extra features going.
Microsoft has a number of engineers who do understand performance; the question is simply whether it'll be a significant priority for them to make WinFS fast enough that we'll realistically be able to use it.
One word: FAT. You are making three assumptions here. The first is that the underlying implementation is capable of supporting near-infinite extension without degradation. Invalid for FAT, valid for the FS types mentioned in the grandparent, and the reason for what I said. The second is that the file system will be used as a hierarchy, which is invalid for most end users. The third is a combination of the first and second, being that the file system extends without unreasonable degradation to a vasst number of files in a single directory, and performing operations (esp. searches) on them quickly. This is invalid for all of these file systems, because of how they store metadata.
Again, you're assumiung you, a technically savvy user. End users don't behave like this. By and large they use meaningful file names in a single directory. If you're looking for a document someone else did, it will be in their single directory, not in a common folder for documents relating to that topic. If you don't know who worked on the document, you need to do a broad search based on keywords.
Which shows how little you've thought about the implementation of this system. You only have to make a change if the file metadata changes. In many file systems you already have to write that change in a different location to changes to the file itself (if you don't, your metadata search time goes out the window). If your "locate" database is a relational database, making a change has trivial overhead.
Actually, this isn't what I was meaning. I was referring to the relationship between the data in the FS and in the locate database (or any other metadata search database), and indicating that WinFS (in theory) takes out the step of building a separate database by using the database as the "index" of the file system. Unfortunately in this incarnation of WinFS (the current implementation) MS will not be implementing it quite in that fashion.
But to answer your point ... Win32 systems have had file change notification in their APIs from day 1 (NT 3.1 / Win95 + have FindFirstChangeNotification; NT 3.51 + have ReadDirectoryChangesW).
And that's pretty much what MS is doing by converging a tradition file system with a metadata view.
Of course, WinFS was intended for client operation systems, not servers. And while NTFS could still be improved, it doesn't make a lot of sense to do so: most high data volume applications store their data in structured files, and don't require much from the file system in any place where performance could be signficantly improved.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
NTFS is actually not bad with fragmentation. I'm running a Win2k Pro box and a WinXP Pro box; neither's partition has ever reached more than 12% fragmentation, and even that was after having the partitions 98% full. Most people won't notice NTFS file fragmentation as a problem until it reaches 50% to 60% anyway. FAT32, however, is quite a different story. I can start to notice performance hits around 9% fragmentation or so. Also, according to my MCSE training kit, the main cause of filesystem fragmentation on windows machines is using a page file that does not have a static size. Using a statically-sized page file can decrease defragmentation dramatically. (If you don't believe me, set your paging file to a static size between 1.5 and 3 times the amount of physical RAM you have, reboot, defragment, and test with every FS torture you can think of.)
For most file data, perhaps.
I will use this, and to good effect, as well.
The point to take into consideration is that the context will also change depending on the metadata available. Your view of the aggregate file objects changes, depending on the context. Not to mention that this same metadata will be available, in the same format, to all participating applications. Your apps can have all the same view, if you like.
What this means in concrete terms is that your carefully sorted directory of MP3's can look like a file library in iTunes. There are searchable, sortable columns for Title, Album, bitrate, Cover Art, year, label, and whatever (note I did not say "filename", which is just another attribute under a modern filesystem). This is possible with only the most basic gestures on the part of the user, and is remembered for the next time you visit this same view.
Similarly, a tree of photographs appear in any participating file browser with whatever columns you want (bit depth, format, date taken, date published, ICC info). It's important to consider that you can do this with any arbitrary collection of data, even one's you define yourself (to take the BeFS example, anyway).
So you can take your collection of widgets, define attributes about these widgets, and your file browser applet works the same for the same user in all applications. It should, anyway. This is why we have APIs.
To cite your example, why visual grep through a bunch of thumbnails looking for a particular photo when you can just indicate with a few gestures the "type" of photo you are looking for? I like the iPhoto interface when I'm browsing photographs, but if I want a particular photo of the GF from a rough date taken at night, I certainly don't want to browse through 1000's of images, especially when some of them can be hard to discern at thumbnail resolutions. I certainly don't want to do this repeatedly when I'm assembling a photo album on a specific subject.
Let the computer do the grunt work of selecting a result set that matches my criteria, and then I can use my human abilities to select the object I want, or refine the search.
Most of us already keep our aggregate file types in associated groups on the filesystem already. In most cases, the tree structure of most filesystems is sufficient. All this does is extended the functionality of the filesystem so that you can choose to abstract aggregate file objects and treat them in a a myriad of different ways. In the most basic sense, you tell the OS, "look, when I have the Explorer/Finder open on this directory of MP3's, make sure you change the column view so it shows this, this and that. In icon view, make sure that mouse-over pop-ups (if enabled) display this that and that. Default sort is alphabetically by Artist's Last Name. I don't want to see the filename, as that doesn't contain any useful information."
That is, you don't have do anything special to make use of the file attributes in this way. You just tell the ultimate app that all of us use the most (the operating system's file browser) to treat certain directories in a different manner.
-- clvrmnky