Does FreeNAS support GMA?

[Sol42]

Over the past 6 months I've been playing with my newly built FreeNAS system and enjoying the ability to have a low power file server for my home use. I bought an APEX J2900 small pc for my hardware and have it working pretty much flawless (minus a usb flash drive failing, ugh). The J2900 cpu seems to be the sweet spot for low power (idle as low as 13 watts so far!) and transcoding via the Plex plug-in. Most of the time it can serve my 1080p movies just fine, however, it does peg the cpu and performing any other actions (i.e. large file transfers) will make the movie stutter as Plex transcodes to serve the movie to a Roku 3 device.

My question is this: does anyone know if FreeNAS 9.1.2.8 supports Intel GMA hardware? I know it loads Intel drivers for the basic boot screen, but do those drivers support the Intel GMA which provides extra code for transcoding? If not, has anyone experimented loading the latest Intel drivers on the latest FreeNAS to provide GMA support? I believe if this is the culprit then simply upgrading FreeNAS with the latest Intel video drivers would solve my issues with transcoding making my processor bleed.

 

[cyberjock]

No, there is no video support for anything of the sort in FreeNAS. FreeNAS is meant to be a file server, not a transcoding server. Just because you can use FreeNAS to do almost anything you want in a jail doesn't mean it's *good* for those things.

Only some of Intel's GMA supports the transcoding feature. I forget the name of it, but it would be a nightmare to make work on FreeNAS because the OS and jail would have to be kept in-sync and such. Not something that is easily accomplished.

 

[Ericloewe]

No hardware graphics acceleration of any kind is supported in FreeNAS.

 

[Sol42]

Thanks for the quick reply cyberjock. It might be more worthwhile for me to consider converting my NAS to Ubuntu server I guess. From a home user perspective, I really want to love FreeNAS diversity, but appears the project is more geared towards small business file server. FreeBSD is nice in that it will probably be one of the last OS to have a virus written for it which is another selling point, but for my use as many others, we are looking for a home NAS device to do it all; Ubuntu provides this, but it's just a bit more work since it's not been refined for this task yet unless there's a build out there I've missed? Anyhow, Plex does the transcoding piece. I think all it may need is the latest Intel video driver support.

Any suggestions on what other builds may meet the needs of a file server / Plex transcoding server by chance?

 

[cyberjock]

Yes, FreeNAS is geared more towards small business servers. Technically you could say that TrueNAS is geared towards enterprises. FreeNAS, being that 99% of the code is from TrueNAS, is pretty much the same. This is why people hate the whole "ECC RAM or GTFO" and "use server hardware or GTFO" and "RTFM or GTFO". This is enterprise server stuff. Yes, it can be molded to make an amazing home server as 90% of forum users can attest to. But.... the hardware needs can't change much.

No, I have no recommendations for what OS might work. I will say that for FreeNAS you should definitely find better hardware. I think you've made this realization though and you just need to find what "is appropriate" for your needs. A few users here have admitted that Intel's transcoding leaves quality to be desired. I'm using an E3-1230v2 in my server and I set transcoding to prefer quality (which drastically improves quality from what I've witnessed) and I could easily transcode 3 streams of 1080p without maxing out my hardware.

 

[HoneyBadger]

people hate the whole "ECC RAM or GTFO"

Are you kidding me? That's my favorite line. ;)

A few users here have admitted that Intel's transcoding leaves quality to be desired.

Pretty much every hardware encoder is in the same place; fast, but not as high quality as software. If you're transcoding DVD rips you won't ever notice a difference, but if it's 1080p source material and you want to preserve the quality, stick with software.

 

[Sol42]

Aye, I completely understand about using better hardware. However, when I decided to go with the J2900, I was comparing it to other home NAS solutions (i.e. synology, qnap, etc..). I was like, "Why should I pay almost twice as much for a synology that has a half-arse transcoder?!? The cpu and memory pale in comparison to self built NAS solution. The J2900, like it or hate it, has fairly strong horsepower to low power usage (the APEX system in particular idles as low as 13 watts and that's with the hard drives still spinning =). Granted ECC makes a huge difference against data loss, but in my case like many other home NAS users, it's not such a big issue. The likely-hood of data loss is quite minimal for large mkv files and even if there were data loss that ECC could've prevented it will most likely only cause a skip in sound or frame. That being said, if one is very concerned to avoid data loss, ECC does it's job.

Anyhow, at some point I'll build a better NAS in the future. Probably go with something like the C2750 server grade board and ECC ram, but I'm waiting for the prices to come down. At that point my server will be doing a lot more though (i.e. I'll probably load either Virtualbox or VMWare and then serve FreeNAS as just one of many small servers). My point being, I wanted to maximize performance with as little cost and power usage as possible. From my research, I have not found anything that beats the J2900 cpu in price, performance, and low power usage at this time.

 

[cyberjock]

Granted ECC makes a huge difference against data loss, but in my case like many other home NAS users, it's not such a big issue. The likely-hood of data loss is quite minimal for large mkv files and even if there were data loss that ECC could've prevented it will most likely only cause a skip in sound or frame. That being said, if one is very concerned to avoid data loss, ECC does it's job.

You sir, are uninformed. Bad RAM that is causing errors can actually corrupt a pool beyond the ability to mount it. That means a loss of the entire pool. It also has replicated that corruption to backup machines and literally corrupted the backups. We've had a few users not only lose their primary pool but also the backup pool because of a single stick of bad RAM in the primary machine.

The problem is not about corrupting a video file with a few bad bytes. It's total loss of all data on the server.

Read the ECC RAM sticky for a better understanding. ;)

 

[Sol42]

Is the use of non-ECC ram an issue with FreeBSD and ZFS? Or is this a general issue across the board? If it's a general issue across any platform than this is nothing new home user have had to face with their home pc's. If it's a more specific issue with how FreeBSD and ZFS operating systems operate than it is something I am not familiar with and would love more clarification as it would provide better insight into when to choose FreeNAS (i.e. ECC necessity for better reliability) and when to look at other solutions that do not rely as heavily on ECC ram.

Believe me that I understand the necessity of ECC in business. I am a database administrator and the last thing I want to hear at work is data loss (makes my easy day turn into a long night, yuk!). But for home use where the data is typically written once and read maybe once a month or longer, I can not see a use for a typical OS requirement of ECC. My best guess is that ZFS relies very heavily on it for it's health and self healing abilities. This may constitute when to use ZFS (i.e. you have a system that utilizes ECC memory) and when not to use it (i.e. you have a standard pc that has non-ECC ram).

 

[jgreco]

It's that there's no mechanism in ZFS to fix a pool that has had random bits spat into it. Once you start writing random bad bits to the pool, who knows what could happen. Data could be corrupt --> not so terrible. Metadata corruption --> possibly fatal.

 

[Sol42]

Ahh, thank you cyberjock and jgreco. Cyberjock's article on how ZFS uses ECC memory makes much more sense in the cascade effect. I have a question though. I currently use 2 4tb drives in a Raid 0 configuration under ZFS. Should I be concerned of the same cascade issues? I ask because with it configured in a Raid 0 I don't believe I have the same self healing capabilities as say a Raid Z1 configuration. That being said, it appears I would not suffer from the cascade effect, but I'm not sure as ZFS is new to me.

 

[Sol42]

Still unsure on the use of Raid 0 and ZFS, but the following article is a good one that explains Cyberjock's point in a different way:

http://louwrentius.com/please-use-zfs-with-ecc-memory.html

I maybe using my Christmas gift to build me a new NAS unit, sigh. Guess I better start considering what to do with the APEX j2900 now. I purchased it before Cyberjock's article on equipment. Was hoping for this unit to last me a year then give it to my dad for his house and build me a new one based on a Broadwell chipset, but the fact that non-ecc ram actually makes ZFS more susceptible to data loss than NTFS is very worrisome.

 

[cyberjock]

Ahh, thank you cyberjock and jgreco. Cyberjock's article on how ZFS uses ECC memory makes much more sense in the cascade effect. I have a question though. I currently use 2 4tb drives in a Raid 0 configuration under ZFS. Should I be concerned of the same cascade issues? I ask because with it configured in a Raid 0 I don't believe I have the same self healing capabilities as say a Raid Z1 configuration. That being said, it appears I would not suffer from the cascade effect, but I'm not sure as ZFS is new to me.

You are correct. Your RAID0 is not protected from corruption. In the event that you have corruption on the disks(not in RAM) the pool will be able to identify the corruption, but it will be unable to correct it. To correct it you must have redundancy of some kind.

As a general rule, RAID0 is bad because you will eventually have a disk fail or start to have corruption. Once that happens it's possible the entire pool will be unmountable and you'll go from a pool that is healthy and available to inaccessible and the data is gone forever.

 

[Sol42]

So if I understand correctly from cyberjock's last reply, zfs in a raid0 configuration with non-ecc ram has no more risk than say ntfs in the same configuration. Would that be a correct statement?

 

[Ericloewe]

So if I understand correctly from cyberjock's last reply, zfs in a raid0 configuration with non-ecc ram has no more risk than say ntfs in the same configuration. Would that be a correct statement?

In a way. NTFS will continue on its merry way with invalid data, but ZFS will start complaining.

It's not a case of being safer, it's a case of being less insistent on data integrity.

 

[cyberjock]

So if I understand correctly from cyberjock's last reply, zfs in a raid0 configuration with non-ecc ram has no more risk than say ntfs in the same configuration. Would that be a correct statement?

I'm sorry, but there's no way to compare like that. We're talking about statistical likelihood. You also have to think about other factors such as the 'recoverable potential". ZFS has none if things go wrong. You're just SOL. There's no recovery tools for ZFS at all. On the other hand, if the file system gets kind of fubared there are lots of recovery tools for NTFS and there's a good chance you'll get most of your data back.

We're talking about risks that nobody here would be willing to do, so your choice to justify to yourself that your choices are good is totally between you and your data. You start talking file servers and you really should be using ECC RAM anyway. Even on NTFS, if you have bad RAM you'll see the OS an file system get corrupted. I've seen it firsthand more than once. Of course, people will do what they always do and blame Microsoft for the data loss and go on with life. But that's not the cause for the problem. The problem is bad RAM is like giving your server Alzheimer's. It behaves erratically, it isn't trustworthy and things can (and do) go wrong.

 

[jgreco]

In a way. NTFS will continue on its merry way with invalid data, but ZFS will start complaining.

It's not a case of being safer, it's a case of being less insistent on data integrity.

I don't believe that NTFS checksums its data, so "less insistent on" is more correctly written as "oblivious to."

 

[kling]

Is the use of non-ECC ram an issue with FreeBSD and ZFS? Or is this a general issue across the board? If it's a general issue across any platform than this is nothing new home user have had to face with their home pc's. If it's a more specific issue with how FreeBSD and ZFS operating systems operate than it is something I am not familiar with and would love more clarification as it would provide better insight into when to choose FreeNAS (i.e. ECC necessity for better reliability) and when to look at other solutions that do not rely as heavily on ECC ram.

I will now tell you a secret... I´m currently using a smaller, non-ECC, FreeBSD computer for my nightly/daily rsync backup. Shhhhh. You have not heard this... And it have been working flawless for 4 years. And yes it is using ZFS(mirror) and ohh my god it has only 4 GB RAM.

Follow cyberjock and EricLoewe advise. I have done that and my bigger server is more of an enterprise server.

For your J2900 CPU it is perfect for a small pfsense setup. Populate the PC with an Intel Dual/Quad Nic and you are going to have a nice stable router. Read more on pfsense forums.

 

[Ericloewe]

I don't believe that NTFS checksums its data, so "less insistent on" is more correctly written as "oblivious to."

Certainly not all its data and not by default, so yeah, NTFS doesn't give a damn - because it has no way of knowing.

 

[jgreco]

Yeah, we pretty much know that 4GB and non-ECC works fine right up to the point where it doesn't, at which time ... toast.

There are some aspects to all of that which basically boil down to "you're a big boy, right?"