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."

Comments

Re:This article is bullshit

[Zork the Almighty]

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.

My turn

[poptones]

to say how much this article sucks. I should have known when I saw "Tom's" that it would be nothing but a few pages of useless drivel slapped into a directory as an excuse to sell ads, but I thought because this was a /. "cover story" it might be worth checking out.

Looks like I was wrong - or, actually, right all along. Musta been a slow news day?

Re:other FSs are out there

[afidel]

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.

Re:Better, not best

[Anonymous Coward]

Relational databases are better than conventional file systems in both performance and transaction management/journalling.

Relational databases focus on data relationships not physical storage, which is what conventional file systems do. Performance and transactions are completely orthogonal and depend on typical use and fault tolerance requirements. E.g. XFS has both performance and journaling (only metedata though) and is still a file system.

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.

Orthogonal Persistence = leave machine on indefinitely. What happens when errors and/or data corruption occur in core? Planned maintenance involving powering down the machine? How about persistent storage (backups, data transference, system upgrades)? And cost: do you think its cheaper to get a 64-bit machine and 500GB of ram to store EROS processes indefinately or a 32-bit machine with 1GB of ram and 500TB of disk space? The whole reason computer systems developed secondary storage is to address these concerns.

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.

Basically turn everything into memory mappings...and that limits your data size to your address sizes. May not be a problem with 64-bit addressing, but storage is growing exponentially.

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.

Modern filesystem already make such optimizations as do databases. Heard of LFS? This is a filesystem designed to do this for *BSD.

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.

And backups? Seperating data from instructions? Sharing data across heteregeguous systems? Or is the plan EROS everywhere?

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.

Yes, but a string hierarchy can be used to built a relational database by layering code and design. However, the opposite is probably less efficient, if it is at all possible. Basically, flexibility and modularity are better: a user can always buy addons for database features.

Re:other FSs are out there

[NightSpots]

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.

Re:Can you say SQL Slammer x 100?

[NightSpots]

This is completely unfair.

How many gaping security holes have there been in NTFS?

By most accounts, NTFS is one of the better filesystems ever written. Journaling, ACLs, decent performance.

There is talent in Redmond. Ignoring that is as flawed as assuming the entire Linux community is represented by Sendmail and SCO (security holes and bad publicity). Pretty bad, right?

Re:This article is bullshit

[doorbot.com]

Hey did the person who modded me "Troll" READ THE FUCKING ARTICLE ? DID YOU ? Read it. ... The whole fucking article is filler.

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 ;)). 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.

RTFA, /. !!!

[NetFu]

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.

WinFS was originally a desktop usability thing

[jamezilla]

The reason why WinFS was slated for the desktop first (and then later considered for server deployment) is because it was considered a usability enhancement -- not a performance enhancer. Most /. readers won't understand this because they think Linux is easy to use (it's not).

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...

data recovery nightmare

[drdoc]

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?

Re:other FSs are out there

[platypus]

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.

"Memory"?

[bluephone]

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...