Improve Reflects handling of Directory mounted backup disks. It gets a little schizophrenic and...


Improve Reflects handling of Directory mounted backup disks. It gets a...
Author
Message
criddle
criddle
Junior Member
Junior Member (50 reputation)Junior Member (50 reputation)Junior Member (50 reputation)Junior Member (50 reputation)Junior Member (50 reputation)Junior Member (50 reputation)Junior Member (50 reputation)Junior Member (50 reputation)Junior Member (50 reputation)Junior Member (50 reputation)
Group: Forum Members
Posts: 38, Visits: 181
When using HDs mounted on directories, rather than having a letter assignment, some parts of the software seem to sort of understand it, while other parts do not recognize it at all.

Background:

My system runs 30+ HDs of various kinds (M.2 NVMe drives, old -style SATA based SSDs, and a lot of spinner drives).

As far as drive identification goes, the most obvious issue is that there is only 26 letters in the alphabet.
They cannot all be named as Letter drives (C:, D:/ ..) when letters also have to be used for optical drives, keeping letters free for insertion of a multitude of Flash drives, external "loose" USB drives, and disk docks, ... Where all are mounted and dynamically identified by Windows on a Letter-style drive when attached.

In addition to the above , other problems occur with Windows Explorer, since

a) I hate seeing all those drive letters every time I use Windows Explorer. Unnecessary, since a large portion are only accessed by one application. Goes for both my backup drives and pure media drives.
b) It also slows Explorer startups, since it queries the drives to show their status/space when in "This PC". No need to neither see, nor query all the drives.

What I currently see is bad enough, as I try to keep that window sized so I don't have to scroll. Smile


My solution to this overall is to mount backup drives and media drives, which I don't need to see in Explorer as "letter drives", on sub-directories off the system drive instead. Works great in all respects, except for Macrium Reflect.
For example, all my backup drives are mounted on subdirectories off C:/0-BackupDisks/.

Mount directories as shown here:


Backups to these mounted "directories" run fine, except for some internal confusions in Reflect:

a) Confusion on what the destination drive actually is:

From a backup log-file:

Operation 2 of 2
Hard Disk: 8
Drive Letter: E
Volume: \\?\Volume{c3ceff83-c8b8-405c-b3b4-71564b7f5577}
File System: NTFS
CBT: Y
Label: Home Drive B1+2
Size: 9.09 TB
Free: 6.78 TB
Used: 2.32 TB 
--------------------------------------------------------------------------------
Starting Image - Friday, September 8, 2023 3:00 AM
Initializing
Write Method: Using File System Cache
Destination Drive: Athena Boot - NVMe M.2 (C:) - Free Space 3.60 TB
Free space threshold: Delete oldest backup sets when free space is less than 2.93 TB

Creating Volume Snapshot - Please Wait

As you can see, Reflect reporting is partly confused:

Athena Boot - NVMe M.2 (C:) - Free Space 3.60 TB

Yes, the "sub-directory" Reflect is being told to deposit the backup in is 'C:\0-BackupDisks\E_Drive_Image_MAC-LB4\Macrium-Reflect\E-Drive-Image\', but the actual drive is not C:.
Reflect is partially confused, since the first part of the message, the drive ("Athena Boot - NVMe M.2 (C: )" is incorrect, but the latter part ("Free Space 3.60 TB") is actually correct and belonging to the actual mounted backup drive
, not the C: system drive, which is physically a 2TB M.2 NVMe drive, that I would never use as a backup destination.   So, Reflect actually manages to determine the available space for the RIGHT drive, despite the path confusion, which is good.

A minor cosmetic problem for sure. Worse is the next one.

b) Side-effect in identification and Reflect's disk speed testing. Reflect speed-tests the wrong drive.

First time you use a new path/disk for backup, Reflect does its Drive Write speed test, determining whether to use File System Cache or Direct I/O. for that drive.
This goes haywire, since that part of Reflect sees all these "mounted" drive paths as belonging to the C: drive (NOT used as a backup destination) , and uses its "Drive Speed test" information for all the real drives.
It deposits its test file in the root directory of the backup path, which of course is a different drive from the actual backup drive it meant to test. It speeds tests the C: drive instead of the drive the backup will go to.

Since my C: drive is a 2TB M.2 NVMe Samsung 980 Pro, this messes with the I/O selections.
See this snapshot from "Backup -> Disk Write Performance", indicating why Reflect always chooses "File System Cache" for backups going to the mounted drives. It always extracts the speed calculations for the C: drive, where there is a factor of 10 between "File System Cache" and "Direct I/O".



Of course, simply depositing the test file in the full path backup directory would test the right speed, but then the storage of Reflect's internal table of drive speeds would have to change, since as shown in the above, the Drive Write speed lists only by letter drive. In other words, like other parts of Windows, Reflect would have to learn to find and use the REAL identification for each actual backup drive, similar to how Windows itself sees them.
As shown in this small snapshot from Windows Task Manager Performance window:



Maybe a minor issue, since backups otherwise function fine on directory mounted drives, but both of Reflect's logging and drive speed selections are off track. Smile

Hence the request for the wish-list: Teach Reflect and its companion apps about directory mounted drives. Smile

JK
JK
Macrium Hero
Macrium Hero (2.4K reputation)Macrium Hero (2.4K reputation)Macrium Hero (2.4K reputation)Macrium Hero (2.4K reputation)Macrium Hero (2.4K reputation)Macrium Hero (2.4K reputation)Macrium Hero (2.4K reputation)Macrium Hero (2.4K reputation)Macrium Hero (2.4K reputation)Macrium Hero (2.4K reputation)
Group: Forum Members
Posts: 1.5K, Visits: 6K
I support your Wish List proposal.  I also feel that a holistic solution to these types of issues would/could/should also address some feature requests and issues/bugs that I have previously posted in the forum:




                                
Edited 8 September 2023 2:47 PM by JK
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Login

Explore
Messages
Mentions
Search