Evaluating FreeNAS for new setup

[Bidule0hm]

SVN has nothing to do with concurrent file access.

Actually it does, it's the whole point of this type of software.

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.

Your network hardware should also be on an UPS. If the client crashes then no harm is done because TC will just crash too and it'll leave the .tc file like it is (in a consistent state) unless it crashes right at the time it write on the .tc of course, but then it the same if your client crashes when you write on a non-encrypted file. But it's so unlikely to happen that you have bigger and most frequent problems to deal with before this one.

 

[Helios]

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.

Okay, let me clarify. Suppose I completely fill two striped disks and then add a third one. I would like for the data not to be reshuffled immediately, but for the new drive to be filled normally over time.

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)

Do I have to be physically in front of the machine even if the encrypted volume is non-system, or can I mount it manually over SSH or any other interface and provide the password through there?

Actually it does, it's the whole point of this type of software.

The whole point of SVN and other SCMs is to be able to keep track of the changes made to a group of files over time. SVN doesn't allow concurrent access to any files. An SVN server process accepts connections from clients and serializes requests to update files. If two clients request a write to the same file at the same time, only one request will succeed. SVN cannot be used to serialize access to files that are continuously updated, such as database files, or file systems encapsulated in a single file. A file system driver is best at doing this.

Your network hardware should also be on an UPS.

What if I'm connected from work to my VPN and there's a blackout? Or even just an Internet outage, which lately have been unusually common.

If the client crashes then no harm is done because TC will just crash too and it'll leave the .tc file like it is (in a consistent state)

You're assuming that the OS is not caching writes to the network share, which I don't think is a safe assumption.

then it the same if your client crashes when you write on a non-encrypted file.

Again, it's not the same. The file system itself is being transmitted over the network. ZFS and the file that ZFS sees is uncorrupted (i.e. ZFS will report it as matching its checksum), but the contents of the file (the nested file system and all its contents) are in an unknown state until the caches from the client have been fully flushed and the file system has been unmounted.

 

[Bidule0hm]

SVN doesn't allow concurrent access to any files.

From the user PoV it does, but in reality each user edit a local copy and then SVN solve the mess that can happen when you send the edited files to the server. In the end the file on the server is not accessed by several users at the same time, problem solved.

What if I'm connected from work to my VPN and there's a blackout? Or even just an Internet outage, which lately have been unusually common.

Aww man, seriously? we can also talk about earthquakes, aliens, black holes, ...

You're assuming that the OS is not caching writes to the network share, which I don't think is a safe assumption.

How many times a year your client crashes? how many times a year do you access your encrypted volume and for how long? How long the OS is caching the data before sending it? ... Well, in the end you're more likely to win the lottery :)

Again, it's not the same. The file system itself is being transmitted over the network. ZFS and the file that ZFS sees is uncorrupted (i.e. ZFS will report it as matching its checksum), but the contents of the file (the nested file system and all its contents) are in an unknown state until the caches from the client have been fully flushed and the file system has been unmounted.

It's exactly the same problem if you use server side encryption. Or no encryption.

And I access pretty regularly a TC volume more than once a week on average for about 1 hour long each time and since I made the NAS. Not a single problem, ever. I guess it's pretty reliable. As I already said, there's bigger and/or far more likely to happen problems to take care of before this one ;)

 

[Helios]

From the user PoV it does, but in reality each user edit a local copy and then SVN solve the mess that can happen when you send the edited files to the server. In the end the file on the server is not accessed by several users at the same time, problem solved.

Right. Which is the same as not allowing concurrent access to any files. A single process (the SVN daemon) manipulates the database at any time.

Aww man, seriously? we can also talk about earthquakes, aliens, black holes, ...

Let's talk about things that actually happen a few times every year. I don't know what it's like where you live, but here the infrastructure is absolutely dreadful. To give an example, recently my commute has been disrupted because of a major long-term blackout in one of the neighborhoods. While they're trying to fix it they've put this gigantic generator that takes up the whole road. The same has been done this year in at least two other neighborhoods.
Last week we had not one but two Internet outages at the office.

How many times a year your client crashes?

One?

how many times a year do you access your encrypted volume and for how long?

Constantly. 24-7. From the server itself and from the local desktop. Occasionally from a remote desktop across the city.

How long the OS is caching the data before sending it?

Unknown. It's an implementation-dependent non-deterministic variable. I have no confidence to give any kind of estimate.

It's exactly the same problem if you use server side encryption. Or no encryption.

I have explained how it's not, so please give some kind of argument, instead of just repeating an unsubstantiated assertion.

And I access pretty regularly a TC volume more than once a week on average for about 1 hour long each time and since I made the NAS. Not a single problem, ever. I guess it's pretty reliable.

A lot of people believe that yanking out flash drives without unmounting is fine, until they trash the FS and learn to remove them properly.

 

[danb35]

Suppose I completely fill two striped disks and then add a third one. I would like for the data not to be reshuffled immediately, but for the new drive to be filled normally over time.

With ZFS being a copy-on-write filesystem, it's not recommended to completely fill your volumes. FreeNAS will start to warn you when they reach 80% capacity, and performance will really slow down at 90% or so. But that issue aside, what you describe is how it works. As data is written/deleted/changed, ZFS will work to balance the disks.

 

[Bidule0hm]

Let's talk about things that actually happen a few times every year. I don't know what it's like where you live, but here the infrastructure is absolutely dreadful. To give an example, recently my commute has been disrupted because of a major long-term blackout in one of the neighborhoods. While they're trying to fix it they've put this gigantic generator that takes up the whole road. The same has been done this year in at least two other neighborhoods.
Last week we had not one but two Internet outages at the office.

Well, if this kind of things happen often where your are then it's not a good idea to use a VPN to access files on a NAS to begin with, encryption or no encryption.

so please give some kind of argument, instead of just repeating an unsubstantiated assertion.

Well, if you corrupt some file because your client crashes or whatever, it doesn't matter if it's encrypted or not, as you said ZFS will report no checksum errors and the file is in an unknown state. I don't see where the encryption makes a difference.

A lot of people believe that yanking out flash drives without unmounting is fine, until they trash the FS and learn to remove them properly.

On windows it's fine if you know what you're doing (i.e. not unpluging it while your are writing files or if it's opened in the explorer for example), but yep, in other cases I agree ;)

 

[Ericloewe]

I haven't seen the word "snapshot" thrown around yet, so I will.

Snapshots will seriously mitigate any risk of corruption due to non-finished writes.

However, given that we're looking at encrypted container files, snapshots will end up being larger than if we were talking about bare files.

 

[Helios]

what you describe is how it works. As data is written/deleted/changed, ZFS will work to balance the disks.

Excellent.

Well, if this kind of things happen often where your are then it's not a good idea to use a VPN to access files on a NAS to begin with, encryption or no encryption.

It's not a problem if you're not doing anything silly, like transferring bits of a file system on demand over the network. At worst you'll get an incomplete upload.

Well, if you corrupt some file because your client crashes or whatever, it doesn't matter if it's encrypted or not, as you said ZFS will report no checksum errors and the file is in an unknown state. I don't see where the encryption makes a difference.

The encryption is not the problem. TC doesn't just encrypt a bunch a files, it encrypts a nested file system contained in a file. Accessing a VHD over the network would have the same kind of safety issues.

On windows it's fine if you know what you're doing (i.e. not unpluging it while your are writing files or if it's opened in the explorer for example)

Actually, no. Caches may remain unflushed until the device is unmounted. In fact, the blocks that are most likely to still be in the cache are those containing file system structure, because those aren't associated with any handles.

 

[anodos]

I looked into having a truecrypt volume on a samba share once. I abused it in lots of ways: pulling network cable, killing samba during writes, hard shutting down computer, etc. I never did corrupt it. Rolling back snapshots worked fine.

Ended up ditching it because I figured it was a pointless waste of energy. If someone owns my client computer they'll figure out a way to own my truecrypt volume on the server. If they figure out how to own my server, they'll figure out a way to own my truecrypt volume hosted on the server. If someone steals my server physically, they'll just sell the parts on craigslist. It just raised the guestion "what exactly am I trying to protect against?"

By the way, ZFS won't be able to do jack about data corruption it detects unless you have some redundancy. I think it's rather pointless to know something is corrupted unless you can actually fix it.

 

[depasseg]

When did the requirement for an encrypted container file pop up in this? The OP originally said an encrypted LVM volume, which from what I've found works like FreeNAS - Full Disk Encryption running below the filesystem.

 

[Helios]

I looked into having a truecrypt volume on a samba share once. I abused it in lots of ways: pulling network cable, killing samba during writes, hard shutting down computer, etc. I never did corrupt it.

You'll have to excuse me if I'm still unconvinced. That would be an interesting test, though. Have two VMs and have one perform random operations on a remote TC volume and have the other randomly reset Samba, and see how many iterations it takes for the file system to get hosed. Maybe I'll whip something up later.

By the way, ZFS won't be able to do jack about data corruption it detects unless you have some redundancy. I think it's rather pointless to know something is corrupted unless you can actually fix it.

My way to fix it is to download it again. If I only find out that it's been silently corrupted when I need it then my time gets wasted waiting for it.

 

[danb35]

When did the requirement for an encrypted container file pop up in this?

I think it came in with my suggestion that, since encryption was going away in FreeNAS 10 (at least in the initial release), something like TrueCrypt might be a serviceable substitute.

 

[depasseg]

I think it came in with my suggestion that, since encryption was going away in FreeNAS 10 (at least in the initial release), something like TrueCrypt might be a serviceable substitute.

In that case, just continue to use FreeNAS 9 until FN 10 includes encryption.

 

[Helios]

In that case, just continue to use FreeNAS 9 until FN 10 includes encryption.

So there are plans to add it back in the future?

 

[danb35]

So there are plans to add it back in the future?

Did you read the thread I linked to, much earlier? @jkh's comments read (to me) like they do intend to add encryption back to some future release of FreeNAS 10, but there's no specific timeframe, and no specific plan for how it will be done.

 

[depasseg]

Did you read the thread I linked to, much earlier? @jkh's comments read (to me) like they do intend to add encryption back to some future release of FreeNAS 10, but there's no specific timeframe, and no specific plan for how it will be done.

I was thinking the same thing?!

Here's the post: https://forums.freenas.org/index.php?threads/10-x-encryption.38979/#post-238723

 

[Helios]

Did you read the thread I linked to, much earlier?

Sorry, I didn't see it the first time.