If not, are any of those blocks shared with other files in its own chain?Īre any blocks shared outside a backup chain?įor example two backup jobs (chains) of identical virgin windows servers, written to repo one after the other - would we expect most of those blocks to be shared between the chains, or kept separate because they're separate chains? Does "per-vm file" setting affect this?
Wise memory optimizer notification clones full#
If so, why do we routinely see VIBs written with very high fragmentation levels (at least 1 frag per 2.4 MB), even though the repo is only 50% full and the free space is fairly contiguous? Please can someone from Veeam clarify if a fresh VIB is entirely composed of new unshared blocks, even if by some magic all the block in the VIB are already on the disk from another file? To pick up on what's performance we should expect, because I've got some evidence that aligns with what sees. There must be something else in play here. The 200 vs 40MB/s is a very high degradation with such a small chain isn't it. Why is a fresh vib file read degraded, it's not in any way touched by ReFS, correct? When copying a VBK or VIB file somewhere else on the same disk 40MB/s, and then copy it to same or another extend or 200 MB/s vib file to another extend, it just goes 40MB/s Veeam backup job writing to extend goes with the same speed 200 MB/s. This seem logical, as there's nothing being done ReFS wise to the file.
Copying this file to other extends goes with the same speed, even when this file is left for a couple of days or weeks. A non Veeam file from network to a ReFS volume goes with 200 MB/s. Just small chains, but the read speed on all files vib and vbk are terrible.īoth SOBRs experience the following symptoms: We store just 14 restore points with synthetic fulls on saturday. SOBR 2 with datastores via NFS backed by NetApp SATA pools / each node (VM) has 12TB ReFS. SOBR 1 with local disks / each node has about 35TB ReFS backed by 12 4TB SATA drives. WE have two differente types of repositories.
I'm staring a defrag on a 11TB volume and see how that goes. It's difficult to draw conclusions across the limited results I've seen due to dramatic difference in size of volume, amount of data, retention, and hardware type, so anything you learn and share here would be a welcome addition. However, results from defragmentation in real world environments are still pretty limited, and the limited results I do have indicated very mixed results, with a few reporting minor/moderate improvements to others showing basically no improvement at all and one even reporting a small decrease in performance after days of defragmentation. Unfortunately, fragmentation is the natural side effect of any solution that shares data segments between multiple references so some degradation over time is certainly expected, especially if you are keeping multiple synthetic fulls in backup chains. However, if synthetic fulls are in use, the overall benefit is not very large as defragmenting one file simply fragments the other files that are sharing those same blocks. There could be some advantages to defragmentation especially when space utilization gets above say 70%, just by keeping the areas for new data more consolidated allowing any new added data to be less fragmented. However, if you are using one of the forever modes, such as reverse incremental or forward incremental without synthetic/active fulls, then using the Veeam settings for defrag and compact can still be useful to clean unsused space and reorganize the metadata within the VBK file. There's simply no way to avoid this when cloning the same blocks between files, there's nothing defragmentation can do about this, if I defragmented File2 then File1 would be fragemented.Īt this point I'm not recommending file system defragmentation runs on ReFS until more testing is complete (I haven't found it to cause any issues, but so far also no benefit, just wasted I/O). File2 is sharing two blocks from File1, so it is immediately 50% fragmented. In this example, File1 has four blocks of 64K each (cluster size) laid out in order on the disk, so 0% fragmentation. Luca's point was that defrag is unlikely to be useful for ReFS when block cloning is in use simply because it's impossible for a single block to be in an optimal location for more than one file.
0 kommentar(er)
