Tech Off Post

Single Post Permalink

View Thread: Why the need of NTFS as base of SQLServer/WinFS?
  • User profile image
    Tom Servo


    Running out of diskspace happens either way, on NTFS and on raw partitions. After looking some more into it yesterday night, SQL Server is well aware about the free space on the raw partition one way or another, since it maintains a bitmap about free and allocated datapages. A raw partition is more or less equivalent to a datafile created with the maximum size on the disk.

    The device abstractions happen below NTFS in the logical volume manager, where a "WinFS2" would run on too. Also error correction is a feature of SQL Server, defrag could be possibly implemented too, basic backup is available in SQL Server, and well software RAID is as said above a lower layer thing.

    One reason I'm probably nitpicking on this is that Microsoft made it look in the past like they were indeed dropping NTFS, maybe it was even intended, but then pulled out of that one shortly before or during PDC last year.


    WinFS doesn't JUST store metadata. While it may apply for old filetypes that you just promote into the store, it's not true for WinFS native schemas and future 3rd party ones. Unless you define varbinary(max) fields in your WinFS schemas, it won't spawn a NTFS filestream for the respective item types and the data associated with the fields will go into the table created by the schema.

    About the security, if you add filesystem semantics to WinFS, what speaks against adding security? It's not a NTFS only thing. The security also only works, aslong the filesystem is hosted in it's native environment. NTFSDOS for instance bypasses security, so your ACLs wouldn't mean anyhing in that case. For that matter, WinFS will get item-level security anyway, somehow you have to prevent other users to access your data within WinFS.

    And BLOBs would only work for unstructured data, which size won't change. Like email bodies and all that.