UTSW-TX wrote:

Will this be solved by disabling snapshots in general or is there something inherent to modifying a lot of data while connected via LUN/iSCSI?

It's general, but is usually more problematic with LUNs than with shares.

When you first take a snapshot, it takes no space - all the data blocks are held in common with the main share. As the main share changes, any updated blocks are written as new blocks (e.g., "copy on write"). The original block then is in the snapshot only - so it now starts using space. And the updated file (or LUN) becomes fragmented.

So if you have a lot of updates happening in the share, the snapshots take a lot of space, and the main share (or LUN) quickly becomes fragmented. Defragmenting the file (LUN) in the main share actually makes the snapshot space go up. The main file is re-written, so it ends up sharing no blocks in common with the snapshot.

A LUN is simply raw block storage for the NAS - so operations that rewrite metadata or otherwise reorganize the storage are detrimental when snapshots are on. For instance, when snapshots are enabled, defragmenting the file system in the LUN will create fragmentation in the LUN container itself, and every disk block that is modified increases the snapshot space usage. So you end up with poor performance combined with a big loss of free space in the RAID array.

There are other cases where snapshots shouldn't be enabled. A torrent download creates similar "churn", as do updates to SQL databases.

Forum Discussion

Ring won’t connect