3ware 9750se smartd.conf empty

[umhelp]

I just installed FreeNAS on a cheap server I bought for my home. It has a SuperMicro X8DTN+ motherboard and a 12 drive backplane connected to a 3ware 9750. When I first booted I was getting an Amber light in the FreeNAS GUI telling me that Smartd was not started. After further investigation it seems that my /usr/local/etc/smartd.conf file was empty. I did some greps and finds to see that that file gets created by the /etc/ix.rc.d/ix-smartd script. While skimming through the script I found a section for 3ware:

# 3ware controller
${disk}:twa*)
port=`/usr/local/sbin/tw_cli /c${CONTROLLER_ID}/u${CHANNEL_NO} show | egrep "^u" | sed -E 's/.*p([0-9]+).*/\1/'`
propdev="/dev/${DRIVER}${CONTROLLER_ID} -d 3ware,${port}"
break
;;
​

Unfortunately, my controller maps to /dev/tws* instead of /dev/twa* so the script is not finding my controller. I added the following case and restarted the service which seems to work:

# 3ware 9750se
${disk}:tws*)
port=`/usr/local/sbin/tw_cli /c${CONTROLLER_ID}/u${CHANNEL_NO} show | egrep "^u" | sed -E 's/.*p([0-9]+).*/\1/'`
propdev="/dev/${DRIVER}${CONTROLLER_ID} -d 3ware,${port}"
break
;;


I copied my new mods to /conf/base/etc/ix.rc.d/ix-smartd and restarted. Smartd now starts properly and my smart.conf is properly configured.

My only issue now is my drive serial numbers are not populating in the View Disks menu.

A) Is the above fix to the ix-smartd script valid.
B) What other files do I need to modify to get the Serial Numbers and other data that I'm likely missing.

PS: I am using FreeNAS-9.3-STABLE-201506292332

 

[Darren Myers]

See this thread https://forums.freenas.org/index.ph...card-join-the-crowd.11901/page-13#post-188262 as that card isnt recommended

 

[umhelp]

Just because it isn't recommended doesn't mean. That it should or can't work. I'm stuck with that card at least for the time being. Smartctl returns all the proper information it is just a matter of getting the proper args to the command. I just need a point in the right direction and I can hack away. I'm not familiar with the source and how the freenas frontend/backend/middleware work so I don't want to change something for the worse.

 

[Darren Myers]

well, there are stuff that does work, but doesnt work right...or how FreeNAS wants to use it, i'm going to link this thread here that also contains an explaination https://forums.freenas.org/index.ph...igh-end-home-built-platform.12591/#post-58953 :

That's a better choice. What you'd have discovered is some misery. No one here is likely to accuse me of terse answers, but sometimes they are insufficiently long. I should have expanded that last reply a bit to help you understand.

ZFS wants to be your RAID controller.

In a hardware RAID controller, you have maybe something like a PowerPC 800MHz CPU, some number of SAS/SATA ports, and - if you're lucky enough to have a high end controller, not an entry level controller - some cache and maybe even write cache with a BBU. Fairly generous ones in this day and age seem to be about 1GB of cache.

ZFS can do all the same computational work for RAID on the host CPU. Yes, that slows the host CPU, but on a Xeon, it's not that large an issue, and in the end Sun figured out that CPU cores were cheap while specialized silicon was very expensive.

With specialized silicon, that means you need a more complicated device driver and mangement subsystem. ZFS needs that too, except that ZFS *is* that subsystem, so it is all cleanly integrated with the filesystem and storage layers.

ZFS wants to cache for you. For reads, it will happily cache on both a per-disk ("vdev") AND more abstracted ("ARC") basis. When you're reading things off the pool with ZFS, just as with a RAID controller, it will let those bits sit in cache until pressure flushes them out. The difference is that ZFS's cache is the system's RAM. So if you have a 64GB RAM system, a huge portion of that is being used for ARC. Also, a fixed amount of it is being used for vdev cache (which is similar to the "read-ahead" function on a RAID controller).

So point one is this: if you use a RAID card as a disk controller for ZFS, you're going to see almost no benefit from any read cache on the card, even if you enable "read-ahead" on the RAID controller, because ZFS is doing that already, and with substantially larger resources available to it (which you can even tune as needed).

But ZFS also wants to cache writes for you. A lot of data such as file writes may not be that important and can be written async to the pool. ZFS bunches these up into a transaction group and flushes them to disk when a txg fills, or every few seconds, all configurable. The thing is, a transaction group could potentially be huge - it is based on the size of your RAM. So if you are doing a bunch of modifications within files, this is actually being handled in RAM at very high speed, then flushed out to disk. And when it does, it's probably going to blat out a large amount of data. Much larger than your write thru cache is capable of caching.

So point two is this: if you have a RAID card with write cache, a lot of ZFS writes are going to be absolutely devastating to it because they're likely to be larger than the cache on the RAID.

However, there is some opportunity for write cache to be of use for ZFS sync writes. Typically handled with a specific type of SSD in the ZFS model, it appears that a RAID controller with BBU write cache could be very competitive - quite possibly faster and more durable - than an SSD. Only for the ZIL/SLOG. But this is pretty much the exception rather than the rule.

I wouldnt suggest hacking around to make it work, youd be better off selling it and getting a recommended card....well many well respected members here in the community will also advise again hacking around FreeNAS and in the event you want assistance in doing so your posts will fall on deaf ears, and depending if someone feels to humor you on what youre doing, you may not like the answers.

I'm not familiar with the source and how the freenas frontend/backend/middleware work so I don't want to change something for the worse.

If youre not familar with it i wouldnt recommend touching it, whats proven and known working is whats known working, that card doesnt come up in many posts, and the posts it does show up in it is advised against. Getting a different card (HBA) wont change your setup for the worse, it will simply allow FreeNAS to do what it is designed to do. Newegg's link says it will do single disk, but single disk isnt the same as JBOD which is what FreeNAS needs.

 

[cyberjock]

Just because it isn't recommended doesn't mean. That it should or can't work. I'm stuck with that card at least for the time being. Smartctl returns all the proper information it is just a matter of getting the proper args to the command. I just need a point in the right direction and I can hack away. I'm not familiar with the source and how the freenas frontend/backend/middleware work so I don't want to change something for the worse.

The reason why it's listed as not recommended is because SMART doesn't work right on 3ware with FreeNAS. We do not endorse or condone the art of hacking the OS, especially in a public setting. I personally bought a 9650SE and traded it 2 weeks later. Not because I couldn't hack it to make it work (I most certainly could have). The problem is that it doesn't work properly with the rest of the middleware without heavy editing and other things that risk breaking other things.

To be short and blunt, if you don't know how to edit all of the dependencies already without asking, you don't have the required experience to do the job 100% anyway.

There are other lower-level issues involved with the 96xx and 97xx, but I can't talk about it. Sorry.