Forgot your password?
typodupeerror
Operating Systems Software

Tom's Hardware Looks At WinFS 809

Posted by timothy
from the straight-to-the-nsa dept.
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."
This discussion has been archived. No new comments can be posted.

Tom's Hardware Looks At WinFS

Comments Filter:
  • by double_plus_ungod (678733) on Wednesday June 18, 2003 @12:38AM (#6229907) Journal
    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.
    • by localghost (659616) <dleblanc@gmail.com> on Wednesday June 18, 2003 @12:42AM (#6229941)
      Journaling doesn't reduce performance much, and at least for me, it's well worth it for the peace of mind, and the lack of fsck. Hard drive space is hardly at a premium, most people can spare the 10%, and without it, I spend 15 minutes scanning my 40GB disk every certain number of boots (or if it's not shut down right). If I used Windows, I'd at least give WinFS a try.
      • by SweetAndSourJesus (555410) <JesusAndTheRobot&yahoo,com> on Wednesday June 18, 2003 @01:46AM (#6230414)
        From what I've read and experienced, the performance hit only involves writes. Reads are unaffected.

        Writes are about 10% less efficient, which a pretty good tradeoff for that peace of mind.

        • by NightSpots (682462) on Wednesday June 18, 2003 @02:21AM (#6230629) Homepage
          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.
          • by platypus (18156) on Wednesday June 18, 2003 @05:23AM (#6231297) Homepage
            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 [sgi.com].

            • Oh, and forget softupdates, they are _not_ comparable to journaling filesystems, for instance you still need to fsck, it's just faster.

              That's true, but misleading. If soft updates are done right, the only reason to fsck is to reclaim resources (orphaned blocks etc.). It is not necessary to get your filesystem into a usable state, and can therefore be done in the background after you've come up. Journaling filesystems also still need to fsck, it's just faster and it's called a log redo, and that is nec

      • Alas it doesn't help (Score:5, Informative)

        by iamacat (583406) on Wednesday June 18, 2003 @03:49AM (#6230984)
        I use journaling and still get filesystem corruption that is not automatically fixed (like overlapped extent allocation) once in a while. On the other hand, HFS+ seems to already use a B-tree and file search is quite fast.
      • by Anonymous Coward on Wednesday June 18, 2003 @03:50AM (#6230988)
        It should be noted that the regular fsck should still be performed, even on a journaling filesystem. The fsck after an unclean shutdown is obsoleted by the journal, but the regular fsck is supposed to catch subtle errors in the filesystem code and hardware problems which can cause the filesystem structure to rot slowly - problems which a journal can't and won't fix.
    • by adamsc (985) on Wednesday June 18, 2003 @03:15AM (#6230860) Homepage
      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.
  • by xanie (446372) <xanie.xanie@com> on Wednesday June 18, 2003 @12:40AM (#6229915) Homepage
    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.
    • by NightSpots (682462) on Wednesday June 18, 2003 @02:26AM (#6230653) Homepage
      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?
      • by mindbooger (650932) on Wednesday June 18, 2003 @03:37AM (#6230945)
        By most accounts, NTFS is one of the better filesystems ever written. Journaling, ACLs, decent performance.

        ... fragments all to heck and back. Ever notice the absence of "defragger" utils in the non-microsoft world? IIRC, I'd read that NTFS was one of the _worst_ fragmenting filesystems.

        • by rekkanoryo (676146) <rekkanoryo AT rekkanoryo DOT org> on Wednesday June 18, 2003 @08:48AM (#6232147) Homepage
          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.)
    • by eidechse (472174) on Wednesday June 18, 2003 @02:52AM (#6230771)
      Uhh...no.

      Slammer exploits a buffer overflow in the sql server "named instance" resolution mechanism. It has nothing to do with the storage/querying/indexing/etc of relational data.
  • db filesystem (Score:5, Interesting)

    by Horny Smurf (590916) on Wednesday June 18, 2003 @12:41AM (#6229928) Journal
    Personally, I still have reservations about using a relational database to keep track of files.

    BeOS used indexing for certain attributes, and it is GREAT. Maybe someone is just sour that linux didn't do it first?

    • Re:db filesystem (Score:5, Interesting)

      by Osty (16825) on Wednesday June 18, 2003 @12:44AM (#6229959)

      BeOS used indexing for certain attributes, and it is GREAT. Maybe someone is just sour that linux didn't do it first?

      I gathered that the quote was alluding to the fact that while the BFS did initially use a full relational database backend, it performed very poorly. Be replaced the backend with a more conventional one, but kept the SQL-like interface to it. It increased performance, but just wasn't quite as cool anymore. Maybe now that PCs have increased in power by several magnitudes since Be last tried this, Microsoft may actually be able to pull it off.

  • SCO (Score:5, Funny)

    by Michael Crutcher (631990) on Wednesday June 18, 2003 @12:41AM (#6229934)
    Wasn't this supposed to be an SCO story? We're falling behind our quota today.
  • by mao che minh (611166) * on Wednesday June 18, 2003 @12:42AM (#6229937) Journal
    It sounds like Win FS will operate a lot like a completely closed ReiserFS. Like the author (and probably many here) I don't like the idea of using a relational database as a FS very much. ext2 might be a bitch to bring up after a crash, but I'll be damned if it isn't stable and well documented. Imagine how well refined ext3 will be in another 12 months.

    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.

    • by idiotnot (302133) * <sean@757.org> on Wednesday June 18, 2003 @12:46AM (#6229984) Homepage Journal
      They mentioned the problems that occurred when moving a volume from one machine to another. Something like this sounds even more risky if there's a problem. With a FAT or NTFS partition, there are many programs that can at least read the partition if the system gets farked to an unbootable state. How will this work with a DB? Furthermore, will you have to have a full OS up and running to be able to query and get data out of the DB?
    • by cookd (72933) <douglascook@juno.cBLUEom minus berry> on Wednesday June 18, 2003 @03:31AM (#6230919) Journal
      I think you miss the point of WinFS. It is actually a layer abover NTFS, so the actual files will still be stored the same way they are presently (and NTFS is pretty good about reliability). NTFS is already a lot like ReiserFS even without WinFS.

      What WinFS adds is more powerful indexing, not a new storage system. Whenever you add or modify a file, WinFS adds the file's attributes to its indexes. The attributes stored are customizable, and vary depending on file type (MP3s have their ID3 info indexed, etc.). For example: somerwhere on my 120 GB disk I have a file named "code.txt" but it will take 10 minutes to find it by scanning the directory structure. Instead, I do a "SELECT Path FROM Files WHERE Filename='code.txt'" and WinFS comes up with the answer right away. If I have full text indexing, I could search for a specific phrase. Even more useful, you don't have to make playlists anymore. Just put all of your MP3s in the same directory, and when you want to hear all of your Bon Jovi, just perform the appropriate query. (Obviously you don't have to know SQL to make this useful.)

      Some of this is already present in a more limited form in Unix. For example, I still can't figure out why Windows doesn't have something like the LOCATE database that is set up by default on my FreeBSD box. But WinFS will blow LOCATE away (update is real time, not daily, and it has much more than just the file name).

      However, from what I've heard, so far it is a bit of a dog performance-wise. I hope it gets up to speed by ship time... At least it can be turned off if you can't take the perf hit.
  • by Zork the Almighty (599344) on Wednesday June 18, 2003 @12:42AM (#6229944) Journal
    This article is bullshit. There isn't a shred of new information in it. It's like watching CNN.
    • by Zork the Almighty (599344) on Wednesday June 18, 2003 @12:52AM (#6230032) Journal
      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.
      • by hayden (9724) on Wednesday June 18, 2003 @02:19AM (#6230624)
        It's every slashdotters dream to get a "Score:5 Troll" post.
      • by doorbot.com (184378) on Wednesday June 18, 2003 @02:33AM (#6230689) Journal
        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.
      • by Jugalator (259273) on Wednesday June 18, 2003 @02:49AM (#6230755) Journal
        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.
    • by sprag (38460) on Wednesday June 18, 2003 @12:55AM (#6230061)
      Hear hear! I paged through the whole thing hoping to find some _actual_ information, but was really disappointed on page 6 which was basically the summary over again.
    • by more fool you (549433) on Wednesday June 18, 2003 @01:05AM (#6230141) Journal
      Welcome to the marketing revolution. A 6-page ad, made mostly of smaller ads. Why do I suddenly have the urge to purchase Longhorn & more memory?
  • Mmmm Hmmm Sure (Score:4, Insightful)

    by technomancerX (86975) on Wednesday June 18, 2003 @12:43AM (#6229953) Homepage
    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.
  • by Scoria (264473) * <slashmail@@@initialized...org> on Wednesday June 18, 2003 @12:45AM (#6229963) Homepage
    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.

    Well, yes; we must preserve those system resources for the most recent incarnation of explorer.exe.
  • nothing new (Score:3, Interesting)

    by g4dget (579145) on Wednesday June 18, 2003 @12:45AM (#6229970)
    This will be better than FAT32 and NTFS, but it is hardly "breaking new ground". A number of operating systems have used more-or-less relational databases as their file systems; it's a special purpose technology and has no place in a general purpose OS. I think ReiserFS makes the right kind of compromise here: it uses a little bit of database technology, but it mostly remains a traditional file system.
  • by xWeston (577162) on Wednesday June 18, 2003 @12:49AM (#6230007)
    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."
    • by xWeston (577162) on Wednesday June 18, 2003 @01:47AM (#6230418)
      I believe they originally planned to have it as an entirely new filesystem but that they wouldnt be able to hit the mark with it...

      The article that i got some of that information from was from The Register: http://www.theregister.co.uk/content/4/30670.html [theregister.co.uk]

      Also, there is more information here: http://www.winsupersite.com/showcase/longhorn_prev iew_2003.asp [winsupersite.com]
  • Maybe it'll work (Score:3, Insightful)

    by localghost (659616) <dleblanc@gmail.com> on Wednesday June 18, 2003 @12:50AM (#6230009)
    It sounds interesting, to say the least. Maybe Microsoft has finally come up with something innovative. I'd be interested to try it out and see how it feels, and if it really can do everything they say it can. As usual, though, security could be an issue. A virus could wreak havoc if it found a way into the database.

    Also, I'm wondering if they'll finally give up on that stupid drive lettering. I don't see any reason why that ever had to exist, and now that they're doing an overhaul of the whole filesystem, it seems like a good oportunity to get rid of it. You'd think, since they try to be user friendly, that they would want to give devices and partitions names instead of letters. I do still see it in that screenshot, but things could change by the time it's released.
  • Terrible article (Score:5, Informative)

    by dbarclay10 (70443) on Wednesday June 18, 2003 @12:59AM (#6230094)
    This article is tripe.

    The closest it gets to examining the (possible!) new Windows filesystem is calling it a relational database, and going on for a bit about how paths (ie: directory structures) will be irrelevant. Oh, and yeah, the closest thing he found to the implementation was called "winfs.exe" and did nothing but produce errors.

    The bulk of the article is a (poor) attempt at explaining filesystems in general, and FAT and NTFS in particular. However, it gets a number of things wrong and - at best - garbles a lot of things. If you already know what he's trying to say, you *may* be able to pick out truths, but if you don't you'll walk away with misinformation.

    I would suggest instead perusing arstechnica.com and aceshardware.com. I don't know if they've done any filesystem stuff, but if they have it'll be of reasonable quality.
  • Oh so informative! (Score:5, Interesting)

    by BasharTeg (71923) on Wednesday June 18, 2003 @12:59AM (#6230095) Homepage
    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.
  • My turn (Score:5, Insightful)

    by poptones (653660) on Wednesday June 18, 2003 @01:03AM (#6230128) Journal
    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?

  • by Gldm (600518) on Wednesday June 18, 2003 @01:04AM (#6230132)
    It's really irritating to have a RAID that gets crippled to 5-10MB/sec when on other OS and FS combos it can do 80-100 because MS has decided "Oh performance isn't important, reliability is, so we'll force cache off for all SCSI miniport devices even if it says it's on."

    See http://forums.storagereview.net/index.php?act=ST&f =2&t=1758&hl=slow+scsi+performance&s=9f0e65a3ff482 2032e4a63091694cc3f it never got fixed. Non-RAID IDE is unaffected supposedly due to a "bug" in the system where IDE devices ignore the OS commands to switch to write through caching. It's really ridiculous when a 700MB file takes almost 2 minutes to copy under XP and yet under BSD on the same system dual booted on the same array, it takes 11.2 seconds.
  • Good idea (Score:4, Interesting)

    by Bodrius (191265) on Wednesday June 18, 2003 @01:07AM (#6230153) Homepage
    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.

  • by sn00ker (172521) on Wednesday June 18, 2003 @01:08AM (#6230161) Homepage
    there sure were a large number of glaring errors.
    1) NT4 (certainly from SP3) allows you to make partition alterations without a reboot. Even 2K requires a reboot for alterations to the boot partition, however.
    2) 2K doesn't dispense with the drive letter concept, despite the implication in the article that this is the case. That you can mount partitions under folders doesn't change this.
    3) You can specify the cluster size when formatting a drive under NT4.

    Also, has anyone actually come across a data centre that is making use of multi-hundred-TB NTFS volumes?
    And, will Longhorn finally do away with the whole drive letter concept?

  • Better, not best (Score:5, Interesting)

    by Peaker (72084) <gnupeaker@@@yahoo...com> on Wednesday June 18, 2003 @01:09AM (#6230171) Homepage
    Relational databases are better than conventional file systems in both performance and transaction management/journalling.

    However, the best solution is that used by EROS [eros-os.org], 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.
    • by Anonymous Coward on Wednesday June 18, 2003 @01:51AM (#6230445)
      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.
      • by sql*kitten (1359)
        Orthogonal Persistence = leave machine on indefinitely. What happens when errors and/or data corruption occur in core? Planned maintenance involving powering down the machine?

        No it doesn't - it just means that from the perspective of an application, there is no difference between malloc() and open(). You ask for some storage, you get it (unless something goes wrong, of course). You read and write to your bit of storage. At some point it may be in main memory, in some cases it will be on disk. The OS take
  • Truth be told... (Score:5, Interesting)

    by Da VinMan (7669) on Wednesday June 18, 2003 @01:11AM (#6230185)
    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.

    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 [techtarget.com], 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! :+) Maybe the initial implementation wonâ(TM)t get all this right. But at least it stands a chance.

    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? [oracle.com]
    • by hansreiser (6963) on Wednesday June 18, 2003 @07:08AM (#6231592) Homepage
      Take a look at www.namesys.com/v4/reiser4_the_atomic_fs.html

      and at www.namesys.com/v4/v4.html.

      We will be adding support for semi-structured data querying in the next major release, assuming that we find funding for it. The semantics for it are described at www.namesys.com/whitepaper.html, which also explains why I don't think the relational model is effective for semi-structured data stores such as a general purpose filesystem is normally used for.

      Best,

      Hans
  • by Future Shock (634657) on Wednesday June 18, 2003 @01:11AM (#6230190) Journal
    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.
  • Fast != Fast (Score:4, Interesting)

    by WoodstockJeff (568111) on Wednesday June 18, 2003 @01:18AM (#6230232) Homepage
    I can see where a more efficient directory structure might be helpful, but... will they continue to sacrifice file access speed for file search speed?

    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!

  • by rot26 (240034) * on Wednesday June 18, 2003 @01:21AM (#6230254) Homepage Journal
    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.
  • by Nucleon500 (628631) <tcfelker@example.com> on Wednesday June 18, 2003 @01:42AM (#6230381) Homepage
    Most of what we say is guessing, because we don't know the question MS is trying to answer. I can't think of any goals best met by WinFS.

    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 [theregister.co.uk], but it's more efficient, it's more compatible, and it doesn't reinvent the wheel.

  • by podperson (592944) on Wednesday June 18, 2003 @01:53AM (#6230460) Homepage
    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.
  • by Professor D (680160) on Wednesday June 18, 2003 @02:00AM (#6230512)
    The headline says "... Looks at WinFS." I click on the link expecting to find some details about the upcoming file system and how it's going to be implemented. Instead there's just page after page of someone's high school paper on Windows' file system through the ages.

    Then at the end there's a few paragraphs with no real info about the FS at all. What meta info will be stored? How will the files be laid out on disk? Is there going to be journaling? How about file system integrity and recovery?

    The only thing _really_ learned was that there exists a 20MB beta executable that doesn't do anything. What the frell? It's two years before Longhorn is to be released. (As if Microsoft is going to get it right the first time anyway).

    Mod the whole article down. Way down.

  • New FS (Score:3, Interesting)

    by rf0 (159958) <rghf@fsck.me.uk> on Wednesday June 18, 2003 @02:16AM (#6230613) Homepage
    New file systems always worry me esp with regard to data loss. With FAT and NTFS they are old but they are stable. I've never seen the OS lose data, though if there is a sudden crash then yes, but not during normal operation.

    New FS = New corruption?

    Rus
  • Once again... (Score:3, Insightful)

    by pergamon (4359) on Wednesday June 18, 2003 @02:19AM (#6230625) Homepage
    ...MSWindows inches closer to where BeOS was 7 or 8 years ago.
  • RTFA, /. !!! (Score:5, Insightful)

    by NetFu (155538) on Wednesday June 18, 2003 @02:41AM (#6230720) Homepage Journal
    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.
  • Backards(w) (Score:4, Funny)

    by pyrrho (167252) on Wednesday June 18, 2003 @03:08AM (#6230827) Journal
    I think we'd be better off replacing the relational database with a file system.

    Just a joke SQLiers, just a little joke. I know they are indispensible. Really. I believe you.
  • by jamezilla (609812) on Wednesday June 18, 2003 @03:33AM (#6230929) Homepage
    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...

  • by stox (131684) on Wednesday June 18, 2003 @03:40AM (#6230955) Homepage
    3 years before release: Product will do everything for everyone.

    2 years before release: Product will do everything for the majority of users.

    1 year before release: Product will do many things for many users.

    Release: Well it does something.
  • by drdoc (640229) <info&alandata,com> on Wednesday June 18, 2003 @04:04AM (#6231040) Homepage
    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?
  • Yipee! (Score:3, Funny)

    by Realistic_Dragon (655151) on Wednesday June 18, 2003 @05:21AM (#6231290) Homepage
    Does this mean that finally the Windows file transfer counter will give sensible answers? Right now the only thing you can be sure of is that whatever it says, it's going to be something else.
  • "Memory"? (Score:5, Insightful)

    by bluephone (200451) <grey@nOsPAm.burntelectrons.org> on Wednesday June 18, 2003 @06:20AM (#6231470) Homepage Journal
    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...
  • by Moderation abuser (184013) on Wednesday June 18, 2003 @06:30AM (#6231493)
    Postgres as an rdbms backend to a filesystem front end.

    Designed mainly for version control. Could easily be modified for other purposes though.

    http://www.linuxjournal.com/article.php?sid=1383
  • by Junks Jerzey (54586) on Wednesday June 18, 2003 @10:06AM (#6232878)
    Personally, I still have reservations about using a relational database to keep track of files.

    A hugely conservative Slashdot reader? No way!

It is better to give than to lend, and it costs about the same.

Working...