Rob Shaver: Trying to discover if FreeNAS is what I need.

[Robert Shaver]

Your system will not fill up until there is a snapshot taken of the encrypted data. At that point it will look like all the old data got deleted and the original snapshot will reference all the old data and take up space.

I don't see how that is possible. The encrypted data has to be stored somewhere and the old data is not being overwritten, therefor the amount of storage in use has doubled.

Correct me if I'm wrong but, copy-on-write means that, at the time of each block write, a copy happens. I'm guessing now but I assume that the directory entry for each file consists of pointers to each block containing the file data. A snapshot consists of a copy of these file pointers. When a block is written to a file, it is written to free space on the disk and the pointer in the live directory entry is updated to that new block. This action continues for each block of the file, with a new block in the disk free space being consumed for each block. When the encryption of a file is finished, the old file plus the new file total twice as many blocks as before.

Again, correct me if I'm wrong. This is just how I've imagined how snapshots worked in storage systems. I don't really have any experience with it.

What I'm really wondering now is how freeNAS handles the error condition of disk free space exhaustion and does it have tools to come back from that? Can I just roll back to the previous snapshot?

Thanks all for hanging in there with me. I hope I'm not asking too much.

EDIT:
I thought I'd better read the docs some more. Here's what I found.

• ZFS is a transactional, Copy-On-Write (COW) filesystem. For each write request, a copy is made of the associated disk block(s) and all changes are made to the copy rather than to the original block(s). Once the write is complete, all block pointers are changed to point to the new copy. This means that ZFS always writes to free space and most writes will be sequential.

If I understand this correctly, when the first block is written, ZFS makes a copy of the whole file, then each block is written. Once the file is fully written then all the pointers are changed in the file record to point to the new blocks. I assume that the snapshot file record still points to the old blocks, preserving that data in case of rollback. In any case, the on-disk storage has doubled.

 

[SweetAndLow]

I don't see how that is possible. The encrypted data has to be stored somewhere and the old data is not being overwritten, therefor the amount of storage in use has doubled.

Correct me if I'm wrong but, copy-on-write means that, at the time of each block write, a copy happens. I'm guessing now but I assume that the directory entry for each file consists of pointers to each block containing the file data. A snapshot consists of a copy of these file pointers. When a block is written to a file, it is written to free space on the disk and the pointer in the live directory entry is updated to that new block. This action continues for each block of the file, with a new block in the disk free space being consumed for each block. When the encryption of a file is finished, the old file plus the new file total twice as many blocks as before.

Again, correct me if I'm wrong. This is just how I've imagined how snapshots worked in storage systems. I don't really have any experience with it.

What I'm really wondering now is how freeNAS handles the error condition of disk free space exhaustion and does it have tools to come back from that? Can I just roll back to the previous snapshot?

Thanks all for hanging in there with me. I hope I'm not asking too much.

Yes your explanation of correct. Mine was a little of. Like you said when the data gets deleted it still takes up space.

To recover from out of space you might be able to just rollback back. But you can definitely just truncate a file and it will fix the problem.

Sent from my Nexus 5X using Tapatalk

 

[Stux]

I don't see how that is possible. The encrypted data has to be stored somewhere and the old data is not being overwritten, therefor the amount of storage in use has doubled.

Correct me if I'm wrong but, copy-on-write means that, at the time of each block write, a copy happens. I'm guessing now but I assume that the directory entry for each file consists of pointers to each block containing the file data. A snapshot consists of a copy of these file pointers. When a block is written to a file, it is written to free space on the disk and the pointer in the live directory entry is updated to that new block. This action continues for each block of the file, with a new block in the disk free space being consumed for each block. When the encryption of a file is finished, the old file plus the new file total twice as many blocks as before.

Again, correct me if I'm wrong. This is just how I've imagined how snapshots worked in storage systems. I don't really have any experience with it.

What I'm really wondering now is how freeNAS handles the error condition of disk free space exhaustion and does it have tools to come back from that? Can I just roll back to the previous snapshot?

Thanks all for hanging in there with me. I hope I'm not asking too much.

EDIT:
I thought I'd better read the docs some more. Here's what I found.

• ZFS is a transactional, Copy-On-Write (COW) filesystem. For each write request, a copy is made of the associated disk block(s) and all changes are made to the copy rather than to the original block(s). Once the write is complete, all block pointers are changed to point to the new copy. This means that ZFS always writes to free space and most writes will be sequential.

If I understand this correctly, when the first block is written, ZFS makes a copy of the whole file, then each block is written. Once the file is fully written then all the pointers are changed in the file record to point to the new blocks. I assume that the snapshot file record still points to the old blocks, preserving that data in case of rollback. In any case, the on-disk storage has doubled.

In the event of a ransomeware crypto event, where your free space is not sufficient for a full copy the ransom wars will fail part way through encrypting, which is a good thing.

You then rollback to a previous snapshot.

If you have issues due to no free space, you first resolve that, then rollback.

 

[danb35]

...and again, as @Robert Trevellyan and I both mentioned, there are precautions you can take to keep the pool from reaching 100% full (which you never want to happen anyway).