ZFS:Main

ZFS is included in FreeBSD and several other operating systems and comes bundled with the supporting tools. This supplies a very large number of tools and toys for managing your disks and filesystems.

Included ZFS features:
(These features are baked into ZFS, but that does not mean that all of them are a good idea)

Disk Management - disk(s) assigned to ZFS pools do not need to be micromanaged by other tools
ZFS Managed Software Raid - stripe, mirror, or raidz (or, some combination/variation like Striped-Raidz)
Datasets - child filesystems of the pool, no special partitioning required.
Volumes - virtual disks created from raw storage of the pool, no special partitioning required
Transparent Compression - lz4, lzjb, gzip, gzip-[1-9], zle, or none (Pool version 5000, also called "feature flags" added lz4 to this list)
Dedup - Identical blocks are not stored more than once. VERY HIGH MEMORY COST, AND SPEED IS SACRIFICED, PLUS OTHER HAZARDS. NOT RECOMMENDED, but available.
Snapshots - read-only reference to a dataset or volume as of a specific moment in time
Cloning - replica of a dataset/volume created from a snapshot

ZFS Structural Elements:
vdev - structural elements that make up a pool
Pool - the nexus that presents the underlying storage devices
Dataset - a child filesystem of the pool
Volume - a child of the pool that acts as a virtual block device
Snapshot - a point-in-time reference to the state of a dataset or volume
Clone - a new dataset or volume that starts with a snapshot as its template

Further Reading/Links

Link		Source		Notes
FreeBSD zpool man page		freebsd.org		for creation, manipulation, and destruction of pools
FreeBSD zfs man page		freebsd.org		for creation, manipulation, and destruction of datasets, snapshots, clones, and volumes
FreeBSD zdb man page		freebsd.org		ZFS debugger - useful for checking pool and vdev parameters
FreeBSD ZFS wiki		freebsd.org
ZFS Tuning Guide		wiki.freebsd.org
ZFS Best Practices Guide		solarisinternals.com		Some is Solaris specific, but most is equally valid
ZFS snapshot, clone, volume		googlux.com
Dedup details		blogs.oracle.com		In case you're curious about dedup. Dedup is NOT recommended
Migrating ZFS pools		docs.huihoo.com
zfs copies=x		blogs.oracle.com
Moving ZFS pools		barbz.com.au
ZFS Compression - A Win-Win		blogs.oracle.com
Becoming a ZFS Ninja		blogs.oracle.com		(video)
ZFS Cheatsheet		lildude.co.uk
ZFS: Read Me 1st		nex7.blogspot.com
Fixing the 4k problem		blog.monsted.dk

Originally from zfs/main.txt · Last modified: 2014/09/04 06:49 by killermist  This is a copy, just in case.

"Popular" protocols comparison

Very unofficial protocols comparison

These conclusions are ENTIRELY the responsibility of me. You can blame me for anything you disagree with.

Protocol		Lan/Internet		Scope		Complexity
HTTP		both pretty safe		fairly universal		fairly simple, great for downloading of static files
FTP		fair for both		diminishing, thankfully		Not “hard” to use, but also not the easiest to set up. Also not particularly secure
TFTP		lan, mostly		obscure		Used mostly for booting diskless workstations. No idea about setup difficulty.
SMB		lan. NOT internet-safe.		Mostly windows, some media players		Sometimes quirky to configure initially, pretty easy to use.
NFS		lan. not recommended for internet		Mostly unix-like		Setup generally fairly simple, both for server and clients. No encryption included
AFP		mostly lan, I think		Mostly Apple		Not sure, never personally tried. Some users have easy success, others, not.
SSH		either. not recommended to expose root account to internet		Mostly unix-like, and windows via programs		Very simple to administer.
RSYNC (over SSH)		Same as SSH		Mostly unix-like console		Very simple to use, no rsync service to configure, only SSH required
RSYNC (module/service)		either, if secured properly		Mostly unix-like, often GUI		A little hard to configure initially.
Torrent		almost entirely internet		fairly universal		Popular for distributing large files to/from large communities. Can be a little challenging to configure initially. Should be fairly easy to use after.
Unison		Not sure, maybe reliant on SSH		mostly unix-like ??		Not sure, kinda tried and failed to use it once. Sorry
iSCSI		lan. internet probably too slow and not safe		growing		Used most often with VMs or diskless workstations. Sometimes hard to configure, but very powerful.
UPnP		Only heard of on lan, thankfully		growing, unfortunately		UPnP, as a concept needs to die in a fire. And manufacturers shouldn't have been so lazy as to add UPnP to their devices and then lie to consumers and say the device is “media ready”.
DAAP/iTunes		probably mostly lan, not sure		apple/windows mostly, I guess		Configuration looks maybe complicated. Not sure, haven't tried.

Originally from documentation/setup_and_user_guide/very_unofficial_protocol_comparison.txt · Last modified: 2014/02/19 14:29 (external edit)  This copy is here as a backup.

What a NAS should and should not be

This is one of my rants. Some people may disagree with the “bias” of the following. But I, killermist, WILL NOT assist anyone in doing any of the things listed below. Those things are things that a NAS should not be doing.

A NAS should be many things.

First and foremost, a NAS should be a storage system. In order to be a storage system that is useful (what good is storage if you can't get it to store or retrieve things?), it must include file transfer protocols (some of which are referred to as “streaming”, which is a fairly useless designation, in general). This carves out a giant area that a NAS should do. And it should do those things expertly. ZFS creates a very stable storage platform. UFS can be used if you don't care about the integrity of your data, because it doesn't checksum the data, and it will gleefully return corrupted data to you as if it were 100% healthy. The list of valid and useful protocols for reading, writing, and moving files is quite comprehensive. NFS, SSH/SSHFS/rsync, SMB and HTTP make up a very comprehensive and useful block. Bittorrent, as a long-running, random availability protocol adds some very useful flexibility. AFP and novelty protocols like UPnP or iTunes add some misguided but commonly requested stuff and can round out a protocol set pretty completely.
That being said, there are a good number of things that a NAS should not be. Further, the list of things that a NAS should not be are things that really should never be supported. Asking me how to install ANYTHING will likely red-flag you as someone that is probably beyond help.

Hint: A good NAS, capable of using the power of ZFS is probably based on FreeBSD. It is probably NOT based on Linux (mostly because of license reasons). So, while some knowledge gained from learning to administrate a Linux system may apply, A LOT of how Linux works is completely invalid in dealing with a good NAS distribution. For almost every action in a good NAS system, using the CLI (SSH or connected screen/keyboard) is entirely the wrong method since the WebGUI should be where configuration changes are made. Furthermore, the "sudo" command, that many Linux people have grown accustomed to, does not exist. Asking why it isn't “installed by default” or why it “can't be installed” is likely to be met with groans and facepalms. 

Among the things that a NAS should not be are the following items, which make up a non-complete list.

• Usenet downloader - You should be using some other machine to do that. Using the NAS to store the results, through a mounted share, great. But A NAS should not be that. There are many low-cost, low-power solutions for little headless tasks like that. Pushing the NAS to do them is not wise.
• Database server - Again, using another machine to run a database server, and storing the database data on a NAS, great. But a NAS is not intended to handle database serving duties. Again, many low-cost, low-power solutions exist to do this. Hey, it could even be your Usenet downloader box…
• Media transcoder - This includes the (misguidedly included) transcoding in UPnP. The processing power and ram of the NAS are supposed to be used for moving hard drive data to/from the network, and not mangling that data along the way for “compatibility” with woefully incompetent devices. If your device isn't compatible with your media, then either fix the media or fix the device. Transcode the data yourself, or get a media player that works right. And no, game consoles are not a good choice for playing media. Anyone that tells you otherwise is lying to you, possibly because they've been lied to them-self. Programs like Handbrake make it really easy to transcode your videos into a format that competent devices can play. But it will require another machine to chug away at the video for a while, depending on the quality level you're demanding of it. But demanding transcoding from the NAS will only slow things down and make responsiveness worse.
• Virtual Machine Host - Again, the processing power and ram of the NAS are supposed to be used for moving hard drive data to/from the network. Wasting your CPU time or memory on running virtual machines means that those resources are unavailable to other more important tasks, like making sure the data can get to/from the network in an expedient manner. In particular, if your NAS only had the recommended quantity of ram for the size of your ZFS storage to begin with, it is especially unwise to take any of that ram away. Even the setup, configuration, and especially troubleshooting of jails (which are virtual-machine-like), which tend to be an included technology in FreeBSD, are a bad idea. So, when someone sets up a jail, and then breaks anything, they will find no help from me for fixing their mess.

Common nonsense

To address some grumbling I can already hear forming, here's some retorts to what I know people are probably about to ask:

• “But, bittorrent is included in a number of NAS solutions. Why not have [X]?” – Transmission is an annoying double-edged sword. It uses the bittorrent protocol to help move files to and from the NAS. Just like NFS, SSH, or SMB. This makes it a valid and useful protocol. In particular, this is a question most commonly asked by people wanting Usenet downloading or other file-leeching mechanisms. Neither of these is a server-like function, which is pretty essential to how a NAS works. If I had to choose to either add these other non-server functions or to remove bittorrent, I'd willingly jettison bittorrent as a supported protocol for the sake of the rest of the system.
• “But my media player uses UPnP and needs things to be transcoded on the fly.” – Get a media player that isn't crap. TV and game console manufacturers have gotten really lazy and bought into the lie and simplicity (stupidity) of adding a broken protocol that then permits them to slap on the “media ready” sticker to their product. Consider these: 
  Scenario 1, I transcode my media once on a client machine and store it on the NAS to play to my media player using SMB. I spend the CPU time ONCE ONLY. I'm also doing it on a machine that isn't the NAS, so the network isn't suffering from a slowed NAS while the encode occurs. And I'm left with a nice pretty file as the result of that spent CPU time. Two, three, 10, even 100 devices can all play video via SMB with no problem provided there's enough network bandwidth and raw disk speed. 
  Scenario 2, some fool uses UPnP to stream files to some broken thing, like PS3/4 or Xbox-something. Every friggin' time a file gets played, CPU time must be wasted (more energy usage and cost, duh) to reencode it on the fly. Worse, all this wasted CPU time leaves no result for having been wasted. Further, because the NAS (and not some other machine) is wasting CPU time encoding, every other task on the NAS has less CPU time available. Simultaneous encodes because of simultaneous viewers can seriously waste CPU time and kneecap NAS performance.

Originally from what_nas4free_is_and_is_not.txt · Last modified: 2015/06/01 09:15 by killermist

FreeNAS Grievances

This listing is maintained by killermist, and not an official rant, so complain to killermist if you think any of this is in error. (hint: it isn't)

Plugins

Such a bad idea from the word “Go.”
Let's start with a definition. NAS means “Network Attached Storage”. It doesn't mean ANYTHING else. It definitely does NOT mean “database server”, or “media transcoder”, or “usenet scheduler and downloader”.
In opening up the Pandora's Box that is “plugins”, it encourages users to do with their NAS things that a NAS isn't intended to do.
On top of this, there's the problem of feature bloat and feature lag.
With users doing so many unrelated and inappropriate things with their NAS, extra care must be taken to not break any of the user's precious plugins. So, every time some feature or program that is in the core system gets upgraded, all kinds of stupid extra tests have to be performed to make sure they don't break user plugins. There's your feature lag.
If in order to keep user plugins running, 2 versions of some thing must coexist, that means you're wasting space keeping the 2 versions of the thing around. There's your feature bloat.

ZFS Partitioning

Where to start with this abomination…. ZFS is memory hungry. Duh. If you don't have enough of it, you're going to have problems. Remember this, I'll come back to it.
Anyone that knows anything about ZFS knows that you want to feed it raw disks to manage. Why?

1. If ZFS controls the whole drive, it can intelligently choose what, if anything, to do with the drive's in-built cache.
2. ZFS should, in anything resembling optimal conditions, be the only user of a drive, and not be challenged for I/O time.

Remember how I said that ZFS is memory hungry? Well, what genius idea did the FreeNAS people have to deal with people without enough memory? SWAP! That's right, swap. And how do they plan to pay for this swap? Well, by taking every disk that will be part of a ZFS pool and partitioning a few percent of it to be swap. Then they take and make the remaining space a partition that will be used for the pool.
So, they wasted space. They put something on ZFS disks that will likely challenge ZFS for I/O time. AND they've prohibited ZFS from exercising its own control over the drive cache.
But, that's one of the things I'd expect from a system designed by committee.

ZFS Documentation

As is only possible in a system designed by committee, the documentation takes liberties with the language and nomenclature that can only confuse users when they try to figure out what they're doing. For example. In ZFS, a volume is a virtual block device that acts like a disk. A volume IS NOT a pool. A volume is a child construct of a pool.
But, the people creating FreeNAS obviously know NOTHING about ZFS, so I can't be surprised that they screwed up the nomenclature/language.

This was originally posted on  the NAS4Free wiki by me.  This is just another copy, just in case.