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
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.
God - I remember hesitating going up to FAT32 - I had only just gotten win95 and it was nagging me like hell. Then I was nervous about upgrading to NTFS, then discovered how horrible it was not being able to use a drive with anything but WinXP. I have a triple boot with WinXP, linux and win98SE Really, there's no difference between the file systems for the normal user! Why upgrade when it doesn't make your life any better and it takes alot of bother and reduces compatibility?
BeOS used indexing for certain attributes, and it is GREAT. Maybe someone is just sour that linux didn't do it first?
It just can't be good. Using MS SQL as a database is bad enough, I couldn't imagine depending on it as a file system.
You'll have that sometimes...
Wasn't this supposed to be an SCO story? We're falling behind our quota today.
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.
A relational database setup should do wonders for file search and access. Most filesystems today weren't designed with 200 Gb drives and millions of files in mind.
I keep thinking back to my Amiga when a 40 Mb hard drive was huge. Hell, I have a keyfob with more storage space now! Can you imagine AmigaDOS (not FFS, the old, slow one) on a 200 Gb drive?
Learning HOW to think is more important than learning WHAT to think.
This article is bullshit. There isn't a shred of new information in it. It's like watching CNN.
In Soviet America the banks rob you!
This whole idea came to me in a dream a few months ago. I can think of many cases where SQL based filesystems would have serious performance advantages. It's not for everybody, but for some applications it would be great.
I Geek
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
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.
Do you like German cars?
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.
I find that 4gb (or is it 2gb?) file size limit rather annoying when doing video stuff.
The performance is the most important thing to the WinFS I think. I hope it could be faster than 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."
And, of course, this author is qualified to pass judgements like the one listed above. Please.
Exactly how efficient should a file system be, genius?
From the article:
"The folder structure shown in the Windows Explorer is thus reduced to a virtual map. Directory structures provide some guidance but do not say where data is actually stored, how the system organizes files or the nature of any data pointers stored with them."
In my miserably unprofessional opinion, obfuscation of the allocation tables in favor of virtual maps that are more user defined or, bettter yet, dynamic, learned content organizations are what the file system should be.
But I already qualified my opinions with the statement... "I don't have any idea what I'm talking about".
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."
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.
Once Microsoft integrates a relational database into the operating system, worm penetration will reach 100%.
Seriously though, I hope they port the registry over to a real database system along the way.
AmigaDOS had an 80 character or so comment field for each file. The comment didn't show up when you did a DIR, but when you did a LIST it was there. All of my pictures and sounds had nice descriptions in the comment, size/depth/mode/etc.
Very useful.
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.
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
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.
His post is darn insightful, wish I had some mod points :-/
100% Crunchier
How about Clippy? "I see you're looking for your work files. You're fscked."
One line blog. I hear that they're called Twitters now.
Looks like I was wrong - or, actually, right all along. Musta been a slow news day?
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."
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.
See http://forums.storagereview.net/index.php?act=ST&
Introducing the new Occam Fusion! Now with sqrt(-1) fewer blades!
NTFS has tons more advantage than FATxx. The official list can be found here. Granted, this benefits the corporate user more than home user.
At the very least, NTFS offers a quicker way to hide porn than FAT32.
I have a feeling that MS will do it half-assed, just like always... and in that respect I think winfs will probably suck, however if done right, it would rock.
The concept of naming files, and sorting them in directories isn't a very good concept, and the proof of it is looking at how everyone here uses playlists to handle media files.
None of us even know the filename for our mp3s anymore, it's buried in iTunes or Winamp or XMMS, we just know the artist, and the song name. As a side-effect, we can easily find songs by the same artist on our harddrives, or same genre.
This obviously doesn't require a database filesystem, but I think it's gotten to the point where we *need* some way to assign metadata to files and then deal with files *soley* by metadata.
I think filesystem creators could take a huge hint from Content Management Systems. CMSs are more powerful than filesystem, and much easier to use, especially when dealing with a huge number of files.
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...
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?
"God, root, what is difference?" - Pitr, userfriendly
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.
Personally, I still have reservations about using a relational database to keep track of...
Don't tell that to your brain, you might be forced to go to summer school...again.
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.
I'm a "normal" user (or at least more normal then most slashdotters I'm sure) and I use computers for the following things: Games, Music, School/University work, Internet. Perhaps watching the occasional DVD.
:)
Quite frankly, why should I, or any "normal" user, upgrade to a file system that doesn't make a difference to my everyday life? I didn't rush to upgrade to FAT32 or NTFS, and nothing in this article is convincing me that I should upgrade to WinFS. (infact nothing in this artice is saying much about it, but that's for another poster I'm sure)
I had another message about this, and was replied saying "what? There's many differences: in Fat16/32 you're restricted to 2GB/4GB files" etc etc.
My reply to this is that when I was using Fat16 it was with a 1.18 GB hard drive. I used Fat32 for a time with an 8GB (hard drive maker GB) hard drive, but why on earth would I have a file that took up more then half of my hard drive? The first time I ever had a file above 2GB in size was a few months ago with digitalised family videos (promise to mum
For upgrading to NTFS, I don't really care about gigantic cluster room. Why should I? I have an 80 GB hard drive filled to about 60 GB, so why should I care about one GB of this being filled with crap allocation tables? Since I can't have any OS before win2000 anywhere near it, say if I want to put my HD in another computer for example, the disadvantages far outweigh the advantages for me. I do have WinXP installed on another NTFS formatted hard drive but I'd prefer to keep the hard drive that has the majority of my important info as compatible as possible.
Now with WinFS, I'm probably going to put that on when I get another hard drive, but not before. There doesn't seem to be any point! I'm sorry to all of the video editors out there, but I really don't want to take the bother.
We, like everyone else, do not know anything about WinFS other than it will be possibly be used in Lognhorn, and will replace FAT32 and NTFS.
90% of the article was a completly different topic, how the older FSes work.
I'm working on a web-based relational filesystem that works to provide metadata using unix-style permissions as an overlay for additional security over the (1+) server's perms. If you're interested in working on such a project just send me an email to jobs@thinkingman.com. The project's called kahiko (hawaiian word). Mahalo.
Thinkingman.com New Media
Is there any open filesystem that operates in a similar manner?
I'm not sure exactly what you mean, but I'd say "all of them."
The way I understand it is that on Linux/unix, if you're using a file, it gets loaded into memory and then the copy of the file on the disk becomes completely irrelevant. Case in point: delete an mp3 while xmms is playing it; xmms will keep on playing it without any trouble. I've also moved/renamed files that were being actively downloaded by BitTorrent, and they came out fine.
and may I ask, how many people have 1000 40kb files on a hard drive let alone one that is 500MB in size?
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!
How'd ya manage to do that? I've used ReiserFS for years under heavy stress on several different systems and have never had a problem. It performs well. It's reliable. I've never had any data loss. Even dying harddrives didn't lose any data although obviously they made it give odd errors.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
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
Nevertheless, the current file system they have is technically far behind any reasonable database.
As a matter of fact, it should not take long to create an Oracle-based file system...
That's probably more applicable than you intended: File System Check
I don't really know what you mean. You can move files anywhere and they should still work as long as the program you are using knows how to find them. Sure if you wanted to you could replace a normal file opening statement with one that did a search for the file using SQL or something similar. This isn't really a filesystem function.. it's just a layer on top of it. It'd work with pretty much any filesystem and a database. Programmers often employ virtual filesystems to work with such information. If the program supports it then it'll work. You will notice they said that WinFS will still provide a directory structure for files.. so that existing programs will still work (And users won't be confussed).
With any filesystem you don't really know where on the disk the file is being stored. Directories are really just some glue to make it easier to work with files. It works well because most information is heirarchal. Unix/Linux also makes it easy to create links. This is an easy way to provide multiple heirarchies for the same files.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
it caches pixmaps, stupid.
Geeks everywhere have been doing this already for a long time. It's nothing new or innovative. It's even been done in the filesystem code by several different groups (and that's still a bad idea). I've been doing this with Linux and MySQL for years. Once again Microsoft is trying to claim innovation on something everyone else was already doing.
On the other hand I wouldn't mind seeing a standard library for this purpose if one doesn't already exist. I know Gnome has a VFS library. I'm not sure how much of it is reused by other projects or who originated it.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
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
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.
Worthless trivia factoid: From what I've read, HPFS was based on HPFS386, not the other way around. HPFS386 was written in assembler and optimized for the 386. HPFS was the "lite" version, written in C, and ran on either the 286 or 386. As you would expect, HPFS was quite a bit slower than HPFS386.
To ensure perfect aim, shoot first and call whatever you hit the target
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.
Sure. But quite a few of the features that are in NTFS are from HPFS (i.e. the basic b-tree design). That's why I brought it up. From the article it sounds like NTFS was a revolutionary part of NT -- which it wasn't. NT up until version 4.0 supported HPFS natively, FWIW.
Actually since it's just a metadata database index to the unerlying NTFS filesystem MS is kind of me-tooing, there have been linux implementation of this scheme using MySQL for ages.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
One interesting question would be, should this all eventuate the relational database filesystem that is. Does this then mean that the Windows "GUI" would then be a layer ontop of the database eg since the underlying filesystem is a database could third parties then create alternative "Window Mangers" for windows that hook into the "file sytem" This could be a good thing, stay tuned for MS selling "Coporate Desktop" and "Home Desktop" add ons for Longhorn
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
Cheap UK and US VPS
However, that would provide lots of scope for slashdot rantings about embrace and extend...
.haeger
While I agree with You that they'd have to extend whatever open/free FS they choose, I don't think that the "embrace and extend" would be an issue.
The GPL which both ResiserFS (I think) and XFS are released under won't allow Microsoft to pull any of that old shite. The GPL was designed with that in mind. Personally I think it would be great if MS would do this, anything to enhance and improve the open standards is good in my book.
You are not entitled to your opinion. You are entitled to your informed opinion. -- Harlan Ellison
It's every slashdotters dream to get a "Score:5 Troll" post.
Nerd: Derogatory term typically directed at anybody with a lower Slashdot ID than you.
...MSWindows inches closer to where BeOS was 7 or 8 years ago.
Security is built in below the operating system. It does support an "integrated file system" that presents file paths other systems can understand for the sake of interoperability and portability of Java libraries.
-- All your bass are below two Hz
The first paragraph of this article is all over the shop like a mad woman's knitting. I particularly like,
Yeah right, coz that's where the physical memory is.
And this new filesystem is supposed to be good because you can search for stuff faster or something? Why not just don't lose your files in the first place and update your locate database daily and fuck I fucking hate those dirty monopolistic fucks and Redmond is hit by an almighty fucking asteroid and fuckety fuck fucking fuck.
Now wash your hands.
Bah! That's nothing. Open up a few directories in Nautilus that have lots of pics in them and you can get a truly massive memory footprint. I'm sure that'll be fixed sometime after they add NNTP support across the board.
Anti-social? My code is just platform-specific.
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.
Yeah, the filesystem that was already obsolete within a year of its initial release....
HPFS had a hard coded limit of 4G partitions.
And no amount of juggling could raise it.
That's why M$ ditched HPFS support in Win2K.
Very good attitude, quite refreshing on /.
Different strokes fer different folks etc.
The point is, MS seem to be looking forward, to the new users rather than trying to appease existing windows users. From what I've read, the new file system/structure seems pretty logical. Especially if you try and think of it as something other than a 'desktop file system'.
I look forward to seeing it develop. At least MS are trying to innovate.
Hmmm.
I have ~ 160,000 files taking up 55 gigs on my NTFS partitioned hard drives. It took over 5 minutes on my 1.6ghz machine to come up with that.
To search for a specific file often takes much longer.
Personally I look forward to a better, faster file system on Windows. Although I'd still hold off judgement of the new system until it becomes available.
-
Rod
I noticed right clicking in Win Explorer in Win2K allowed you to apply attributes to files. Not sure if they were limited to MS Office files.(Sorry, I can't check this anymore ;-)
The metadata in database, files on disk is used frequently in any number of applications. Some search engines do it (at their heart, search engines are databases - just not usually relational). I've also seen email servers, document management systems that do the same.
Even good ole rpm does the same thing, doesn't it? I thought the rpm info was stored in Berkeley database, and has pointers to the real files on the disk.
Applying RPM in a more generic way to user data files would get you the same result if you tack on a search engine.Let's see, even without it:
rpm -qa|grep tax
But the thing that freaks me? Do I really want a MS database product to use my filesystem?
So does Anonymous Coward have good karma?
Whenever any OS hoses any filesystem severely, run a burn in test program or at least a memory checking program to make sure something in your hardware (*cough* bargain basement RAM *cough*) isn't the culpret.
Any sufficiently advanced influence is indistinguishable from control.
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.
-pyrrho
Ah I see. My bad.
I did use command line copy on both OS's. I've also tried tons of "accelerator" programs that claim to be faster at copying. I tried same partition, different partitions, changing cluster size to every possible setting it allows, etc. With Atto, the drive performs well once write size gets over 256K, but the OS's internal copy routines for both command line and drag/drop apparently want to write one 512 byte cluster at a time and confirm it went to disk before writing the next one, which is crippling the write performance because the writes won't cache or stripe.
Just "right click, turn on write cache etc" (from a previous post to this) DOESN'T WORK. If you'd care to READ what I originally posted I mention that it indicates write cache is enabled when IT ISN'T. It's pretty obvious whether it is or isn't based on the write performance. When read is 80-90MB/s and write is 1/10th of that, there's a problem. It's called the OS is forcing write-through, i.e. confirm all data to physical disk instead of just write back to the cache.
As for the controller, it's a 3Ware Escalade 7500-4, not one of those POS promise things. The drives are 4 Western Digital 1200JBs in RAID5. My previous Escalade 6400 and 4 75GXPs in RAID0 had the same problem. (this was asked in one of the previous posts)
Introducing the new Occam Fusion! Now with sqrt(-1) fewer blades!
"fsck" usually isn't a typo!
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.
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.
Microsoft already has a file system that is integrated within a relational database. If you install Exchange 2000, you will see an M: volume on your local drive. You can flip thru this using Explorer as if it were an actual drive. In fact, it is a representation of a back-end relational database. The speed seems adequate to me so long as you have less than 8 GB in your mailboxes and public folders.
jwg
Well, seeing how much of a pain in the ass I once found using an NTFS drive when trying to boot from disk - or share partition space - I'm not sure I'll like this one much either. FAT32 can be a pig at times, but with mostly-large files anyhow, and a big drive it doesn't affect me much.
Now, making a whole partition unavailable to my "legacy OS" is a real pain. Win98, which up to awhile ago was still the only thing that worked with my old apps... though XP is functional now with new drivers, but not perfect.
And, oops, virus, screwed up windows, whatever... boot disk no workie with NTFS, it's a pain. I think I'll stick with FAT32...
My old OS can still play with it, I know it doesn't have any unexpected glitches, and even 'nix can mount it nicely.
However, for the future, as in a few years, maybe I'll check it out - if I even run an MS operating system by then.
Oh, and speaking of 'nix, aren't there utils to link a database into the FS to optimize searches? It's not entirely necessary to do it all the time by integrating into the FS, just do a scan+update on a periodic basis
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...
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.
"To those who are overly cautious, everything is impossible. "
The former British computer firm ICL (now, at best, a subsidiary of Fujitsu) invented a context sensitive file system called CAFS. This was hardware based and could search up to 1MB per second!
Looks like another piece of MS innovation.
Commercial licenses for ReiserFS are available; according to Hans Reiser, Namesys makes most of its money from NAS vendors who don't want to reveal that they use ReiserFS.
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.
Damn, so I have to buy Microsoft SQL Server and the Internet Connector License for something like $10.000 just to run Windows?
They're after my money again.
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?
I Agree With This Post (it's 4 GB)
Windows 2000 pre-installation environment3 /Index.c fm?ArticleID=38308
linky and as always, google is your friend
http://www.winnetmag.com/WindowsServer200
1q2w3e4r5t6y7u8i9o0pqawsedrftgthyjukilo;p'azsxdcf
It also fits on a usb keychain, knoppix sorta works too, but no ntfs writes.
And god, is the "wait 2 minutes to post another message" annoying.
1q2w3e4r5t6y7u8i9o0pqawsedrftgthyjukilo;p'azsxdcf
One thing I have never understood is why it takes so long to find files in FAT/NTFS systems even with their evil indexing services which grinds away at the disks and gobbles CPU cycles at random intervals while slocate is instantaneous and the update is almost as fast (slocate -u). I haven't tried slocate on windows partitions, but I expect it would do a similar job here. Perhaps someone could port this over to save us from needing longhorn?
FAT32 Formatting in Setup is an option, but is known to frequently fail or have significant errors
No it doesn't.
Just a side-note, when you format a drive as FAT32 using XP/2k, Win98 won't recognise it and won't let you install to it ("Bad Media Block"), eg. when you want a dual-boot between 98 & 2k.
Also, if you have a look at the Partitions while using a Linux-based partitioning app (eg. Disk-druid, fdisk) you'll see a whole stack of < 1MB or < 4MB partitions everywhere.
Yurk. fdisk all the way.
I'm sorry, but ReiserFS is a meta-data journaling only file system. This means that it does not protect your data at all. It only protects the integrity of the file system. This goes for other journaling file systems like NTFS and XFS. Ext3 is somewhat different in this regard as it can be made to do data journaling as well as meta data journaling depending on mount options.
/jarek
The problems with ReiserFS 3 are not all that unknown. If you ever found files on your system that contain junk appended to the real data you've found a known problem with ReiserFS. I believe that this has actually been solved in later kernels but the solution was not part of 2.4.0 for sure.
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.
Beep beep.
Actually, when you delete a file in linux (or any other *nix), you do not actually delete it yet when a process still has a handle to it; it only becomes unopenable for processes. Only when the last process that has a handle to it closes that handle, the disk-space containing the data for that file will be freed.
Compare this to DOS/Windows or NetWare; there a file cannot be deleted while a process has it opened. You will get some sort of error if you try.
Wenn ist das Nunstueck git und Slotermeyer? Ja! Beiherhund das Oder die Flipperwaldt gersput.
This is about denying Linux and BSD compatibility to their file system. NTFS is being reverse engineered as we speak, write access is being worked on, so obviously Microsoft needs something new to get rid of them pesky Linux people.
All the new and great features could be done with a (simple?) layer between NTFS and the application. There is no reason why Microsoft needs to invent a new file system here.
Realistically there isn't any reason why a file system implemented as a transactional database couldn't be as fast as a traditional file system and a whole lot more stable. The only additional overhead that theoretically is built in is file creation/deletion/moving. Reads and writes to disk for most of the better implemented databases tend to be at the cutting edge of what most systems can even push to disk. If they limit the functionality to the few goodies listed in the article it will actually be a joke on MS. This thing has a LOT of potential, ESPECIALLY on low end hardware.
Anyway, when i first heard about WinFS (maybe a few months ago), people were saying that all data on the hard drive would pretty much just be stored in a big blob, and that the database would basically index where each "file" in this blob is. Now, from this article (and from the comments i've gathered here) that doesn't seem to be completely accurate, but... eh. Database is a database i guess.
So i thought, if the database is doing the job of indexing these files for the operating system, then theoretically you could have, like, a database of what basically amounts to a whole bunch of symlinks. So you'll have your blob of file(s), your "original" database, and then your "symlink" database (for lack of better terms). I was thinking, if you could have that symlink database, you could pretty much choose where in the file system (as it appeared to you, the user) each file would go, and how it would be represented.
For example, say that you want My Computer to just be / (like on UNIX, basically). You could have a utility that tells your symlink database to set My Computer's "location" as /. That is, it "holds" all your drives and stuff. So then maybe you could set C:\ (your primary hard drive) to something like /hda, and set D:\ (your DVD drive) to something like /hdb. Et cetera.
Say you never messed with the stuff in your Windows directory, and you don't want a bunch of extra junk on the root level of your hard drive. Tell the symlink database to hide /hda/Windows (if we're continuing with the file system i'm kind of creating right now, heh), and that's that. It's basically like a hidden file, i guess, but that's not really the point (hiding folders, that is). The real point is, say that you did mess with your Windows directory, but you didn't want it on the root level of your hard drive, for whatever reason. You could tell your symlink database to "mount" the Windows directory to any place your heart desires. So, if i wanted, i could have my Windows directory located in /hda/hax0r stuff goes here/i like bacon/kthxbye.
Stuff like that. Or i could tell the symlink database to hide certain types of files. Or i could construct a full UNIX file system in Windows, complete with /dev, /usr, /bin, /etc, and all that other jazz. Or i could create my own file system (as i kind of did above with the /hda stuff). Maybe the symlink database utility would come with pre-set file systems for the user to choose from. Or something.
I don't know, i just thought that would be a neat idea. I know that symlinks and aliases and all that can kind of (but not completely, in most cases) accomplish the same thing, but a databased file system like what i described would be far more robust and manageable. Just a thought i had. :/
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 ]
Postgres as an rdbms backend to a filesystem front end.
3
Designed mainly for version control. Could easily be modified for other purposes though.
http://www.linuxjournal.com/article.php?sid=138
Government of the people, by corporate executives, for corporate profits.
Note that a "relational" or "set theoretic" filesystem does not neeed to mean SQL. SQL is the COBOL of relational systems.
:-( ), and the same file can be in multiple directories, just make the filesystem able to instrospect on a file to determine directory-membership,and perhaps add union, difference and intersection operators on directories (though they could be built in userspace, it'd be more efficient in-filesystem, and e.g. AmigaOS already had union operations.)
Personally, I'd like a set-theoretic FS. You could even do it reasonably easily with a small change to today's technology - just make the (unix-like) filesystem be able to answer, for a given inode, what directories that inode is linked in. Combined with hardlinks (including directory-hardlinks to allow membership of sets by sets to give relational capabilities... i don't buy the "circular reference" argument, one could GC the filesystem.), that instantly gives you a set-theoretic system, where each file can be truly present in a number of "sets" i.e. directories. Consider the statement: "Saying a file has attribute X is equivalent to saying it is a member of the set of all files with attribute X."
If directories are sets (and they are, except they mix in name-assignment too
With "stat -c%i" and "find -inode" in a shell script you can already emulate a lot of this, to a level sufficient to multidimensionally sort your... uh... image library. I might write a k5 story detailing the method, if I can be bothered.
"using a relational database to keep track of files"
I don't believe it, I've been hoping for this recently.
Could it be plausable with specialised hardware, such as the database itself stored seporately and keep tracked data seporate?
I'd really like to be able to search quicker, a linux database fs for just a few files on a seporate harddrive anyone? I can't run updatedb constantly, but if it was incremental that would be interesting.
A blog I run for the wealth
Personally, I still have reservations about using a relational database to keep track of files.
Isn't that what what the AS/400 does..?
(At least, I hava a faint recollection of my old man (mossy old main-frame-guy) arguing this as a reason why OS/400 is surperior to Unix.)
Ethics is what you say you do. Morals is what you actually do.
"WinFS is not a file system" Now they are using recursive acronyms as well. Someone posted this on /. before, had to repost this one!
This is gonna be a M$ classic :)
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
> Geeks everywhere have been doing this already
> for a long time. It's nothing new or innovative.
Only, coming out with a crap-ass alpha isn't the only thing that counts as "innovation". Pushing it out into the "real world" and getting real people to use it also counts.
To that extent, Be is the only one who has innovated here - because they got a decent FS out into the hands of actual users (that they didn't get too many users is not totally thair fault). As for random geeks developing "their own libraries", and Gnome's VFS -- I suggest they ship something real before you start drooling about 'innovation'.
Go somewhere random
[i]fragments all to heck and back.[/i]
Does it really affect performance? I am not sure about that. But the reason that you see the fragments is because the defragmenting utilities show them. They create the need for defragmenting by showing the fragmentation.
The difference between differnt file systems is still often a factor 6. This is in the design, and has notthing to do with fragmentation. Any file sytem will have severe fragmentation if the disk is used with very little space free. This is exactly what happen with the average geek PC that will get overloaded with gadgets.
By the way, i have seen a ext2 defragger. quality was "use at your own risk".
So I still need a dodgy defrag to keep my disk nicely packed or it finally does like ext2, where you keep it clean just by using it?
I guess this is still on topic but...
...........
I noticed NTFS wastes a lot of space with its MFT. Creating a batch file to test NTFS shows how space is not recovered when creating and deleting even a small number of files. I figured it out after I noticed 600MB of file space missing on an empty drive that I moved all files from. After reformatting and copying them all back, only 90MB was used by the MFT.
[begin]
echo "----------------- 1:" >>AAAA
dir AAAA >>AAAA
copy AAAA BBBB1
copy AAAA BBBB2
copy AAAA BBBB3
copy AAAA BBBB4
copy AAAA BBBB5
copy AAAA BBBB497
copy AAAA BBBB498
copy AAAA BBBB499
copy AAAA BBBB500
echo "----------------- 2:" >>AAAA
dir AAAA >>AAAA
del BBBB*
echo "----------------- 3:" >>AAAA
dir AAAA >>AAAA
notepad AAAA
[end]
Running this in a directory more than once will show space is not lost but the first time I lose between 30K and 400K.
Can anyone using WinFS and NTFS see a difference?
Do your best, hope for the best, suspect the worst.
..This means I can't use Norton Disk doctor from '95 to "recover" my files anymore!????
Damn.
On a serious note, I'd love to see the development being done on forensic analysis of this new filesystem
Rob
Yes, I noticed since I upgraded from WinNT to WinXP, the file system seems to be much slower. When you open a folder in Windows Explorer it takes a second or two while in WinNT it was instantaneous. I tried tweeking it (removing indexing service, etc.) to no avail. The fact that I have SCSI drives makes me think that this might be what's causing it
The article doesn't address the most important question on every /.'ers mind:
Will copying a 200 MB file be faster or slower than on an old Mac 8600/300?
(For those who don't read Apple related articles often, this is a reference to a famous troll, not an attempt to start a "which OS is better" war.)
pictures could be about 40kb on average each, and it's easy to get 1000's of those.
500MB+ is great for DivX movies, which also come in the pr0n variety.
Learn from the mistakes of others. There isn't enough time to make them all yourself.
Avoiding deadlock, dealing with transaction timeouts, controlling permissions on who can keep a transaction open for how long, these are all very serious issues that have us first making transactions available to plugins and trusted processes only in the first release. However, there is a LOT you can do with just plugins and trusted processes to make user data more secure.
The name you see in the win2k file properties is metadata stored in the file system, it is not part of the file itself and does not add to its size, certainly not worth 16KB. If you try to copy the document from the ntfs partition it is on to a FAT partition that does not support this metadata you will get a warning that some information will be lost.
I'd guess that openoffice has a more efficient implementation of the doc file format, word must be storing blank space. Word can also store file revision historys, you can see how many time a file was edited, what changes were made, etc. perhaps openoffice does not support this.
"Taligent is still pure vapor. Maybe they'll be the last who jumps up on Openstep... "
SELECT * FROM [TomsHardware] WHERE NOT IsNull([Content])
---
(0 row(s) affected)
Putting transactions into a file system is retarded.
An ACID file system would mean that images would probably take 10 days to write, and that, if someone was writing a long file, and a short file, all users of the short file would have to wait until the long file write was complete.
This is my sig.
Gosh, I did not know that. Amazing. Always wondered what that command stood for. :^P
One line blog. I hear that they're called Twitters now.
I noticed right clicking in Win Explorer in Win2K allowed you to apply attributes to files. Not sure if they were limited to MS Office files.(Sorry, I can't check this anymore ;-)
.AppleDouble directories for an approach to foreign datastreams...they can get ugly pretty quick.
I believe that NTFS supports multiple streams of data per filename much like HFS. However, Windows doesn't make the pervasive use of the capability that Apple did in OS 9. I think one reason is that pretty much anything can go in these multiple streams meaning that particular files are tied even more closely to particular applications. Another reason may be that multiple filestreams complicate transfering files from machine to machine.
You're correct about RPM. It is using a more conventional approach by chucking it's data in a database file. Read about Netatalk's
The original HPFS (OS/2 1.2) was written for the 80286 by Gordon Letwin of Microsoft.
Mea navis aericumbens anguillis abundat
I noticed that its faster to copy a large file on a NTFS 5 (W2k and higher) partition to another NTFS 5 from BeOS 5 then in / from Windows Explorer.
:(. So I'm using BeOS to move files from there to a FAT32 partition that W2k3 can read.
For you who don't know BeOS 5 does support NTFS read / write of NTFS. I think they licesenced it or something as it works great except it leaves a folder called "RECYCLER" and it shows all the hidden system filesystem structure files / directories.
I'm now using the BETA of W2k3 Sever and it can't read my old Win2k NTFS partition. It says unknown filesystem and I can't mount it from the logical disk manager
-- I don't buy it, I grow it.
Soon, your OS will be based on a RDB, so get over it.
I am very small, utmostly microscopic.
Heyyy, that's our clever geek naming convention... (WINFS = Winfs Is Not a File System)
My beliefs do not require that you agree with them.
I don't think it is possible to configure ReiserFS wrongly and to lose data as the above suggests. What is very possible is to use it with the wrong kernel and obsolete utilities. If you use ReiserFS with RedHat, get an OFFICIAL kernel from Marcelo, not a redhat kernel, and get the latest utilities off of our website.
I would take a guess that the users complaining about losing data are redhat kernel users and the ones that are happy are SuSE or official kernel users. When you compare stability of ReiserFS and ext3, try to compare them using the same version of the official kernel. We have generally been more stable than ext3 in the official kernels at any given moment in time, in large part because we were about 6 months ahead of them in the development cycle. Remember that RedHat does not tend to keep up with ReiserFS updates in its nonofficial kernels.
Recent RedHat kernels are probably much more stable than the old ones because they have bugfixes from more recent official kernels, but remember that these are the guys who in one of their releases compiled reiserfs with debugging turned on to make it slower than ext3, so I would go with an official kernel if it was me.
V3 of reiserfs is very stable currently. We go for months without bug reports and we have a lot of users in Europe. This is in large part because we put all our new features into V4. V4 will be unstable for quite some time.
Smells like AS/400+DB2!
Hey! As long as you're going to combine the FS with a DB, why settle with the relational model? PICK all the way!
What FS do you think Dell is going to use?
My point is, in percentages there is no choice. When you say "you" have a choice, you are referring to the very small percentage of people who know what a file system is. Ask 100 people what file system they use on their computers, and most will probably say "windows".
That is how Microsoft works, they play the percentages (which they own). So yes, you do have a choice, but the collective "you" doesn't have a choice because they don't know or care what a filesystem is. I know, this is Slashdot, and you have to speak to the crowd, but to win the "game", MS doesn't have to win over this crowd.
And for all I know, WinFS may be awesome - but I'll probably never use it.
My beliefs do not require that you agree with them.
When you end up with 200 Megs taking up 1Gb on disk I'd say it affects performance.
That is called slack. And that is a problem with many small files. Especially under FAT the minimun amount of space a files takes is quite large. That NOT fragmentation.
Defragmentation almost never saves you any space. saving space is called compression. (And compression leads to fragmentation in w2k, now that is a braindead implementation!)
Fragmentation (might) occurs if the is a low % of free space. 1 GB free on my 120 GB disk is bad. 1 GB free on my 4 GB disk is (mostly) OK.
One quiblle:
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?
Because Oracle is as monopolistic in intent as MS, just not quite as good at it?
IFS was a horrible failure. Oracle has a history of this sort of thing - throwing something out there and hoping it sticks, without really treating it like a true product. Remember WebDB, I think it was called?
IFS has a lot of problems (interaction with backup tools, orthogonality of intent, decent tools to take advantage of what gains actually are there, etc.).
Even the link you posted reads really defensively, as if a project manager is attempting to justify their job.
I forget what 8 was for.
Tom says that NTFS stores file system information
in the registry. All of a sudden I am worried that
if my primary drive fails, I won't be able to read
the files on the secondary drive, even if I mount
it in a working system, because the registry information wouldn't be right for the drive. That would be just like MS wouldn't it. Don't a lot of people use a second drive as a backup?
What ever happened to PostgresFS. I seem to remember sonething about it in like 1997.
SGI's attitude that XFS is unbreakable, therefore they don't need to make tools to fix it is a pain in the arse. XFS does go wrong, it does stuff itself up, and can't always recover at mount.
They tried the "it can't possibly go wrong" stunt with Irix. A few versions later the repair tools turned up... Until they include some decent repair tools with the Linux utilities, I have no intention of letting it anywhere near my data, I've been burned by that one before.
"All users of the short file would have to wait until the long file write was complete"
You do realize that change-vectors in a journal can be interleaved?
And that there are well-known technological solutions to allow concurrent r/w operations in a single file/table without readers ever blocking writers? (i.e. Oracle or PostgreSQL's multi-versioning)
The only part of an ACID file system that usually requires some leeway, as in a database system, is the "I", isolation. You could crank that up or down depending on the needed semantics of your situation. Consistency and durability are there in most file systems, atomicity less so.
-Stu
>What I think would be cool would be couple a relational
>file system with a version management tool - you can
>find any file and any previous versions of it.
Didn't VMS do that back in the 80s?
"America has done some terrible things. But I know that Americans don't cheer when innocents die." -Dave Barry
Sourceforge will soon have another project called LinFS that is compatible with WinFS.
From excellent karma to terible karma with a single +5 funny post...
I'd live to finally see the ability for an MS filesystem to allow for true symbolic links.
Trolls lurk everywhere. Mod them down.
Why do people do things simply because they can?
-Slashdot Junky
.
Landfill Mining Co.
Managing the (Un)natural Resources of Tomorrow
WinFS Is Not (a) File System!
See the subject, biatch.
"America has done some terrible things. But I know that Americans don't cheer when innocents die." -Dave Barry
It was written by Gordon Letwin, but he wrote it first for MS Lan Manager, then later ported it to OS/2.
To ensure perfect aim, shoot first and call whatever you hit the target
Personally, I still have reservations about using a relational database to keep track of files.
A hugely conservative Slashdot reader? No way!
Not having read Tom's Hardware review of WinFS, but from the sound of things of the post, if WinFS is supposedly using a relational database to keep track of files, this sort of already sounds like what MS is implementing in some of their exisiting software such as Exchange and Sharepoint. Sharepoint utilizes Exchange-like file system where you can store files into the Sharepoint repository. In the first delivery of Sharepoint, there was an upper bound on the size of an individual file to be stored (I believe it was an 4GB limit) but in the current release I believe there is no upper limit. From what someone had told me if i recall right, Sharepoint utilizes the SQL engine to keep track of the files that are stored in Sharepoint. Maybe MS is just taking what they have learned from Sharepoint and making it more 'general purpose' for day to day use.
I've seen the same sort of progressive slowdown with my Win2K box using NTFS that I used to have with Win98/FAT32, and that's only using about 2/3 of the drive or so. I've never seen a filesystem on Windows that didn't regularly get horribly fragmented and accumulate a noticeable drag on performance (with a resulting return to "health" after defragging).
"I call a baby goat a 'goatse.'" -- my non-Internet-savvy 6-year-old stepdaughter
HOST $dir login.com
Directory DEV:[DIRECTORY]
LOGIN.COM;10 LOGIN.COM;9 LOGIN.COM;8
Total of 3 files.
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.
I love the name after hearing Win FS I was thinking Windows file system. As the years go by softwate gets funkier and funkier names.
A filesystem like this is great for organizing music and media files, something I know a lot of people currently struggle with. Songs frequently fall under multiple categories at the same time solving the problem of not being able to sort music by author and album at the same time with directories.
Chris
Microsoft can require the bootstrap call routines from a separate DMCA/Patent protected, Microsoft branded, bootstrap ROM, and can control motherboard vendors through licensing for that chip.
Nasty Microsoft if they try that. Someone better get some prior-art out there and QUICK!
--- Nothing clever here: move along now...
This idea isn't new... Microsoft as long been trying to nip at the heels of IBM's midrange platforms. The system/38 shipped with a relational-only filesystem over 20 years ago. This filesystem is still alive in the AS/400 and iSeries systems. The advantages really are nice... merging the filesystem and the database, combined with a really smart optimizer, allow you to run a high performance database without having a DBA constantly monitor it. You end up with no tablespaces or any of the rest of the cruft that occurs when you try to build a database using files.
If it were just that, it might be laudable... but what MS is trying to do here is really more nefarious... MS is really trying to rid itself of all non-MS databases on Windows. This is the old IE vs Netscape trick. Why would you buy a real database when you're forced to buy SQL server anyway? Enough people might not know the difference
I wouldn't be surprised at all if this is what motivated MS engineers to do this, but it also highlights one of the problems MS has: Their broad user base. As someone who just lost his job admining 20 Windows users I know that just as many Windows users never use the desktop as MS might assume. While Windows offers just about as much functionality in terms of drag and drop and meta key modifiers (Ctrl-Drag for copy etc) as the Macintosh does, Micorsoft never advertises this functionality. Most standard users don't even know what the right mouse button is for and do most actions either through the toolbar or the menu.
Oracle has a database hosted file system as well, the Oracle Internet File System.
e s/ index.html?ifs.html
http://www.oracle.com/ip/deploy/database/featur
I suppose if I had to have my filesystem in a database, I'd rather have it in an Oracle database. Lord knows how much fun M$ SQL Server has been.
To sum it up : WinFS will be based on a relational database of some sort. That is ALL this article says about WinFS.
It goes on to tell you about FAT16, FAT32, and NTFS 4.0 and 5.0 (which they don't even bother to number).
Good info on the previous FSes, but comes up short on the topic that the article was meant to encompass, namely the WinFS filesystem. If you're looking for hard-core information on how it works, you're out of luck.
I don't know why anyone should care about it. The only place I've ever had trouble finding anything was on a Microsoft platform. Everywhere else find and grep come to the rescue and don't take much time at all. You would think that someone would slap a graphical front end on a combined tool.
Friends don't help friends install M$ junk.
One of those is more than 20 MB in size...Currently, however, all existing system files have no function or produce nothing more than error messages.
that's the default behaviour!
I found that a tad amusing.
maybe $ms-gorillaz invaded/cracked their servers and uploaded it. Xor payed them (the greedy-capitalist of THG) to put it there them selfs (if you look, at THG now, and a few years back, one can conclude that greedy-capitalist have increased in THG over the time).
I don't claim I know more than I know, and if you know you know more than I know, then by all means, let me know.
Finally, I can stop naming my folders like: ...
;)
cute brunette
cute brunette in dress
hot blonde with guy 1
hot blonde with guy 2
hot blonde with dildo 1
Now I can attach meta data like
hair color,
props (clothing, toys, surroundings),
# partners,
partner gender(s),
whatever else... you get the idea
no comment
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
Well, VMS has database support in the OS, and file versioning, but RMS is not actually integrated within the file system.
Gamingmuseum.com: Give your 3D accelerator a rest.
It is my understanding that fat32 limits the number of entries in the root directory to 65,535. Can someone shed light on this?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
This will eventually close the markets to products like Oracle's Collaboration Suite. The main advantage to keeping files in a Relational DB layer is that changes can be related to transactions and can be rolled back without having to resort to a restore from tape. This is handy if you're developing code or keeping track of a huge number of user files and restore requests. When this functionality is built into the OS, it will put the nail in the coffin of anybody offering Content Management Systems.
So all Windows PCs in the future will have files sytems based on a relational database (i.e. SQL server).
Imagine how much more devastating SLAMMER would have been if it could have infected every one of them instead of just the ones with SQL server installed.
I don't think the inefficient overhead will be a problem. The new Intel IC's and frontside bus speeds need somthing to do.
What I wonder is, how will the Linux community respond to this.. will Wintel machines take over?
Ross Youngblood
All it did was put 'WinFS' in the title, then proceed to talk about the advantages and disadvantages of the other, existing file system.
It had no new information on WinFS whatsoever.
Useless.
.... partly..... and barfed.
I know a thing or two about filesystems: I work in the data-recovery business.
This article was written by someone who has some basic details, and has fantasized a lot of incorrect info around it. Bunches of terms are used incorrectly etc. etc.
NTFS is a very well-thought-out filesystem. It can be made to perform well, and has almost no limits. (it does have limits: For example, files are limited to about 16 Billion gigabytes. Something like that....)
I sure hope they don't throw away the good things about NTFS....
Microsoft makes very little "good" software. But the NTFS filesystem generates the impression that it's different. They probably didn't design it themselves.
It also fits on a usb keychain, knoppix sorta works too, but no ntfs writes.
I just started experimenting with Knoppix so I am far from an expert on it, but your statement caught me offguard. Knoppix may mount NTFS as RO, but cant you manually remount the partition RW?
Personally, I have never mounted NTFS RW from Linux of any flavor, but part of the reason I purchased a Knoppix CD was for repair of failed systems, including NT. If I truly can not RW a NTFS partition, Knoppix will be of little use to me.
Tequila: It's not just for breakfast anymore!
Actually, when you delete a file in linux (or any other *nix), you do not actually delete it yet when a process still has a handle to it; it only becomes unopenable for processes. Only when the last process that has a handle to it closes that handle, the disk-space containing the data for that file will be freed.
I always figured it was because when you "delete" a file, it just makes the inode stop pointing at the data, it doesn't actually destroy the data. That way, if a program already had the file open, it would "know" where on the disk the data is, and it would still be able to access it, even though the inode it used to open the file has been freed.
and my roomate can never remember where he saves his documents. A feature that enabled him to search by author or by title in *reasonable* time would seriously help people who find sprawling directory trees intimidating.
---------
Get back to me when my brain starts working.
Unfortunately, HFS, FAT(16/32), BFS, NTFS... none of them have this built in.
I want to see a filesystem with Evil Bit support!
Did you even read my posting?? I didn't say it wasn't a good idea, I just said MOST people wouldn't use it, and I wasn't getting very excited over it. I would probably use it, you would probably use it, and other anal geeks like us who spend hours getting the most out of our systems will probably use it. But Joe Average down the street, the same guy who doesn't know where his downloads end up, won't use it. So, in my humble opinion, it is bloat.
/. effect.
And, to use your example, what if the file system used it's existing file type/program associations, and if you wanted a detailed view, the associated program would sneak into the file and display the information for you? Isn't that what happens now with Word and Excel? What this file system is doing is duplicating the information already in the file and storing it in the file system.
It would be very easy to add an option in the file association tab in Windows so that an executable can be run to extract the summary information from the file. No change to the existing file system format would even need to be done.
Two ways to get at the same data. One pays a penalty for when you want the data (extra I/O to open the file and look at it), the other pays a penalty for every file stored (redundant data storage.) These are common compromises made in every database by the designers, and there is no one correct answer.
My preference would be for the former. It is far more flexible and mirrors my view that the OS (including the file system) should manage resources and not data. If I want and/or need an advanced file browser or file system, let me buy one, but put the hooks into the OS to support alternatives.
<rant>But, that is not the way of the M$. They are far better at creating proprietary methods that lock you into the 'one true way' that the megalomaniac Bill Gates sees the future as. </rant>
Sorry about that rant,
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
There is a huge misunderstanding: SQL is corrupted, not derived, from the relational model. Since SQL deviated from it, the relational model has been developed significantly by Hugh Darwen and Chris J Date among and above others.
So MS is not proposing a relational data storage instead of a file system, but a SQL data storage. Or perhaps not even SQL, as MS SQL Server is notoriously almost as little SQL-compliant as Oracle itself, the king of standards deviations, second only to MySQL.
BTW, if anyone tries to tell you SQL is really relational, or quasi-relational, don't belive the Marketspeak. You can't be quasi-Mathematical, and the relational model is really an implementation of set theory and predicate logic. Tables aren't relations, just like 2+2=5 is not Algebra.
Pragmatically, this prevents SQL from being as flexible, simple and performant as a relational system is. There are some examples, unfortunately mostly historical: Ingres QUEL was found to perform consistently better than SQL systems, and much better than pre-SQL systems that had SQL grafted upon; BS12 was much cleaner, as was QUEL, than SQL; nowadays Alphora Dataphor is extensible in a much cleaner way than current OO or SQL OO systems.
In its defense, it may be that Microsoft uses only the data storage engine of MS SQL Server in WinFS, just as it uses it now for Exchange. Getting rid of SQL looses many interesting, powerful capabilities, but also may unleash performance. It even could be perfected as the engine of a future, nice, relational system, if ever Microsoft wakens up to what Alphora and TransRelational are (trying to) do. But I very much doubt; most of the database field, both academic and corporate, is corrupted by SQL money; there simply isn't enough cultural critical mass for a big company as Microsoft to steer its course from SQL to relational.
Even so, this could be the single most important contribution of Microsoft to the Informatics field, on a par with making the x86 computer a commodity. Even a sub-relational system can be so much better than what is around; this, together with Moore's Law making inherent Wintel inefficiencies irrelevant 80% of the cases, could pose a very big threat to the competitive position of free software. Granted the GNU/Hurd, or perhaps even Eros, could implement something even better than WinFS, truly relational and with orthogonal persistence in the physical layer (Eros) and/or a functional language application layer (GNU/Hurd). But there is no talk of doing so yet, and it would take a long time to bring these systems to where GNU/Linux is now.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
I, in fact, did read your posting. I disagreed with your contention that most people would not use it.
My examples were actually counter to any filetype association cruft that some operating systems default to. This is not what these types of file systems are about. Why limit yourself to three letters and a global registry entry that gives you one of a few static views?
*shrug* My only experience with RDBM-style filesystems is the BeFS. Folks who used BeOS didn't have to be technical wizards (most didn't even bother installing a POSIX shell). Everyone I know used the BeFS in this way, however, for aggregate data where it was useful. For example, most people just manipulated their MP3 files based on the information in the ID3 tags. They rarely viewed the filename ever again; with a few mouse clicks they made the Explorer view of their MP3 directories report bitrate, album name, etc. You could edit your ID3 tags through this views, as well. You could select a number of MP3's based on any number of keys and edit all the ID3 tags from the this same view. No third-party tool necessary. It just made sense, and was dead simple to do.
Once you opened a view on some other "directory", your view changes to the default one, or another view based on other, possible unique, meta-data.
Once you learn how do do this, it becomes a natural way to view the "filesystem".
Sure, only the power users defined their own meta-data to incorporate into specific views. Getting started was dead simply, however. The apps you used then could concentrate on doing what they did best, and cooperated with the OS to provide filesystem views.
I think it's important to note that this file system has a specific use: it's really geared toward user-interaction. This implies two things:
This means that this is not the perfect filesystem for all reasons and all seasons. If all you need is a basic tree-structure, and have no need to hide or filter the generic view that Explorer gives you, then fine. If you are looking for a fileystem that can stream data at a tremendous rate, then another one may be more appropriate. Even a tree-structure may not be good anough, and you have to build an Oracle-like extents system on top of the raw device.
But if you are making a file system that returns searches in a timely manner, "feels" responsive through the clever use of threading, and allows for simple gestures that instantly change the way you present and manipulate file data, then something other than NTFS or ext2fs may be appropriate.
My only point was that Windows Explorer is arguably the most used application in the world. Making this application behave more appropriately based on existing or user-defined true file-type-specific meta-data is good. Being able to instantly contruct unique views based on these meta-data is a good. Certainly accepting near-human search strings based on keys that may be unique to us, and returning those results in a timely manner can only be a good thing.
Monolithic, system-wide and fixed "file attributes" just don't measure up. As long as Microsoft makes it as easy, or easier, to use as the BeFS, people will use it.
Ultimately, all I can say is "have you lived with such a filesystem before?" This is one of those things that you can just make more and more use of, as you gain experience. But you certainly don't need to be a power user to reasonably sort and search your MP3's or photos.
-- clvrmnky
"My God, this must be a truly remarkable corn chip, to be so widely and confidently touted."
Read this, it might help.
http://support.microsoft.com?kbid=265396
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
I really wonder about Microsoft's motivation for this. Are they trying to make Windows "the media OS" that BeOS promised to be? I somehow think it's more than that.
The article is rather thin on details, which has been noted elsewhere. One line at the very end of the article stands out:
What this tells me is that Microsoft is looking for a way to promote lock-in on the desktop, by making multi-boot systems difficult or impossible, and by making cross-OS reading of file systems difficult or impossible. But I think there's even more to the story than that.
Orrin Hatch recently proposed that some kind of measure be placed on computers (he doesn't specify how to accomplish this, just the behavior he'd like to see) to warn the user if they download illegal music the first or second time; the third time that the user downloads an illegal music file, the software that oversees this would essentially trash the user's computer. Now, anyone with two brain cells to rub together can see that this presupposes the ability to distinguish between a legally downloaded MP3 and an illegally downloaded MP3 -- virtually impossible, since MP3 has no built-in DRM. Many bands put MP3 files on their web sites. (Even major acts like the Offspring have made songs available in MP3 format prior to releasing albums.) The only practical way to implement Hatch's proposal is to essentially assume that all MP3 files are illicit, or to assume that all MP3 files downloaded from the network are illicit. This would essentially mandate a closed file format for music, forcing DRM down people's throats and effectively ridding the world of MP3, Ogg Vorbis, and so forth.
How is this relevant? Because if you put a stranglehold on the file system for an OS, you suddenly have the ability to police what goes into that file system, and where it comes from. And maybe, just maybe, this push by Microsoft to add more database-like functionality to their file system is a way to make it easier for a "watchdog" application to perform its cop duties.
The sad part is, if any other developer were to create a file system like this for any other OS, I wouldn't even blink. But because Microsoft comes up with this idea, I automatically start spinning conspiracy theories about their motives, and how they could pervert what could be a great idea and use it against the end users.
Yeah, you can't mount as rw, sucks. I believe you can change some config files and reburn (or something) but I haven't tried it, and even then ntfs writing is a toss of the dice (from what others tell me)
/2k3, etc off the cd and after the first reboot (where the 640x480 gui starts off) shift f10 will dump you into a console with full access to drives, ntfs, fat, et al. You can also start some gui programs while windows is installing, but dlls, etc may not be there because they haven't been installed yet. ;)
A side note, knoppix mounts all disks are read only (IIRC) you have to right click on the drive in the file explorer (I dont have it running right now, I don't know the exact name, but you'll know what I mean when you get it).
That aside, I was impressed with knoppix - booted faster than windows 2003 server and had everything running from a web browser to the usual sort of tools with no config on my part.
However there are some workarounds - you can "install" windows 2000
I'd still say best bet is to either swap the drive or use the preinstall environment.
What a pain. I actually just ftp'd the files off the partition and killed the partition and reinstalled when I had a problem, but if you want to do something a bit more useful, I think you're SOL with knoppix.
1q2w3e4r5t6y7u8i9o0pqawsedrftgthyjukilo;p'azsxdcf
Signatures are supposed to be funny?
she still downloads all her pictures into the default folder, and uses thumbnails to find the ones she wants
:)
"Almost half of all people are below average."
Sounds like you need to teach her the fine art of pr0n management.
Nearly half of all people are below average
screwed up the formatting. The last quote is the sig, not to imply that your girlfriend is in anyway below average.
Nearly half of all people are below average
This is interesting, in fact. With a proper and efficient DB as a backend rather than a traditional FS, you could not only make fast searches, you could reorganize the way your data is presented to you.
/2003/June/1[5-8]/*
Now you are entering data in directories and files, but what if you want to find out what you worked on a particular series of days? You could reorganize your data on the fly so that your directory structure would now be presented in a timeline fashion. E.g. you would be looking in for files in
A nice database combined with version control could potentially find for you the changes to a particular file you made that day. All pretty much instantly.
You could decide to organize all the data any which way that would make sense to you at the time. You would not be stuck with a fixed directory structure anymore.
If this is what MS has in mind this could be a real advance.
First off, I know a lot more about databases than you might think. First I did a stint in a class action lawfirm. Our document management databases would index every document produced in discovery. This would be millions upon millions of rows, for a single litigation, and we would have dozens of those going on. After that, I decided to get into the simpler business of real time energy capture. That's just a few hundred million rows a year...
Transactions are not a panacea and their automatic use needs to be considered and considered carefully and for every application. A sweeping rule of transactions everywhere is madness.
Why?
There are two popular ways of dealing with transactions, multiversion concurrency control, as used by PostGres and Oracle, or, the locking protocols used by Sybase and SQL Server. With MVCC, readers do not block writers, and writers do not block readers, but, sometimes, a rollback in one transaction MUST force a cascading rollback in downstream transactions. The database stalls as do all of your users. On the other side, SQL Server locking, you avoid the potential rollback, but then, writers block readers. So, the database stalls, and users are still screwed! In both cases, in fact, in any concurrency scenario involving transactions, the system is going to tend to wait for the longest running transaction, when their is contention.
Of course I assume a serializable isolation level. If you are going to have that, then, what's the point of having ACID? You can't have ACID without that I for Isolated!
So, where could there be contention? Let's see, in Windows, we have the Registry and its relational replacement, we have the amount of disk space on a volume, we have the contents of a particular file folder. What happens to applications that look for disk free in the middle of a copy of a file folder with 50 files? What happens when you are copying a DVD into a folder? Do you lock the folder query while the DVD is writing?
You guys that admire SQL Server because of a few dozen tables and some little data sets (by little I mean less than 100,000,000 rows), have no idea what you are talking about. Database based file systems with transactions are madness.
This is my sig.
Q: When did you save it?
:-)
A: Yesterday afternoon
find . -name \*.jpg -mmin +1000 -mmin -1500 -print
I think your solution already exists
"I wish Tom would get a clue."
I remember several years ago someone at Tom's site reviewed and benchmarked a number of videcards. The offering from 3dfx did pretty well in the Quake 2/OpenGL benchmarks. The writer stated that the 3dfx did well because "OpenGL was its native API."
First, as anyone with a brain knows, 3dfx's native API was Glide, NOT OpenGL.
Second, I don't think 3dfx ever released a full OpenGL API to go with their cards. If I remember correctly they used a wrapper of some sort to make OpenGL work.
Third, since 3dfx was not using a real implimentation of OpenGL, they were free to cheat to make benchmarks appear much faster.
I was just shocked that Tom had someone so incredibly ignorant performing benchmarks and writing reviews. It then occured to me that maybe, just maybe, Tom himself wasn't too bright. After that fiasco I stopped reading Tom's site.
If someone says he and his monkey have nothing to hide, they almost certainly do.
It's a joke, laugh.
Actually, we've tested quite a bit of the memory disk solutions here. Haven't really been able to get performance to justify the cost though.
Glad to see your Googlin's up to par, tho.
Can I bum a sig? I left mine at the office.
Sorry to take so long to get back, but I was tring to find the info for *both* the kinds of SSD we've tried here. But I could only find the one. Funny, if you Google SSD, it'll be the first thing you'll find, so I'm sure you'll claim that's where I got it. It was the TMS RAM-SAN.
Can't seem to find the info on the other...it was like Armadillo Systems or something like that. Ultimately doesn't matter much. Didn't perform very well.
Can I bum a sig? I left mine at the office.
How long would it take to Google "Solid-State Disk" and link the first company that comes up? Not long, I think. Maybe for you, but for humans...
Your ilk are the reason Bob Dobbs had to point out that the realm of subgenius is not simply the realm just beneath the genius but actually extends *far below* it.
Can I bum a sig? I left mine at the office.
This really has nothing to do with user usability, performance, or anything else. The MPAA and RIAA are tired of having to wait for dir /s to finish (assuming they've hacked your computer) to figure out if you have any pirated music or movies. It's too slow to make it feasible to run scans of large numbers of computers. It's also quite noticeable to the user.
Give them a simple backdoor to access WinFS remotely on any computer (through some bill they push through congress soon after the release of LongHorn), and they can scan entire networks in a reasonable amount of time. Doesn't require them to run indexing software on your computer, since Microsoft has done it for them. Trivial application to write if WinFS is really based on SQL Server, one would imagine.
It's not just DRM boys and girls, it's easily enforceable DRM.
Hey, maybe they can use the "Messenger" Service that runs by default that does pop-up messages
Message from User 'YerFucked':
Click ok to pay us for the 1800 MP3's you've downloaded or click cancel and the police will be dispatched to your location. Thank you for your compliance.