ZFS filesystem support


jphipps

Recommended Posts

  • 2 weeks later...

hmmm, I run a ZFS mirror cluster on Ubuntu 18.04.  It really is an amazing file system for its features and ease of use.

 

You don't require lots of RAM or ECC RAM, this is a myth.

1. plain ZFS can run on 1GB of RAM on any size array. If you have more RAM it will use more for a cache.  Once you enable Dedupe and L2ARC you needs lots of RAM (rule of thumb is about 1GB of RAM per TB of storage)

2. If you use ZFS for business reasons, like any server you should use ECC RAM.  For home use, storing movies... you don't need ECC RAM. btrfs doesn't require ECC.

 

ZoL is ZFS on Linux, it functions in linux like a native file system.  BSD has switched to this.

https://zfsonlinux.org/

  • Like 1
Link to comment
On 12/15/2016 at 9:09 AM, RobJ said:

* If you don't have ECC RAM, don't even consider file systems like ZFS, you are safer with file systems that don't 'scrub'.  This makes me somewhat concerned about BTRFS scrubs, especially attempts to automate BTRFS scrubbing.  If it only detects issues, that's one thing, and safer.  But if it attempts to automatically correct issues, then ECC RAM should be REQUIRED.  I'm afraid that for me, this may add one more to the list of BTRFS concerns.  I don't want to worry about whether a scrub could be damaging, instead of helping.

 

I suggest others re-read the above concern before handwaveing it away as a non-issue. (Copied it because it was well expressed)

Link to comment
49 minutes ago, BRiT said:

I suggest others re-read the above concern before handwaveing it away as a non-issue. (Copied it because it was well expressed)

From what I gather most believe that's a non issue, while possible, both for zfs and btrfs, you'd need to have hash collision for that, and the chances of that happening are extremely low, see for example here:

http://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/

 

I use and strongly recommend ECC for anyone who cares about data integrity, but you're still better protected against data corruption with zfs or btrfs without ECC that would be on a non checksummed filesystem.

  • Upvote 1
Link to comment

RobJ has an opinion. But ECC is not REQUIRED for ZFS or btrfs, probably strongly suggested for the more data paranoid who may lose sleep over a possible "scrub of death".  But, RAID is not a backup - so I'm not going to be upset if bits flip in my movie stash and all my actual important stuff of course is backed up somewhere else.

 

Link to comment

I don't personally use ZFS, but I'm going to put these links here as some of you guys might be interested.  Greg KH has given a statement on ZFS in the v5 kernels which I suspect (although have no absolute proof) is what Unraid v6.7.0 will be using.

 

https://www.phoronix.com/scan.php?page=news_item&px=ZFS-On-Linux-5.0-Problem

 

https://github.com/zfsonlinux/zfs/issues/8259

Edited by CHBMB
  • Upvote 1
Link to comment

I don't care if it's ZFS or not.  What people like though is the self-repairing file system.  That's the point of this thread.  We can choose where we put it (cache or array), but an option would be great.  I don't know of a self-repairing option for any other file-system, but it seems to me, a company like lime could put pressure on to get it in the roadmap for one of the file systems, even if it is a 5-10 year plan.  Maybe it already is, I haven't actually looked.

 

ECC is just if you're a purist or not.  You get incremental improvements with various additions and implications when you leave bits out.  Up to the end-user to figure out if they're important.  ZFS does have a huge hardware penalty though, it's why I moved to Unraid - FreeNAS / TrueNAS and Proxmox performance was absolutely abysmal.  And all for the idea that your data is somehow randomly falling out of your drives while you sleep.  Absolutely not true.  But peace of mind does have a lot of value doesn't it.

Link to comment
1 hour ago, Marshalleq said:

What people like though is the self-repairing file system.  That's the point of this thread.  We can choose where we put it (cache or array), but an option would be great.  I don't know of a self-repairing option for any other file-system

Self-repair wouldn't work on the array drives, since each disk is an independent filesystem, it would work on the cache pool for redundant configs, and btrfs has the same self-repairing features as zfs, though there's no doubt zfs is more mature and stable.

Link to comment
  • 4 months later...

I do still tend to go over to the FreeNAS forums and salivate over ZFS from time to time.

While poking around I saw this release announcement on Phoronix: ZFS on Linux 0.8 released with Native Encryption, Trim and Device Removal.  That would seem to alleviate all of my remaining concerns, depending on how it's implemented.

 

Now that I'm running Threadripper with so much RAM I expect I won't have performance issues and only advantages.

Link to comment
  • 3 weeks later...
On 5/29/2019 at 1:34 PM, itimpi said:

I believe the limiting factor over including ZFS support has been the licensing terms rather than technical, and as far as I know this has not changed.

Licensing used to be thought of as the limiting factor, but it's really not, as Ubuntu now ships with ZFS.  I thought this was all settled back in 2016:  https://blog.ubuntu.com/2016/02/18/zfs-licensing-and-linux

Link to comment
6 hours ago, Marshalleq said:

I think the Licencing concerns do exist, but as concerns not as facts.  Pretty sure that's been proven illegitimate now, of course that the concern still exists in peoples minds is enough to be a problem.  

Link? Has it been litigated successfully in a similar application?

Link to comment
On 5/29/2019 at 3:27 AM, Marshalleq said:

I do still tend to go over to the FreeNAS forums and salivate over ZFS from time to time.

It sounds to me like you are trying to make Unraid into a FreeNAS clone, which it isn't.

ZFS can be self-repairing because of its RAID design.

Bringing the ZFS file system over to Unraid will not automatically make it self-repairing, because Unraid isn't RAID (i.e. what johnnie said a few posts back).

 

If you want self-repairing, what you need to request is a partial rebuild feature.

Because we can infer where a file is located on a drive, that section (or those sections) of the drive can be reconstructed from the rest of the drives + parity.

That feature + the file integrity plugin should make Unraid self-repairing regardless of file system.

That is probably more complicated to code on Unraid (because it's not RAID) so it will probably be a while before it's implemented.

 

The grass always looks greener on the other side. Having been to both sides, I can tell you the other side certainly looks greener but is full of cow excretion that, if you are not careful, can explode in your face.

Link to comment

LOL, no, I came to unraid for a reason.  And I am so sick of hearing people argue over at FreeNAS about ECC ram.  The Unraid raid driver is built by lime tech and to that end if an option can be dreamed up, I'd agree with going that route.  Ultimately yes, self healing is what I am salivating over, along with the whole shebang of ZFS - like many others.  

 

However, most linux systems include support for all the filesystems and there are pieces of each that can be useful in different scenarios.  So on one hand yes, it would be great to build in some self healing into unraid, but there is all sorts of other stuff ZFS has too.  Who knows maybe there's something in the code that could be brought in.

 

Also I don't think we can say it's not RAID when you think about what RAID stands for.  RAID HAS typically been striped or mirrored data, but nothing says it has to be.  Primarily lime tech just got rid of the striping and figured out that meant you didn't have to have the same size disks.  Netgear also figured this out (very similar) with their X-RAID implementation on ReadyNAS, and I know there's at least one other out there.

Edited by Marshalleq
spelling of Freeness should be FreeNAS lol.
Link to comment
8 hours ago, jonathanm said:

Link? Has it been litigated successfully in a similar application?

What kind of link would prove to you that it was OK?  I'd take a guess at only a court case?  I could do a google and try and find it again, the problem is no-body seems to want to test the theory - legal theory or not.  What changes it from theory?  Only a court case I expect.  And nobody wants to go there, unless we find google adopts it or something I'd say fat chance.

Link to comment
  • 3 weeks later...

A self healing filesystem would be an amazing addition to unRAID. At the end of the day, when you have 80TB of data, then knowing your data is actually safe from bitrot would be huge piece of mind to me.

 

This is the reason that my home pictures, videos and documents are still stored on FreeNAS, and unRAID is used for everything else. I can't risk my most important data (yes i do have a ton of backups too..!).  Why is btrfs even still offered as a filesystem, as most people will say it's simply not reliable enough for production?  

Link to comment
41 minutes ago, sdamaged said:

Why is btrfs even still offered as a filesystem, as most people will say it's simply not reliable enough for production?  

Because those people are wrong, and like mentioned already on this thread, even if Unraid could use ZFS for the array it still couldn't fix any corruption, just find it, same as btrfs, since each array disk is an independent filesystem.

Link to comment

So is there no way at all for unRAID to be able to silently fix file corruption? (even in the future?)

 

Just to add, i think unRAID is an absolutely phenomenal piece of software, but as the amount of storage you have goes up and up, it becomes almost impossible to have backups (50+TB of movies on mine) that i can't back up without another array.  So the (albeit slim) chance of a movie file being corrupted and not playable would be a bit of a problem, as you wouldn't know it was corrupt until you play it

 

Incidentally, what benefits could BTFRS give me over XFS, as i may be building a new server early next year

Edited by sdamaged
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.