[Archived] Feature REQUESTS 2024

[admin]

Please add ability to install/update via WinGet

many thanks

I'm sorry we're not familiar with WinGet, we'll consider it in a future release. Thanks.

[n8chavez]

It would be nice is HBS could disable TRIM on an SSD when an image is being created or written to, and then enabled again when the reading/restoring is completed.

[Froggie]

N8, I'm curious, why would you want this to happen?  If TRIM is disabled during restoration then all the blocks in the SSD being restored to would be left orphaned and unavailable to the FileSystem under Windows (unless the garbage collection algorithm used by the SSD is smarter than most... they're all different).  If anything, the TRIMming of the blocks being restored, prior to restoration (the way Macrium REFLECT does it), guarantees no orphaned blocks caused by the restoration by itself.  Under any case, following the restoration (having used no TRIM), any periodic optimization by the OS after the restoration would free up those orphaned blocks anyway, unless the user never optimizes their disks during normal operation.  That would result in tons of orphaned SSD blocks that would eventually affect (slow down) SSD throughput.

As far as TRIMming the image target during the imaging operation, that doesn't make any sense at all due to the way Windows allocation and TRIM actually operate... not really a requirement here.

[n8chavez]

It was my understanding that having trim enabled during a restore can mess with proper 4k partition alignment. I could see your point, but partition alignment remains an issue. It's also worth noting that disabling trim before image creation is important because it reduces the amount of caching required for the source drive on systems with TRIM enabled by disabling TRIM during the backup operation. When TRIM is enabled the original contents of deleted sectors must be cached, whereas a normal delete doesn’t overwrite the sectors and instead just updates the directory entry.

But that's just me. Maybe I've been using IFW too long.

[Froggie]

It was my understanding that having trim enabled during a restore can mess with proper 4k partition alignment.  I could see your point, but partition alignment remains an issue.  It's also worth noting that disabling trim before image creation is important because it reduces the amount of caching required for the source drive on systems with TRIM enabled by disabling TRIM during the backup operation. When TRIM is enabled the original contents of deleted sectors must be cached, whereas a normal delete doesn’t overwrite the sectors and instead just updates the directory entry.

But that's just me.  Maybe I've been  using IFW too long.

Referencing the RED:  Now you've got me really confused    I've never heard of TRIM ever causing a 4K (I assume sector size here) sector-based partition problem.  It may have but I've been part of many discussions in this area and have never heard of such.

Referencing the GREEN: Something else I've never heard of.  Reducing Windows caching doesn't really affect the reading of the SOURCE drive in any major way other than possibly slowing up an older slower drive in its READ operation.

Referencing PURPLE: I think this statement is caught up in semantics between the SSD itself and the Windows operation.  What you're describing is basically what happens inside the SSD, not anywhere in Windows.  If TRIM is disabled in the SSD then the SSD will not clean up the old data being replaced during the write operation (aka "caching")... that's what I was referring to in my post above, that data will be orphaned inside the SSD until told to clean it up.  TRIM is the only way to do that cleanup, other than through some garbage collection algorithms.  None of this stuff affects the efficiency of your Windows operations... they are very straight forward as far as DELETE and TRIM are concerned.

The normal delete you describe above is, indeed, a Windows operation, but it never overwrites anything regardless of TRIM.  The way the DELETE operation works under Windows is as follows... the old method, does indeed update a directory entry as well as clear allocation blocks used in its FAT (File Allocation Table), that's all it needed to do.  When TRIM was introduced, it needed to be able to tell the SSD when its internal NAND memory was no longer needed.  What Windows decided to do was the same stuff it did with the older operations, but also send a special transaction to the SSD (via TRIM) that told the SSD what blocks were no longer needed... Windows was done at this point.  The SSD then, internally, would free up its NAND blocks by moving the data around and placing it in empty NAND blocks (a very efficient pure WRITE operation), basically filling up the empty blocks.  At this point, the SSD can now ERASE any NAND blocks that are no longer needed.  The most efficient operations within an SSD is a READ, WRITE & ERASE.  If the SSD cannot find any absolutely empty (unallocated) NAND blocks to use for this internal recovery, it then must rely on another very inefficient operation, the READ-MODIFY-WRITE (RMW), to enter data into the unused portion of existing non-empty NAND cells.  This is why if TRIM is not enabled over a longer period, eventually all those orphaned BLOCKS must be used for writing data, but can only be used with the RMW operation, which really slows down an SSD immensely.

The whole SSD internal operation is a complex one (it has its own "logical block" table similar to Windows and its own FAT table to represent what its NAND cells are really doing) and really doesn't reflect at all what Windows is doing.  Any major discussion of this type of operation should be be held elsewhere, not really in the Forum

[n8chavez]

Careful @Froggie. No where did I reference Windows. Read what I said again. Windows was never brought up. You're getting all working up over this, when it's really very simple, I want to prevent write amplification when restoring an image. Thus I need to temporarily disable trim.

Let me give a little background. An SSD write operation can be done to a single page but, due to hardware limitations, erase commands always affect entire blocks, so writing data to empty pages on an SSD is very fast, but slows down considerably once previously written pages need to be overwritten. So, restoring an image to an SSD is slower because the blocks are not empty in the first place. Since an erase of the cells in the page is needed before it can be written to again, but only entire blocks can be erased, an overwrite will initiate a read-erase-modify-write cycle the contents of the entire block are stored in cache, then the entire block is erased from the SSD, then the overwritten page(s) is written into the cached block, and only then can the entire updated block be written. So, as I said before, in order to eliminate this need to first cache the drives original contents before it can be erased it's best to temporarily disable trim in order to speed the restore up. Of course, this assumes the drive is not empty.

#themoreyouknow.

[Froggie]

I was assuming some Windows references... I no longer am.  Just a coupla statements here... the TRIM function is what eliminates long term write-amplification problems, that's a fact, and it will happen one way or another.  Secondly, if you do the exact same restore with or without TRIM, you will see no speed difference at all at the Windows restore level, especially when using Hasleo

If this doesn't make sense to you, we can agree to disagree on this issue.

[chmichael]

Hello,
I don't know if Hasleo backup is already using https://github.com/zlib-ng/zlib-ng lib for compression.

GitHub - zlib-ng/zlib-ng: zlib replacement with optimizations for "next gen…
zlib replacement with optimizations for "next generation" systems. - zlib…

We'll get a nice speed boost for v5.

Thank you

[admin]

Hello,
  I don't know if Hasleo backup is already using https://github.com/zlib-ng/zlib-ng lib for compression.
  We'll get a nice speed boost for v5.

Thank you

Thank you very much and we will consider it.

[n8chavez]

Would it be possible to get a more detailed "log" window when creating and restoring an image? Currently, we get a completion percentage, ETA, and time estimation. It would be nice to have a more specific showing of partition, write/read speeds, and more accurate timings.