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."
Now that every Windows user is going to be running a SQL variant on their system, imagine the bugs and holes that are going to be in this. Now THIS will be interesting to see.
Fundamentalism stops a thinking mind.
In any event, Microsoft still has a few years to refine this "Future Storage" file system, so all judgements concerning it's effectiveness are a bit premature on some levels. Then again, it's always good to start planning as early as possible - especially when you consider that it may be introduced into Windows Server 2003 some time during the next 12-18 months. For now, all we can base judegement off of is Microsoft marketing hype and comparisons to existing file systems that operate in a similar way.
Haven't they basically been trying to implement this since the days of Cairo? Seems the 'revolutionary new file system' gets announced for every Windows release that is several years away, then vanishes by the time the release takes place.
.technomancer
Hey did the person who modded me "Troll" READ THE FUCKING ARTICLE ? DID YOU ? Read it. It's 6 pages of how FAT and NTFS work, along with the classic line that VFAT "was the first system that could write long file names". The LAST PAGE is the only page that talks about WinFS. It's titled "Conclusion: WinFS - The Future". It regurgitates that WinFS is based on the upcoming file system for SQL server, which is *modelled on* a relational database, and gives all the usual hype about how you'll be able to search by content, blah blah. There is not a shred of any information, let alone anything new. The whole fucking article is filler.
In Soviet America the banks rob you!
Looks like I was wrong - or, actually, right all along. Musta been a slow news day?
Unless they can keep the overhead to a minimum, I can't see it being as efficient as a file system should be.
They may have goals other than efficiency. Security, probably. But probably also security's perverted uncle, DRM. As DRM becomes more common, and we "pirates" look for more innovative ways to get around it, locking us out of our hard drives would seem to be a logical if not downright necessary step. It's pretty obvious that a lot of entities out there would benefit greatly from a model where we don't really OWN our computers, we just lease the right to use them. I mean, look, they're already floating the notion out there, at least for software and entertainment media, that we don't really OWN ANYTHING, and it's not that much of a stretch for that to become literal truth, aside from the hardware, which will be as impervious to meddling as they can possibly make it. (You decide who "THEY" might be, but I have a long list with a lot of familiar names on it.)
How technically difficult would it be for, say Microsoft, to "rent" out portions of your hard drive to various media and software providers, using a combination of hardware and software controls to assure those companies that you and I ABSOLUTELY CANNOT meddle with "their" product while we (temporarily) posess it? A database-driven file system provides exactly the access control and accountability that would be required to successfully implement something like that.
To ensure perfect aim, shoot first and call whatever you hit the target
Linux can not safely write to NTFS, not even NTFSv1.2 even though it has been around since 1994. The lack of documentation makes it so that some aspects of updating the metadata and indexes cannot be done safely in all situations.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
A Mac desk accessory / extension combination, I believe, that came out in 1990 or so. It allowed you to instantly retrieve lists of file on your hard disk based on name and content (by "instant" I mean the list of matching files changed as you typed your query).
On my IIci it was perfectly fast. Faster than BeOS queries on a dual 603 box.
It took a little time to build your index, but keeping it up-to-date was pretty painless. Apple's developer CDs used to ship with On Location indices on them.
Right, but in general, journaling is a hack. The BSD softupdates concept is both cleaner and faster, and accomplishes nearly the same thing. To be fair, all of NTFS, ext3, reiserfs, BeOS's FS, and the new OSX FS have some advanced journaling features, but the concept itself should be more cleanly handled. Much like databases should be ACID compliant, filesystem writes can and should occur in such a manner that no external journal is required.
--
Use Vobbo for Video Blogs
Hey did the person who modded me "Troll" READ THE FUCKING ARTICLE ? DID YOU ? Read it. ... The whole fucking article is filler.
;)). Now it looks like the two paragraphs per "article page" are just used to keep the ads from bumping into each other. The whole article could've fit on one page, but I guess that doesn't get very many banner impressions when you know that Slashdot will link to your story, no matter how high the "filler" ratio.
Tom's Hardware must have degenerated while I wasn't looking. The articles used to be full of detail, two printed pages long per "digital article page" (what you see on the screen
I've been reading and contributing responses to Slashdot for years, but this is by far the worst article I've ever seen posted here. I can't believe whoever posted the article on the "front page" of Slashdot actually read the article -- they couldn't have even read the first page.
Right on the first page of the article, the "journalist" who wrote it describes disk storage as "memory". In the "Summary" of the article posted on every page, current file systems are described as wasting "memory". This reminds me of every-day users who confuse their computer running slowly (or literally telling them they don't have enough memory) with the need to delete files from the hard drive -- two completely separate things in most situations. This is all aside from the fact that the article doesn't actually tell you much that anybody who's used computers for more than six months doesn't already know. This guy sounds like some of the kids who come to me interviewing for I.T. positions thinking they've got a leg-up on everyone else because they've got some basic experience with PC's and Windows.
The bottom line is that the guy who wrote this article doesn't have any business writing tech articles without heavy supervision from someone who KNOWS tech, and I don't just mean someone who knows enough to rattle off performance numbers for CPU comparisons (read some other articles on the site). Lastly, Slashdot has no business posting amateurish and misinforming articles like this for the rest of us to waste our time on.
Usability engineers looked at what users were doing in Windows and they saw that tons of people weren't using the filesystem - at least not directly. They were just putting everything on the desktop. If it was on the desktop, they could find it. They kept folder structures to a minimum and organized things visually (or not at all).
This posed a significant problem, so indexing and searching and abstracting the filesystem was one of the solutions. Instead of having to navigate a filesystem (hard for many users), you just type in what you're looking for and *poof* it appears. Not sure what you're looking for? Start describing it... *poof* it appears.
I'm not saying this is the right solution, but technology is not always about cluster size and performance - especially if the system isn't usable. It will be interesting to see how user friendly this WinFS thing is...
Reread the post again, paying special attention to the word 'when'.
I suspect people confusing DOS kernels and NT kernels is your pet peeve, and it bothers you so much you see it everywhere.
Maybe you should reread your post, you said that it 'still isn't'. - Implying that Windows still isn't an operating system, and with the previous reference to the DOS underpinnings you set yourself up for that interpretation.
Besides, now that we are on the subject, Win9x and its successors also were TRUE Operating Systems, as they handled ALL Input/Output of the OS and the only DOS it relied upon was for compatibility with legacy application or drivers. DOS was basically a 'boot loader' for the Win9x Operating System.
Go look up the terminology of Operting System, and you will find that Win9x easily fits the definition. This is why the Win3.1 box said 'Operating Environment' and Win95 box said 'Operating System'.
Maybe your pet peeve is that some people notice when you make an ass out of yourself when you are so quick to find a reason to bash Windows and yet you still have to find a way to respond.
Geesh...
Microsoft loves to create incredibly complicated, undocumented and fragile data structures. Consider word: the internal structure of a word document as itself a filesystem, it has a root, a FAT and a bad block list. If even 1 block is damaged the file is useless. There are few repair tools because the internal layout is secret and undocumented. Access and SQL files are worse. In data recovery we frequently recover 90% of the files from volumes that have thousands of bad blocks or other damage. That wont work with WinFS. Are you going to store you precious digital photos on your $80 WesternDigital 80gb drive with its new 1 year warranty? Microsofts (and WD's) attitude will be that you should have backed it up. How do you easily back-up 80gb anyway?
Much like databases should be ACID compliant, filesystem writes can and should occur in such a manner that no external journal is required.
And how would you propose to achieve that without performance going down the drain?
The guys writing these filesystems are not dumb, and the reasons why journals are used are well considered. Another thing is that ACID compliant databases also use something like a journal to achive the atomicity.
Oh, and forget softupdates, they are _not_ comparable to journaling filesystems, for instance you still need to fsck, it's just faster.
Compare that with one of the funnies manpages I know.
Am I the only one really annoyed at this guys use of "memory" for disk space? I _still_ find customers who can't tell the difference between RAM and HDD, and this guy goes and makes it worse for every twit who thinks they know everything. Yes, I know that one can make a theoretical argument for using the term, but really, in practice, memory is RAM. It's just annoying... I'm surprised to see it at Tom's Hardware...
jX [ Make everything as simple as possible, but no simpler. - Einstein ]
That's a very small amount of metadata. Let's say I've got a picture of mountain that has been digitised and sits on my computer. Here's some meta data I want to store against it:
a) I want to store that it's a jpg file. I am Japanese and see no reason why the file type should be indicated by a small dot shape followed by three symbols left over from the roman empire that stand for some words in a language I don't speak. File name extensions are very archaic technology.
b) I want to record when I took the photograph that this picture represents.
c) I want to record that this photograph is going in my family album
d) I want to record that this is an 'outdoor' photograph
e) I want to record that this photograph is of Mount Fuji
f) I want to record that this particular file is the high-resolution version, suitable for output onto my photo-printer.
g) get the point? I could have a lots of symlinks of this file to folders called 'my photos' and 'outdoor photos' and 'photos taken in July' but that would be a stupid ugly hack. I could call my file:
mount_fuji_july-hi_res-outdoor.jpg
but that would be even more stupid.
Now, at this point someone says "well, if you want all that then just buy a content-management application that sits ontop of the OS and lets you catalog all your stuff."
I think MS has realised that pretty much every file _should_ be in a content management system of some kind. They are simply adding a lightweight CMS to the OS, which seems perfectly sensible to me. That way, other applications can make use of the meta-data the CMS holds. The file open dialogue on all windows apps will, instead of a directory browser have the ability to query the CMS for, say 'most recent versions of my hi res outdoor photos' which seems good to me.
I never fail to be baffled at the degree of inertia in the IT world. I sometimes thing every computer person thinks technology should be frozen at whatever point they got tired of learning new stuff. "File name extensions and symbolic links were good enough for me lad!" It's a weird attitude.
-----
Now storing the meta data in a database, which is essentially what WinFS and such are doing, is not as clear a benfit. Personally I can imagine that it would be a very practiacal FS for keeping movies and MP3's on. I don't really see the benefits of running the OS files on that FS though. A lot of unneccesary overhead. (I don't search for files in my OS partition very often.)
BeOS used a metadata enabled fully journaled multithreaded filesystem and it was the bomb.
Mail client? What mail client? You email inbox was a directory in the OS with all the email metadata attributes enabled in the file manager. Mail filters literally became shell scripts. Want to index your MP3s according to artist, album, etc all at the same time? Use the shell scripting and metadata, Luke!
It also does away with the stupid limitation of extensions. When all your data is stored as a datatype in the metadata listing, who needs them?
I think that Microsoft are going a little overboard embedding a database into the filesystem, proper meatdata enabled filesystems are a GOOD thing in my book.
Let's get one thing straight ... many of these features are already available in one form or another and no one uses them.
... I'm not against having an FS that enables you to annotate files outside of the programs that create them. I remember working many years ago with FSs that would allow you to automatically keep the last n revisions, which was very helpful when coding.
How many people click on Properites in M$Word and put in the information?? How many people download files and leave them lying in whatever directory they just happen to fall in.
Don't take me wrong
It's just that I have a hard time getting excited over something that is going to simply bloat a system and the odds are no one will use.
My girlfriend is fairly smart, but she still downloads all her pictures into the default folder, and uses thumbnails to find the ones she wants. She has about 1000 of them, and it only takes here a few minutes to find the ones she wants. It would take here no extra work than what this new FS is suggesting to rename the file and/or store it in another folder
Useful feature, bloatware, Linux beater, or disaster waiting to happen. My guess is all of the above, at one time or another. Some people will use it and spend hours cross-linking files. I'm sure the initial releases will have security or data loss issues until the bugs get worked out. It will take 0.10 minutes for some Linux hacker to reverse engineer the ability to at least read it. And it will probably take up gobs more memory.
It's all a matter of perspective....
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.