J
jpaetzel
Guest
I've been working on FreeNAS for years, but my home fileserver has always been a straight FreeBSD box. Thanks to iXsystems providing me with a dedicated FreeNAS box I've cut everything over to FreeNAS 9.1.1-RELEASE.
I'd like to document some of my experiences.
1) It's vitally important that you get working email from your FreeNAS box. The alert system is great if you happen to be looking at the GUI, but you're going to want it to be able to send you email alerts. Be sure to give smart an email address to send to as well.
2) Set up smart test for your disks. I recommend a weekly short test and a monthly long test. These have no performance impact, as the disks prioritize normal IO over the tests. If a disk fails a test, even if the overall smart status is "Passed", strongly think about replacing it.
3) If you are using ZFS, create a dataset called syslog. This is a magical name, and the system will move syslog there, giving you persistent logs. (Requires a reboot)
4) The plugins are easy, and plex rocks. A caveat is, if you are on DHCP the jails will oftentimes grab a range of IPs to use that are in the DHCP range. This can lead to later IP conflicts on your network. To address this change the jail ip range to something outside the DHCP range.
5) Use datasets for your samba shares, and set up snapshot tasks for them. FreeNAS will auotmagically configure samba to pass through the ZFS snapshots to samba. Windows will then activate the previous versions feature, available if you right click properties for any file or directory.
6) Give ZFS enough redundancy to not only find, but fix filesystem errors. Use RAIDZ or mirroring. For really important data drop to the command line and zfs set copies=2 <pool>/<dataset> Give ZFS as many chances as possible to not only detect errors but fix them. It's good at keeping your data safe if you let it. Be religious about running scrubs. Scrubs will help you detect hardware going south, and if run early enough can fix problems.
7) If you really really don't care about your data, for instance doing builds or rendering scratch space, do zfs checksum=off <pool>/<dataset>. If you are using NFS, you can also do zfs set sync=disabled <pool>/<dataset>. These sacrifice data integrity for speed, so please be mindful of where you use them. (In the first case zpool scrub is helpless to even detect errors, let alone fix them, in the second case an NFS client or server crash can cause corrupted data.)
I'd like to document some of my experiences.
1) It's vitally important that you get working email from your FreeNAS box. The alert system is great if you happen to be looking at the GUI, but you're going to want it to be able to send you email alerts. Be sure to give smart an email address to send to as well.
2) Set up smart test for your disks. I recommend a weekly short test and a monthly long test. These have no performance impact, as the disks prioritize normal IO over the tests. If a disk fails a test, even if the overall smart status is "Passed", strongly think about replacing it.
3) If you are using ZFS, create a dataset called syslog. This is a magical name, and the system will move syslog there, giving you persistent logs. (Requires a reboot)
4) The plugins are easy, and plex rocks. A caveat is, if you are on DHCP the jails will oftentimes grab a range of IPs to use that are in the DHCP range. This can lead to later IP conflicts on your network. To address this change the jail ip range to something outside the DHCP range.
5) Use datasets for your samba shares, and set up snapshot tasks for them. FreeNAS will auotmagically configure samba to pass through the ZFS snapshots to samba. Windows will then activate the previous versions feature, available if you right click properties for any file or directory.
6) Give ZFS enough redundancy to not only find, but fix filesystem errors. Use RAIDZ or mirroring. For really important data drop to the command line and zfs set copies=2 <pool>/<dataset> Give ZFS as many chances as possible to not only detect errors but fix them. It's good at keeping your data safe if you let it. Be religious about running scrubs. Scrubs will help you detect hardware going south, and if run early enough can fix problems.
7) If you really really don't care about your data, for instance doing builds or rendering scratch space, do zfs checksum=off <pool>/<dataset>. If you are using NFS, you can also do zfs set sync=disabled <pool>/<dataset>. These sacrifice data integrity for speed, so please be mindful of where you use them. (In the first case zpool scrub is helpless to even detect errors, let alone fix them, in the second case an NFS client or server crash can cause corrupted data.)