You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Wyng currently scans all archive metadata items (root, volumes and sessions) on startup. This impacts startup times and is also sub-optimal when encountering or recovering from errors.
Solution
Map the commands to metadata requirements, such as receive only needing one volume's metadata at a time. When receiving older sessions, it may not be necessary to instantiate all session objects / infos. verify, diff and list could have the same/similar metadata usage profile, while delete would be a special case where as little as zero volinfos could be used if the user is able to specify a volume id. And monitor would be another special case, since it is a goal to be able to run it without authenticating.
The profile for send would not be as flexible as the others, since the send workflow may call on both deduplication (which requires every bit of metadata) and pruning operations.
The arch-check command could have a similar profile to verify depending on the parameters used.
Notes
A generic load() method for objects may provide needed flexibility.
Its probable this issue will focus mainly on session objects, although being flexible with volume object should also be a goal.
The text was updated successfully, but these errors were encountered:
Problem
Wyng currently scans all archive metadata items (root, volumes and sessions) on startup. This impacts startup times and is also sub-optimal when encountering or recovering from errors.
Solution
Map the commands to metadata requirements, such as
receive
only needing one volume's metadata at a time. When receiving older sessions, it may not be necessary to instantiate all session objects / infos.verify
,diff
andlist
could have the same/similar metadata usage profile, whiledelete
would be a special case where as little as zero volinfos could be used if the user is able to specify a volume id. Andmonitor
would be another special case, since it is a goal to be able to run it without authenticating.The profile for
send
would not be as flexible as the others, since the send workflow may call on both deduplication (which requires every bit of metadata) and pruning operations.The
arch-check
command could have a similar profile toverify
depending on the parameters used.Notes
A generic load() method for objects may provide needed flexibility.
Its probable this issue will focus mainly on session objects, although being flexible with volume object should also be a goal.
The text was updated successfully, but these errors were encountered: