Disable Snapshots on Thick Volumes

[wk170]

Have replaced the disks on my TS-453A, and now deciding between Static and Thick Volumes.

Certainly, Thick volumes offer a lot of advantages, but myself do not need the snapshot feature.

Have some related questions:
1/. Can the snapshot feature be completely disabled on a thick volume?
2/. If so, what will then be approximately the performance loss between Thick-volume(without snapshot) and Static, will that improve a lot compared to Thick-Volume(with snapshot) and Static?
3/. Can the snapshot reserved space be reduced to 0?

At the moment for me the only reasons why I would choice for Static is the better performance and no loss of space of due to snapshots.
If I can disable snapshots on a Thick volume, and as a result the performance gets closer to Static, and there is no space lost for snapshots, I would choice Thick.

Please advise. Thanks.

[P3R]

1/. Can the snapshot feature be completely disabled on a thick volume?

I don't think it can be permanently disabled but you could simply decide to never enable them. I run one volume with and one without snapshots.

2/. If so, what will then be approximately the performance loss between Thick-volume(without snapshot) and Static...

I don't know but my educated guess is that it's very small.

3/. Can the snapshot reserved space be reduced to 0?

By default nothing is reserved unless you actively reserve it.

At the moment for me the only reasons why I would choice for Static is the better performance and no loss of space of due to snapshots.

The main performance bottleneck in your system is the gigabit networking and not the storage so you most likely wouldn't notice any performance difference even with snapshots enabled.

[bookcar]

If I understand correctly, you do not want to run snapshots on a thick volume.

The snapshot on a thick volume does so on the entire volume (even when most of the volume is empty). So when you write more files into the volume, all the past snapshots will be written into as well and this would have rather bad disk usage and performance implications.

In contrast, thin volumes only snapshot on the actual data. So writing more files will not affect the past snapshots much at all (but deleting files will).

The way I do it: 1) If I will constantly delete files (e.g. log file, temp files), they go into a static volume; 2) If I need versioning from snapshots, I put them on a thin volume.

For some unknown reason, I was not given the option to create a static volume on a RAID5 storage pool. So I had to settle on a thick volume (but I would not run snapshots on it).

[Mousetick]

If I understand correctly, you do not want to run snapshots on a thick volume.

It doesn't work quite like that.

Using QNAP terminology, there are 2 options to choose from when initializing disk storage:
- Static Volume: snapshots can never be used.
- Storage Pool: snapshots can be enabled or disabled at will, free or reserved space in the pool determines how many can be taken and how much data can be changed.

In the latter case, it doesn't matter if the volumes are QNAP thick or QNAP thin in the Storage Pool. Snapshots work exactly the same way with either volume type, there is zero difference between thick and thin as regards to snapshots.

Under the hood, a QNAP Storage Pool is implemented as a thin LVM2 pool. And both QNAP thin and thick volumes are implemented as thin LVM2 volumes within the thin pool. A QNAP thick volume is pre-allocated so that it occupies all the space of its max capacity from the start within the thin pool, and as such its performance degrades less with fragmentation within the pool. QNAP snapshots are implemented as thin LVM2 snapshots stored in the same LVM2 thin pool. They don't suffer from the copy amplification and space usage of old "thick" LVM snapshots when multiple snapshots are taken. All volumes and snapshots in the thin pool share the same data, only their metadata differ. So if 1 block is modified on the origin volume, and there are N snapshots, only 1 block is copied, and N block maps are updated.

[bookcar]

Mousetick: Thanks for your detailed explanations. Two things:

1) Could you take a quick glance at this paper?
https://media.eetgroup.com/documents/Doc_25068669.pdf

On page, 6 it stated:

"3.3. Thick Volume and Thin Volume Snapshots

Thick and thin volume snapshots are different in QTS. A thick volume snapshot records the state
of all used and unused blocks. A thin volume snapshot records the state of used blocks only. This
makes thin volumes more space efficient for both storing data and when using snapshots."

Maybe you are over-estimating QTS's sophistication when it implements the thick volume snapshot. (You would think that QTS knows to use the inode table to snapshot data blocks only. But the paper seems to indicate that QTS blindly snapshots all blocks on the volume.)

2) You stated: "So if 1 block is modified on the origin volume, and there are N snapshots, only 1 block is copied, and N block maps are updated."

Would it be 1 block copied, or N blocks copied? Consider the case of deletion of 1 block in the actual data. Mathematically and informationally, one only needs to copy one block. But that requires that the N snapshots record deltas with respect to the copied block (wherever that block is now placed). The N snapshots cannot just naively record individual deltas with respect to the actual data (as that would require N blocks copied). Are multi-snapshots implemented in the "smart" or the "dumb" way?

[Mousetick]

1) Could you take a quick glance at this paper?
https://media.eetgroup.com/documents/Doc_25068669.pdf

This paper seems to have been written as a marketing piece to promote QNAP's use of ext4 and LVM snapshots vs. Synology's use of Btrfs. So I would take what it says with a grain of salt.

On page, 6 it stated:

"3.3. Thick Volume and Thin Volume Snapshots

Thick and thin volume snapshots are different in QTS. A thick volume snapshot records the state
of all used and unused blocks. A thin volume snapshot records the state of used blocks only. This
makes thin volumes more space efficient for both storing data and when using snapshots."

That seems logical to me. In a QNAP thick volume, unused blocks are still reserved out of the pool and are part of the volume. From the point of view of the pool, they are always "used" no matter if they're actually occupied by data in the volume or not. So they're always tracked. In a QNAP thin volume, unused blocks are not part of the volume, they belong to the parent pool, so they don't need to be tracked.

If an initially "unused" block is later used to store data in a thick volume, it will be copied to the snapshot. If an initially unused block is later used to store data in thin volume, nothing is copied to the snapshot, only the block map is updated.

So yes, you're quite right in the case of data growth, thin volume snapshots are more efficient (space- and performance-wise) than thick volume snapshots. In other scenarios they're pretty much equivalent.

Keep in mind the LVM has no knowledge of filesystems. It has no notion nor visibility into the internal data structures of ext4. It doesn't "know" what an inode is nor does it care. It works at a lower level, basically like a virtual disk. There can be no filesystem-dependent optimization. That's a limitation of LVM. Other filesystems like Btrfs and ZFS have built-in support for snapshots and can be much smarter in their snapshot implementation.

So when QNAP talks about used and unused blocks, they're referring to "virtual disk" blocks, not filesystem allocation blocks. It seems to me that the theoretical efficiency advantage of thin volume vs. thick volume snapshots diminishes over time, unless you regularly use the "reclaim space" feature of the thin volume to shrink its filesystem and release the unused (by filesystem) blocks back to the pool. As the thin volume expands and uses up more blocks from the pool, these blocks are considered used by the volume for snapshot purpose, whether they are actually occupied by data or not at the filesystem level. So we end up in a similar situation as with thick volumes.

2) You stated: "So if 1 block is modified on the origin volume, and there are N snapshots, only 1 block is copied, and N block maps are updated."

Would it be 1 block copied, or N blocks copied? Consider the case of deletion of 1 block in the actual data. Mathematically and informationally, one only needs to copy one block. But that requires that the N snapshots record deltas with respect to the copied block (wherever that block is now placed). The N snapshots cannot just naively record individual deltas with respect to the actual data (as that would require N blocks copied). Are multi-snapshots implemented in the "smart" or the "dumb" way?

I don't quite understand what you mean by "deletion of 1 block". How does one delete a block? If you mean that 1 block becomes free, there is nothing to copy. The block still holds some data that doesn't need to be saved by the snapshot until the block is allocated again and overwritten.

[bookcar]

Mousetick : Thanks for explaining that snapshot is NOT at the filesystem level. I guess QTS has no choice but to track the entire volume for a thick volume. I never tried ZFS or Btrfs. Look forward to checking those out later.

"Deletion of 1 block" should have been phrased as "x number of blocks get changed due to deletion of one file." But as you explained, snapshot does not know about files, so my question really should be phrased as "x number of blocks changed in the volume." Then would 1) x blocks get copied, "jointly" for all N snapshots, or 2) x blocks get copied for each snapshot (N*x in total)?

[Mousetick]

Then would 1) x blocks get copied, "jointly" for all N snapshots, or 2) x blocks get copied for each snapshot (N*x in total)?

#1 would happen.

A LVM2 snapshot is just map of pointers to blocks in the thin pool. It doesn't contain blocks per se. So x blocks get copied once, somewhere in the thin pool, and then for each snapshot, x pointers are updated in its respective block map. That's a grand total of x block copies, and N*x pointer updates (trivial operations compared to block copies). The origin volume is also a block map. So all blocks in the thin pool are "shared" between origin volume and snapshots via pointers in block maps, there is no duplication.

[bookcar]

Thanks. Make sense now. I thought it was #2. I actually woke up this morning with this great idea that one could do #1. There are may too many people way smarter than I am.

Right now, I have this one volume which holds:
A) source code,
B) data files that get "updated" every day,
C) directories holding new daily data dumps (add files only).

A) and B) could benefit from versioning. C) would not. Right now, they are all on this thin volume, with snapshot.

Maybe the best arrangement is to have two thick volumes:
-- Thick #1 will hold A) and B), with snapshots (I mostly modify files, only add occasionally)
-- Thick #2 will hold C), without any snapshots (I never modify files, but add all the time)

Maybe this is the most optimal?

[Mousetick]

Maybe this is the most optimal?

Well, it depends Are you making regular backups of your volume(s) to at least one external device? If not, forget about snapshots for now and start making backups!

Why snapshots alone are not backups
Why is Snapshot Not a Backup?

For versioning source code, a source code tracking system such as Git would be a lot more appropriate and efficient than volume snapshots.

Other than that yes it would make sense to segregate your data into two volumes, one snapshotted and the other not. Particularly if data on the second volume mostly grows and rarely changes or is seldom deleted, in that case snapshots would be almost useless and only waste disk space.

[bookcar]

Nothing beats backups, onsite and offsite!

RAID and snapshots do not replace backups. Snapshots are really for versioning ONLY.

[P3R]

Snapshots are really for versioning ONLY.

Good backups (like with HBS) are versioned as well so I'd say that snapshots are really only for very fast restores.

[AgileTS]

That seems logical to me. In a QNAP thick volume, unused blocks are still reserved out of the pool and are part of the volume. From the point of view of the pool, they are always "used" no matter if they're actually occupied by data in the volume or not. So they're always tracked. In a QNAP thin volume, unused blocks are not part of the volume, they belong to the parent pool, so they don't need to be tracked.

Thanks for this clarification, Mousetick. Helps me a lot.
I suspect this is the reason I'm getting terrible snapshot performance on a client NAS. It's a thick volume, used as a file sync repository, with daily snapshots up to 90 days and I'm seeing storage utilization at 10x the actual repository size, after 12 months in use.
Will definitely convert to a Thin Volume.
I probably should have read the QNAP documentation more thoroughly before implementing

Cheers,