Evaluating FreeNAS for new setup

[Helios]

Hi.

Right now for my home server I'm running an Ubuntu box with 4, 2, and two 1 TB Caviars of various colors, merged into a single encrypted partition by LVM. I'm planning to get a hardware upgrade soon, so I'm once again considering FreeNAS. Last time it was rejected because its hardware requirements far outstripped my budget for the system. I have some doubts I'd like to have clarified.

The data in this server is for the most part not vital and if necessary I can generate or get it again. I'm interested in ZFS not primarily because of its ability to correct, but to detect errors. I understand that it generates checksums at block level and periodically scans its blocks to detect errors, correct? If FreeNAS will notify me somehow, that's enough for me. I don't need any redundancy. The data I do care about I can just encrypt and upload wherever.
What I do need is the ability to grow my capacity as time goes on.
So, my question is: is there any way to expose to SMB a single encrypted directory with the accumulated size of, say, three drives, and then later on add a fourth drive and maintain the same configuration to external computers? If possible, would this operation involve rewriting all the blocks and/or reshuffling them among the devices?

Thanks.

 

[danb35]

If you don't care at all about redundancy, and you're comfortable with the fact that adding more drives to your pool increases your risk of data loss (since the failure of any drive in a striped pool will result in the loss of all data on the pool), then yes, it's possible to do exactly what you're suggesting, with the possible exception of encryption.

Encryption in 9.x and prior is done at the disk level. Thus, all disks are encrypted, and the filesystem is written onto the encrypted disks. There's no way to selectively encrypt certain datasets or directories. FreeNAS 10 is going to remove the encryption capabilities entirely, as they frankly didn't work too well. But if you run something like TrueCrypt on your clients, that should cover your encryption needs.

 

[Helios]

That's not actually the "official" replacement for server-side encryption, is it? Doing the encryption on the client side is absolutely crummy. What's the point of using a high reliability file system like ZFS if we're just going to add uncontrolled caching at the other side of a network pipe, not to mention a nested file system journal?

That's too bad, because I definitely do need encryption. What do you mean it didn't work too well?

 

[danb35]

At this time, to the best of my knowledge, there is no specific planned replacement for server-side encryption. You can find some discussion of the subject in this thread. It never did (and likely never will) support per-dataset or per-directory encryption, so your desire to share "a single encrypted directory" may not be possible even in the current version, depending on exactly how you mean that.

The problems that I've seen (and bear in mind I've never used encryption, so this is based on the threads I remember around here) seem to deal mostly with key management. If the keys are lost, of course, your data's toast. But it isn't straightforward to keep safe copies of your keys, or to ensure that the key state is consistent. The result is that a number of users have completely lost their data. At this point, I believe the official position of iXSystems (i.e., what's in the documentation) is that encryption isn't recommended unless you have a specific legal requirement to use it.

 

[Bidule0hm]

Doing the encryption on the client side is absolutely crummy. What's the point of using a high reliability file system like ZFS if we're just going to add uncontrolled caching at the other side of a network pipe, not to mention a nested file system journal?

In fact it's more secure because the data travelling on the network is encrypted, but it's not with server side encryption.

 

[Helios]

t never did (and likely never will) support per-dataset or per-directory encryption, so your desire to share "a single encrypted directory" may not be possible even in the current version, depending on exactly how you mean that.

I didn't mean to imply that I wanted a single directory encrypted on the file system. What I wanted to emphasize was that all the disks should appear as a single directory, not several.

In fact it's more secure because the data travelling on the network is encrypted, but it's not with server side encryption.

My complaint was about data integrity, not security, but since you bring it up, personally I'm not particularly concerned about the security of the 15 m Ethernet cable connecting my two computers. If for some insane reason I were, I'd encapsulate with OpenVPN (although I'm not entirely sure how I would transfer the keys without involving any cables). The advantage of that solution would be that more than one client would be able to use the volume at the same time.

 

[danb35]

What I wanted to emphasize was that all the disks should appear as a single directory, not several.

Yes, ZFS and FreeNAS can absolutely do that.

 

[Bidule0hm]

My complaint was about data integrity, not security

Oh, ok. But encryption or not you'll the same level of data integrity in either case anyway.

 

[Helios]

But encryption or not you'll the same level of data integrity in either case anyway.

Are you sure? What happens if either system loses power? What happens if a client writes to the encrypted volume while another client that had opened it was sleeping? What happens if a packet gets lost? Are you sure the TC driver can cope reasonably with this?

 

[Bidule0hm]

What happens if either system loses power? What happens if a client writes to the encrypted volume while another client that had opened it was sleeping? What happens if a packet gets lost?

Exactly the same as with server side encryption or non-encrypted files: possible corruption.

 

[Helios]

No, not "exactly the same". Client-side encryption involves transmission of the nested file system over the network, not just of data. The integrity of the nested file system is directly related to the number of network jumps between the two computers.

 

[Bidule0hm]

In the end corruption is corruption, you don't want it.

Hopefully TCP/IP can deal with lost packets and retransmit them.

 

[Helios]

In the end corruption is corruption, you don't want it.

Therefore limiting the damage it can make is pointless?

Hopefully TCP/IP can deal with lost packets and retransmit them.

It can't deal with the other situations I mentioned.

 

[Bidule0hm]

Those are pretty extreme and rare situations (or very dumb ones: you don't let multiple users edit the same file at the same time, if you really need to manage this there's version control software like SVN to do this) and they shouldn't happen, or something is wrong with the system design (for example your server should be plugged on an UPS to avoid power loss).

 

[depasseg]

I'm interested in ZFS not primarily because of its ability to correct, but to detect errors. I understand that it generates checksums at block level and periodically scans its blocks to detect errors, correct? If FreeNAS will notify me somehow, that's enough for me. I don't need any redundancy. The data I do care about I can just encrypt and upload wherever.

Yes FreeNAS will do this, regardless of the number of drives and whether or not it can recover the corrupt data.

What I do need is the ability to grow my capacity as time goes on. So, my question is: is there any way to expose to SMB a single encrypted directory with the accumulated size of, say, three drives, and then later on add a fourth drive and maintain the same configuration to external computers?

Yes, it's very easy, and folks accidentally do it all the time. Just be aware that a single drive failure destroys the entire pool.

If possible, would this operation involve rewriting all the blocks and/or reshuffling them among the devices?

The only way I'm aware of to balance the data across all the drives evenly is to actually move the data off and back onto that volume.

 

[Helios]

The only way I'm aware of to balance the data across all the drives evenly is to actually move the data off and back onto that volume.

Thanks for your reply. So striping is the only data layout FreeNAS offers, is it?

or very dumb ones: you don't let multiple users edit the same file at the same time

Computer A can use \\server\share\foo.txt and computer B can use \\server\share\bar.txt without any conflicts. If foo.txt and bat.txt are in \\server\share\vol.tc, only one computer at a time can use any file. You yourself point out why this solution is stupid.

if you really need to manage this there's version control software like SVN to do this

SVN has nothing to do with concurrent file access.

for example your server should be plugged on an UPS to avoid power loss

A UPS doesn't protect against power loss somewhere in the middle of the network, nor against crashes in the client that could leave the nested file system in an undefined state.

Honestly, I don't understand how this is controversial in any way. This is a retarded solution. Yesterday I was researching whether to virtualize FreeNAS and found a post saying not to trust the PCI passthrough implementation in prosumer motherboards, and not to nest ZFS on top of a virtual drive, and now I find myself explaining how adding computers and networks into the mix is a bad idea?

 

[pirateghost]

First of all, you have some reading to do.

Second of all, please lose the attitude. We are all volunteers around here, and if you come in with an attitude like this, you will alienate yourself.

It sounds like FreeNAS is not the right fit for your environment, or you do not understand how FreeNAS works. We have documentation that explains how it works. Feel free to browse around, but do not discredit the individual volunteers around here that have spent countless hours helping others understand how to use FreeNAS and not lose their data.

 

[danb35]

So striping is the only data layout FreeNAS offers, is it?

Not at all. It's simply the layout most consistent with your stated goals of easy piecemeal expansion, and no concern for redundancy. It also supports mirrors and a variety of RAIDZ configurations, but those use some disk space for redundancy, and are not as easily expandable if you want to retain redundancy.

As to the encryption, if you want it, versions up to 9.3.1, the current release, offer it. iX has said that the initial release of 10 will not. I suspect that a future release of 10 will, but that's just me. If you choose to use it, do a lot of reading here first, and make sure you have backups of your keys.

 

[depasseg]

Thanks for your reply. So striping is the only data layout FreeNAS offers, is it?

Striping vdevs is the only way I'm aware of that ZFS can expand. vdevs can contain anywhere from 1 drive up to a dozen+ in RAID-Z(1,2,3) or you can add mirrors.
And the balancing I thought you were asking about was taking some of the data from disk 1 & 2 and move it to newly added disk 3 , which FreeNAS won't do automatically.

 

[depasseg]

And I missed the part about the SMB share being encrypted. I thought you were just talking about the data you were moving off-site. As long as you don't mind all of your data being encrypted on disk (and the hassles that go with it like needing to provide a password at boot) then it sounds like what you have today (http://security.stackexchange.com/questions/39080/ubuntu-lvm-encryption)