These for fun threads seem to inspire discussions and in some cases change and provide a nice intellectual break so I think its worth having them.

 

There is an old "Why ReiserFS" thread i started last year but I am not continuing it or linking to it for 2 reasons:

 

1. It was opinion based on Hans Resiser being evil

2. Things have moved on development wise since then

 

So heres the proposition:

 

ReisferFS (RFS) is not widely supported. It is not on every Linux distro, its useless in windows, very young in BSD and in OSX (more research needed here).

Fat32 is useless since it has a 4GB limit.

 

NTFS on the other hand whilst very new to many distros is well supported now and you can see a trend for the big distros enabling write support by default already. A complete guess but I think it is fair to say most unRAID users will be windows users since they have the vast market share.

 

So while a few years ago I would be mad for saying this but now... perhaps not so mad now.... why not bin RFS and use NTFS instead. It seems to make sense but what are the technical implications.

 

Have a look at this chart as a graphical representation of what I mean:

 

http://en.wikipedia.org/wiki/Comparison_of_file_systems#OS_support

NTFS-3G is great - I was enabling this by default before bubbaRAID (in fact asked bubba to have it in bubbaRAID), so that I can easily mount my USB disks (all NTFS)

it is a single package without any real prerequisites - a single line install in my go script it was

 

the low-level features of MS NTFS (latest version and not only) easily put it among the most elaborate file systems

 

so if we leave behind us "MSphobia" and "antiGates syndrome", maybe indeed it is an alternative

 

 

Yeah at a glance I have to agree.

 

The thing is M$ wont ever cater for Linux but as we can see here Linux can cater for M$. Leaving behind the ethics of this it seems logical that the only cruelly cross platform solution will be NTFS.

 

 

I've been using the latest Windows 7 beta at home and wanted to point out that the new virtual folder Libraries system only supports ntfs indexed locations. It's extremely prominent in the ui and unavoidable. It replaces the user folders in the explorer sidebar, is located above the computer locations, and it doesn't look like it can be removed. Additionally, windows explorer is by default pinned  to the new taskbar and will always open into the library folder. For many users this is going to be a common way of sorting files in the future, especially with it tying into the "Home Group" feature.

 

I might move some of my files over to my domain server's new wd green drives to take advantage of this. It looks much more featured than using dfs to bring shares together.

 

Edit: On second though, these indexed locations might only be indexed locally anyway.

I want the FS that, based on unRAID's usage, is the most stable (i.e least likely to get corruption) with decent speed.  I don't give a rat's pajamas if it was written and invented by a collaboration of Hitler, Stalin, and Pol Pot, I'm sticking with Reiser.  "Evilness" of the author is an absurd consideration.

 

Besides, on some scales, Gates is more evil than Reiser.

 

 

I struggle with these threads about functionality that is only slightly positive (or even slightly negative) IMO.  I would rate this as extremely low priority.

 

Is it good to discuss them?  Sure.  Just don't want them to create confusion about priority relative to something like new GUI APIs, or the numerous other things on a very long list of enhancement requests.

 

Although I can't totally rule out the source of a software application or other invention, I also can't condemn one based on the evils of the author.  It would have been different if Reiser had kidnapped a bunch of CS majors from MIT, locked them in his basement until they completed the file system, and then murdered them and covered it up.  Reiser coded the file system (with the help of others as well) in a perfectly legitimate way.  The murder of his wife was completely unrelated.  I guess every one has their own personal sense of morality on this topic.  I suggested renaming the FS for his wife.  That would honor her and likely piss him off big time!

 

I have had very good luck from a stability and reliability perspective with RFS.  I had one of the most difficult data recovery experiences ever on this forum, and reiserfsck succeeded in recovering most of my data despite my stupidity.  I once had a corruption issue with Windows / NTFS and did not due nearly as well.  If given the choice, I'd stay with RFS.

 

I want the FS that, based on unRAID's usage, is the most stable (i.e least likely to get corruption) with decent speed.  I don't give a rat's pajamas if it was written and invented by a collaboration of Hitler, Stalin, and Pol Pot, I'm sticking with Reiser.  "Evilness" of the author is an absurd consideration.

 

Besides, on some scales, Gates is more evil than Reiser.

What about Btrfs when it becomes more mature? (in a few years)

 

includes many fault tolerance checks at every level and is 'ZFS' like in many ways

 

http://btrfs.wiki.kernel.org/index.php/Main_Page

 

or is this discussion just centered on  ReiserFS and NTFS?

 

Sorry to hijack,

Bobby

 

I recently needed to set up a networked file system to be in place for a few weeks. It had to run off of a GNU/Linux laptop, use SMB/CIFS, and serve a range of different clients. The infrastructure was gigabit LAN and the two main uses where networked document editing (i.e., archetypical low-latency random read/writes) and quick transfers of ~5GB files both read and write (i.e., archetypical high-bandwidth sequential read/write). I am not claiming that there's anything universal about my findings, but reiserfs was between 30% and several hundred % faster for the sequential case and real-time vs badly sub-realtime for the random case compared to any other filesystem I tried on the server, incl. ntfs-3g, ext-Ns, and a few more.

 

Just saying ...

 

---

 

edit

 

1: my main point is that the choice of file system need to be a looked at in context. incl interoperability w/SMB/CIFS.

 

2: oh, and btw, I fail to see how complete support of reiserfs on other OSs is a factor in any way. Yes, we want the ability to read data off of the surviving drives of a crashed unRAID server, but that would be a one-off and there's enough platforms that allow for it to guarantee that most users can get it done relatively straightforwardly, in case it is ever needed.

 

3: and lastly, NAS, may I suggest that you clearly define to yourself what you want to bring up in any future "for fun" threads before you do it AND go ahead and do a bit due diligence, and report on some amount of testing related to the chosen issue?!

I would rather have a choice of ReiserFS, EXT3 or NTFS. I think this solves many camps.

I don't see the reason to eliminate RFS, yet I do see the need to add others.

I would not be comfortable with using NTFS on unRAID as my main filesystems.

I strongly agree with WeeboTech.  I would prefer this discussion to be between 3 choices, ReiserFS only, NTFS only, or YourChoiceOfFS.  Since the support is already there for multiple file systems, and it is only a mount statement parameter change, and the parity protection is below the level of the file system, it really does not matter what the file system is.  I would prefer that Tom select a default FS (currently ReiserFS), and at format time add a dropdown box listing the default and other file systems supported.  He or we can provide a good table clearly delineating the pros and cons of each file system choice.  (And this feature automatically preserves backward compatibility with all our current Reiser file systems.  Changing to a new mandatory file system choice would be messy.)

 

A *NIX camp is going to prefer *NIX-originated file systems, as WeeboTech indicated.  Windows departments and users would prefer FAT32, NTFS, etc.  Sun shops will have other preferences.  Mac owners would have still different preferences.  Others will have their own reasons for choosing a particular file system, often the one they are most familiar with.

 

Choice is the best answer.  Plus, it enables easier migration of current disks, for new users.  No need to reformat their current drives, or spend time migrating data.  Just install, assign, and build parity.

I strongly agree with WeeboTech.  I would prefer this discussion to be between 3 choices, ReiserFS only, NTFS only, or YourChoiceOfFS.  Since the support is already there for multiple file systems, and it is only a mount statement parameter change, and the parity protection is below the level of the file system, it really does not matter what the file system is.  I would prefer that Tom select a default FS (currently ReiserFS), and at format time add a dropdown box listing the default and other file systems supported.  He or we can provide a good table clearly delineating the pros and cons of each file system choice.  (And this feature automatically preserves backward compatibility with all our current Reiser file systems.  Changing to a new mandatory file system choice would be messy.)

 

A *NIX camp is going to prefer *NIX-originated file systems, as WeeboTech indicated.  Windows departments and users would prefer FAT32, NTFS, etc.  Sun shops will have other preferences.  Mac owners would have still different preferences.  Others will have their own reasons for choosing a particular file system, often the one they are most familiar with.

 

Choice is the best answer.  Plus, it enables easier migration of current disks, for new users.  No need to reformat their current drives, or spend time migrating data.  Just install, assign, and build parity.

It is not as simple as choosing a file-system.  The chosen file system must also be able to have its size changed dynamically (made bigger), otherwise you would never be able to replace a drive with a larger drive.

 

Reiserfs can be dynamically expanded... I'm certain it is not easily done with many of the other file systems mentioned.

 

Personally, witnessing the massive corruption accidentally done by several users by overwriting their data on the reiserfs with zeros... I'll take my chances with it.  I doubt NTFS files would be as easy to recover from that much corruption... 

 

Joe L.

Reiserfs can be dynamically expanded... I'm certain it is not easily done with many of the other file systems mentioned.

 

EXT3 can be expanded online.

 

I doubt NTFS files would be as easy to recover from that much corruption... 

 

I agree here.

 

Again, Another pro of RFS has been that it does not require a preset number of inodes.

Tom expressed in a recent thread how important he felt the safety of customer data was. I think it is quite unlikely he would allow a not-as-safe option.

The chosen file system must also be able to have its size changed dynamically (made bigger), otherwise you would never be able to replace a drive with a larger drive.

 

Reiserfs can be dynamically expanded... I'm certain it is not easily done with many of the other file systems mentioned.

That is a very good point!  It is not completely insurmountable though.  If you were to replace a 500GB FAT32 drive (yeah it is possible) with a terabyte drive, unRAID could rebuild the 500 gigabytes onto the terabyte, and then you could use a third party partitioning tool to expand the file system.  Probably would want to run a special version of the pre_clear tool to clear the final 500GB of the drive, before running a parity check to correct all further parity issues.  (Not that I would ever recommend FAT32 for an unRAID drive!)

 

Personally, witnessing the massive corruption accidentally done by several users by overwriting their data on the reiserfs with zeros... I'll take my chances with it.  I doubt NTFS files would be as easy to recover from that much corruption...

While I agree that the ReiserFS has done a good job, I *think* NTFS may have the better data recovery tools, such as GetDataBack and others, that do a fantastic job of recovering files.

NTFS can dynamicaly expand.

 

I *think* NTFS may have the better data recovery tools, such as GetDataBack and others, that do a fantastic job of recovering files.

 

When I had my first data recovery experience, after running reiserfsck, I thought that I had identified a set of files that were not recovered (later I found them on a differrent disk).  Anyway, in an attempt to recover the data I tried to go back to the NTFS drive that the data used to be on before I copied it to my array.  Problem was, I had already formatted it with reiserfsck and put it into the array.  I decided to remove it and try to run GetDataBack on that drive.  (I had not copied any data onto that drive yet).  I figured that the format was only minimally destructive and that I had a decent chance of getting at the data.

 

It did work - but the results were not as good as what I had gotten with reiserfsck.

I have also had some experience in recovering data from RFS.  I have so say that I was impressed.  I got all of the data that I was looking for back.  There may have been some that was not recovered but it must not have been important enough for me to remember.

Comparing features in isolation here:

 

http://en.wikipedia.org/wiki/Comparison_of_file_systems

 

NTFS seems to be more capable. However more capable is meaningless if you don't need most of the features which leads to the obvious question?

 

Why, today, is RFS better than NTFS in the context of unRAID?

Comparing features in isolation here:

 

http://en.wikipedia.org/wiki/Comparison_of_file_systems

 

NTFS seems to be more capable. However more capable is meaningless if you don't need most of the features which leads to the obvious question?

 

Why, today, is RFS better than NTFS in the context of unRAID?

One consideration is that NTFS-3G runs in user-space through the FUSE file-system interface.  It therefore might be slower than a file-system compiled directly into the kernel.

Valid point.

 

I should really have worded the question better on hind sight:

 

"What features, today, do RFS and NTFS have over each other in the context of unRAID?"

I would like to bump this with a question to Limetech/Tom. I am in need of one NTFS based NAS. Is there any possibility of unRAID meeting my requirement in the next few months?

Polite bump to keep it apparent i am still interested in knowing if this will hit the unRAID line up.

Time flys... thats over a month since my last request so just bumping so it doesn't get lost in the bowls of the forum.

Coming up for 2 months since my last request so another polite bump

Maybe you could make a poll on filesystems and see what people want most.