Slashdot Mirror
Microsoft Announces ReFS, a New Filesystem For Windows 8
bonch writes "Microsoft has shared details about its new filesystem called ReFS, which stands for Resilient File System. Codenamed 'Protogon,' ReFS will first appear as the storage system for Windows Server and later be offered to Windows clients. Microsoft plans to deprecate lesser-used NTFS features while maintaining 'a high degree of compatibility' for most uses. NTFS has been criticized in the past for its inelegant architecture."
After my initial tests, I must say that ReFS is incredible advangement. ReFS supports named streams, object IDs, short names, compression, file level encryption (EFS), user data transactions, sparse, hard-links, extended attributes and quotas. It is basically all the best filesystems compiled into one.
Not only is this good for Windows system, but overall network architecture.
This is a bad idea.
Now we can count on some guy named 'Hans Resilient" to be tried and found guilty of murder.
Free unix account: freeshell.org
I can't say that I've ever used any of the NTFS features they're planning to drop.
I do wish Windows had a sane soft-link system like *nix does; I've yet to run into an application that automatically dereferences a .lnk when opening it. You have to futz around with opening the link manually, reading it's redirect, and then opening THAT instead. Very crude and ugly.
But more to the point, I didn't see much about what might be NEW with this file system, only what's OLD and being discarded.
Mind you, some basic feature cleanup never hurt anyone. But if that's the case, why not NTFS2 instead of a marketing buzzword?
I do not fail; I succeed at finding out what does not work.
Today, NTFS is the most widely used, advanced, and feature rich file system in broad use.
If this is true...it's a very sad world we live in...
There's already no Linux driver for it... so does that mean you're going to switch? And if someone makes a Linux driver will you switch back to not using it?
If you're married to "Hans Resilient", you'll want to start running now.
Sounds like they're due for a refresh so they can get some new patents on their filesystem to make sure all the device makers need to continue to pay them money.
That might be motivation for creating ReFS. Third party NTFS drivers finally became mature enough to safely read/write the file system... so lets create a new undocumented filesystem and make data exchange between other OSes a PITA again. It also means WinFS is completely dead and never coming back.
I'm not a filesystem guru. I stick to programming in the application space mostly. But I have noticed a large time discrepency compiling a large project using EXT4 vs NTFS. EXT4 being multiple times faster then doing the same compile on an NTFS. My question now is, will ReFS bring those times up to similar values?
PS. Also looking at the dropped support for short names, i think quite a few server batch files will be broken.
"Microsoft plans to deprecate lesser-used features" --- such as the reasonable level of compatibility that has started to show up in non-Microsoft implementations of NTFS over the last couple of years. We may be assured that ReFS is a patent minefield.
Tired of FB/Google censorship? Visit UNCENSORED!
.
I have to wonder how much of the pre-release ReFS hype will prove to be true in the coming years.
A few weeks ago, I pulled "Hail Mary" with regards to saving an SBS 2003 server. For whatever reason, the server would not boot after a power failure. The RAID cache was not dirty on the card, and the RAID volume passed a manual parity consistency check. Unfortunately, the server would still not boot into the OS. It kept throwing a BSOD or hung at finding the hal.dll file. Attempting to access the recovery console or other F8 invoked options failed. Any Server 2003 disk would throw a BSOD the moment it attempted to mount the boot "C" volume. It wasn't the RAID drivers, but actual NTFS corruption causing the kernel panic. Serious shit. However, a Server 2008 R2 disk did save my ass. I was able to mount the volume through a command recovery console. A chkdsk revealed massive amounts of corruption. Server is fucked right? NO! A "chkdsk /R" command was able to find and repair all errors. No data loss what-so-ever.
Basically, the server must have been busy with installing updates or something when the power died. An old UPS battery will do that. But this goes to show how remarkably resilient the NTFS system is. Absolute respect!
Life is not for the lazy.
... to not one.
The real world disagrees with your statement: we have TFS projects with long directory and file names, such that we cannot map the entire TFS source in a single folder. Even naming it e.g. "c:\x" (or "d:\", putting it on a separate drive), the paths and files still exceed MAX_PATH (which is 260, not 255).
So, this feature will be useful to our shop.
It's also useful for "rolling backups"; I administer family machines, and one has been upgraded from a desktop, to a laptop, to another laptop. The first upgrade, I copied all the files to "c:\e" (old machine was an eMachine). That laptop died, we used a restoration company that started with a "G" to get the data back (now we backup via WHS), and I saved that in "c:\g" (so there's a "c:\g\e" with the desktop's files). The third machine (second laptop) has "c:\h" (which also contains "c:\h\g\e"). Other times I've saved backups with more descriptive names, like "Backup of the Dell Inspiron 5150, 2011-11-11", and sometimes those backups fit inside each other like expressed above.
So, I have examples from both home and work where having longer-than-MAX_PATH file/path names would be useful.
I feel fantastic, and I'm still alive.
How much data did you have on a single large zdev that it required that amount of time? I tend to group mine into groups of 8 disks with raidz2. When I have to rebuild, it does so at the write speed of the new disk (100+MB/sec). If you have a relatively small array and it still takes 45 days to rebuild then you have a hardware issue, or you are using an siig card, which has horrible performance under all the unix/linux variants I have used.
I use zfs on linux at home with an 8 disk raidz2 array for network storage. On a core 2 duo / 2.5ghz using an lsi 1068 based card, I achieve a rebuild speed of 80+MB per second, a scrub speed of 150+MB/sec. At work, I use it to store spatial data / 3d video using zfs on linux. Multiple 8 disk raidz2 devices connected via lsi 9200 card. I achieve a rebuild speed of 80+MB per second, a scrub speed of 250+MB/sec.
If you use junk cards, you get junk performance.