Jump to content

davidduff

Members
  • Content count

    116
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by davidduff

  1. hitting "stop" in the activities view with a grooming operation selected does not stop the selected operation. i have a runaway groom operation that is crashing retroengine. every time it crashes, it restarts itself and comes back trying to do the same groom. hitting the stop button seeming accomplishes nothing. the status of the task switches to "please wait...", then nothing happens for a while. then the engine eventually crashes again.
  2. i'm wondering about grooming under version 10. as a preface, i will say that i could never really get grooming to work the way i wanted it under versions 8 (where i mostly didn't experiment much due to a variety of other problems and issues) and version 9 (where my experiments met with poor results leaving me thinking that i must be doing something fundamentally "wrong" in terms of how the program was designed to work). my simplistic starting assumption is that with grooming, retrospect should be able to work somewhat like the way time machine does in that you could allocate some storage to it, let it start backing up and it would save everything (every version, every incremental backup, etc.) until it ran out of space, and then when the allocated space was depleted, it would start deleting the oldest, unused stuff to make way for new stuff. with a modest number of machines (3-4) and what seemed to me to be a modest number of backups (roughly 2x/week for a few months), i would find that my media sets would take a really really long time to groom (like ~3-4 days) under version 9. so now i've installed version 10 and i'm trying it out. my first attempt is to groom an existing media set with 1TB of storage and a few million files. so far it's been running almost 5hrs. as with previous versions, there are NO meaningful progress indicators of any kind during grooming, which is quite frustrating (edit: see followup note below about progress reporting). but if i had to guess, i would say that version 10 does not look like it is going to provide any kind of huge improvement. the web page describing mac version 10 says "IMPROVED! Automatic Disk Grooming Tell Retrospect how many backups to keep, and it will automatically remove older backups when it needs more space on disk-based storage. This technology allows Retrospect to perform faster, smaller Smart Incremental backups forever." this sounds like exactly what i'm looking for. questions: is there something i need to do in order to see this "improved" behavior and in particular to see faster grooming? for example, do i need to create new media sets? is there some kind of first-time cost when v10 reads v9 catalogs before this wonderful new feature kicks-in? any other advice on how to get "smart incremental backups forever" w/o having to recycle backup sets and hopefully without needing multi-day groom operations?
  3. can anyone point me to a document or support article or past forum thread that will tell me about how to use the "is like" operator? i see that rules includes "is like" as a matching operator. i gather that this is supposed to be a pattern or regex type match. the existence of "is like" is mentioned in the Retrospect 8 User Guide, but the specifics are not documented - for example, whether it expects "standard" regexp syntax in the pattern or something else. i am looking into the use of rules to better partition my backups according to the backup-related properties. so for example, i might have separate media sets to handle photos/music vs. other stuff in users' doc directories vs. the non-user directory contents of machines. i can't find any user manual for v9 or v10 of retrospect. the v8 manual, as i indicated, does mention rules (seemingly based on selectors of retrospect v6), but does not cover "is like" (unless i missed it). thanks.
  4. quick summary of my experiments to date with grooming under retrospect 10: a few times, i had media sets that seemed otherwise healthy, but when i tried to do a groom, problems were found and i had to fall back and do a full catalog rebuild. hopefully, that's not a recurring issue but instead is either a one-time v9-v10 transition issue or something. i will monitor ongoing behavior and see. after rebuild, i can now get groom to complete successfully on a few of my media sets. here are some performance numbers: mediaset A: ~13M files. 1.5TB. catalog size: ~22GB. FW800 drobo storage (slow) mediaset B: ~4M files. 1TB. catalog size: 7.5GB. separate FW800-connected single hard drive. mediaset C: ~13M files. 3TB. catalog size: 53GB. iscsi drobopro storage (somewhat fast). results for mediaset A: groom took 21.5hrs - "success" (but see note below) rebuild took 19:02* results for mediaset B: groom took: (can't find the number here, but i think it was ~8-10hrs - i will edit this next time i groom this set) rebuild took 7:18* results for mediaset C: groom took: <not yet attempted> rebuild took 18:44 results marked with * above were done on a slower CPU with less memory so are not directly comparable. "*" indicates ops done on core2duo 6GB ram. no "*" indicates ops done on quad-core i7 with 16GB of ram. all groom operations above are "groom to retrospect defined policy", which (perhaps stupidly/stubbornly) i am still continue to try to get to work -- for some definition of "work". here's a big question: after full rebuild, followed by a lengthy groom (on mediaset A above) logs indicated that a successful groom had completed. a total of 1.6GB was groomed (about .1% of the total size of the mediaset). WTF!? (so in about 78000 cpu-intensive wall-clock seconds, i freed up 1.6 GB - roughly dial-up modem speed - not good). the real question or issue is: how is this supposed to work? when i initiate a groom, i don't get to tell retrospect how much it should try to cull from the media set - so does it have some default target, e.g. 10%? apparently not based on the results above. does it merely figure out the minimum amount of stuff it needs to cull to fit the existing space? well that might make sense for an "in-line" groom operation (my term), where retrospect knows (maybe) how much it wants to add to the mediaset as part of the current backup operation, but that can't be the way a manual groom works, since obviously there was enough space before, there's going to be enough space afterwards, even if nothing gets culled. does a manual groom merely cull snapshots on a schedule basis and then delete whatever files from the mediaset that may no longer be accessed from snapshots? this seems to match the data. here's the retrospect (v8) manual on the topic: "When the backup drive fills up, or when you run a scripted or manual groom operation, Retrospect uses its own grooming policy to delete old backups. At a minimum, Retrospect’s policy retains two backups for each source, saving the last backup of the day for each source from the two most recent days on which each source was backed up. Given enough space in the Media Set, Retrospect keeps a backup of each source for every day in the last week, a backup for each week in the last month, and a backup for each previous month." so i think this means that if i am using groom to retrospect-defined policy (GtRDP), that a manual groom may generally accomplish little or nothing in terms of recovering space. it allows me to assess performance and confirms the health of my media sets, but is otherwise mostly useless. the only way using GtRDP can accomplish anything useful is if it invoked in-line with a backup. so for example, i'm trying to backup a user's machine over a network, and if one of them happens to be the unlucky one, their backup will trigger an inline groom, which may take 10+ hours to complete, after which their backup will finish if they've bothered to stay connected for that long. and at the end of this process, enough stuff will have been deleted from the mediaset to fit the new backup, but there's no guaranty that the next user to come along won't have the same experience. in other words, GtRDP, unless i'm missing something GtRDP is really not useful for what i am trying to accomplish. it does not provide basic TimeMachine-like behavior of a simple "rolling backup set", or at least it does it so slowly as to be non-useful from an operational perspective.
  5. davidduff

    New Forum for Retrospect 10?

    agree completely. past history shows that v10 issues will get reported and questions asked in this forum. then eventually/inevitably a separate retro10 forum will be opened up and past inputs/questions will be orphaned in the old forum. i hate to complain (not really ) but dantz/emc/roxio/retrospect has a bad track record in this regard. with no user manual for for v9 or v10, i think retrospect inc needs to foster and respect user-driven forums like this. honestly, there's no way a normal user can muddle through all the issues, warts, complexities, bugs, performance problems, etc. associated with retrospect w/o this forum.
  6. i'm confused. george76, we have a mac (A) and a windows box ( B ). to which machine is the storage actually attached? which machine is running the retrospect engine? it sounds to me like you are saying that the storage is attached to B but is accessed over the network from A via SMB protocol. retrospect is running on A and you want to use the storage on B for backups. lennart, is this your understanding? if my understanding is correct, i don't see what retrospect client has to do with this... you first add a network source (in retrospect's confusing terminology) either by browsing for it or by using the "add source directly..." button. i've done this for mac (afp) network shares, but have not had occasion recently to try it with windows (smb), but i think it works the same. once added, retrospect sees the remote volume and the interface treats it pretty much the same as any other (attached) drive. that is, it can be used as a backup destination either by creating a new mediaset or adding new member(s) to an existing media set that resides on that drive. i think it is easy to get confused by the requirement that the drive be added as a source. intuitively, adding it as a "source" implies that you are going to back it up rather than that you are going use it for storing a backup (i.e. a media set). that intuition is reenforced by the fact that all of the other drives and clients that you backup appear in the list of sources. however that's not how retrospect uses the term. to retrospect a "source" is just a volume that can be something you backup or something you use to store a backup.
  7. thanks for the input. very interesting, mastercam and maser. when you get a chance, here are some additional details that would be useful: do the details you provide above related to retrospect 9 or 10? (i assume 9) have you had a chance to test retrospect 10 yet? if so, have you noticed any changes? i.e., any have you seen any improvements to performance (specifically wrt grooming) under v10? anything interesting to report about your system config? what type of high-volume storage are you using for your media sets? for your catalog? are you using SSD or RAID? you mention size of your media sets in terms of bytes. what about # of files? regarding "grooming has been fine"... can you elaborate? are you using "groom to retrospect defined policy" or are you using grooming to keep around a fixed number of backups for each source? do you let grooming happen "on demand" or do you invoke it as a separate operation? how long do grooming ops take to complete?
  8. catalog file was on separate disk. disk space was not an issue on the drive containing the catalog file. i have done a full rebuild. media set is functional again. i notice last few backups show "using instant scan" in the logs. i don't see evidence in the logs that an (auto-)groom has taken place since the rebuild. i'll initiate one manually and see how it goes.
  9. davidduff

    how to stop a groom operation

    moving the catalog accomplished what i needed in this case. thanks for the suggestion.
  10. need help! i have a groom operation that's causing my retroengine to crash. when the engine restarts, it tries to continue on the grooming task and it crashes again. i tried stopping the task, but that did not work. so now essentially i'm stuck. anytime the server is running, it keeps trying to execute that groom task. i'm pretty sure that i need to do a full rebuild on the media set in question. is there something i can do to break this infinite crash loop and force the groom task to stop?
  11. ok - thanks. i eventually reached that conclusion myself "the hard way" - i.e., everything else i tried failed badly. fyi, i tried doing a repair on the media set a couple of times and it crashed the engine and the console. not good. also, for my own understanding, in the case where a catalog is corrupt, shouldn't repair do essentially the same as rebuild? if not, why not? and why should repair crash both engine and console?
  12. i'm seeing assertion failures from retrospect engine. oddly, they are happening at 5 minute intervals. they seem to be related to an instability i observed with client communications (reported under a separate thread). "Assertion failure at "grx.cpp-1089", on threadID <hexID>"
  13. davidduff

    retrosect10: console instability

    well, it looks like i misread the situation, and thus the title of this post is misleading. my engine is crashing every five minutes. i don't know the actual root cause, but it seems likely that whatever the problem is, it is likely that is not the fault of the console or engine-console comms as i incorrectly assumed. refer to a separate forum thread i've opened under the heading "retrospect10: retroengine assertion failure at grx.cpp-1098".
  14. i'm running retro v10 console on my server, connected to the local retro engine and roughly every 5 mins, the console "blanks out", acting as though it has just restarted itself. it jumps up to the top level default display. from the log view within the retro console app, it appears that this is happening every 5 mins give or take a few seconds, with occasional "skips" where the interval is roughly 10 mins. in the console log view, i also see one odd msg of the form: "StucOpen: IOCreatePlugInInterfaceForService(kIOMMCDeviceUserClientTypeID) (error -536870210)". also, i had been away for a while and came back to the machine to find the console app had crashed. i have the crashdump and can post if it is useful. in this situation i'm running the latest retrospect v10 console and engine (installed ~4 days ago). the retro engine is running locally on the same box as the retro console. my system is running mac os x 10.6.8 server. in the system console on the machine, i see bunches of msgs at 5 minute intervals of the form "Server::updateScriptsCache exception: MacRequestor::Request: connection closed by remote endpoint" or " and other similar msgs involving updateSetsChangeCounter, updateSelectorsCache, etc. i'll post these log records as an attachment - it actually looks like there might be a lot of different things going on there that don't look familiar, including some scary-looking assertion failures - hmmm... RetroEngine or Retrospect.txt
  15. it appears to me that my retroengine process is dying each time the above message is written to the logs. i didn't realize it at first, because one of the running activities (a groom operation) seems to survive the engine crashes. so this is a more serious problem than i originally thought.
  16. the process of doing a rebuild is awkward in several ways and has been so through versions 8, 9, and now 10 of retrospect. some observations: under the media sets view in the retrospect client, there are a set of icons in the toolbar. some of them apply to the selected item in the list. others are just general actions that you can perform independent of the selection. even as an experienced user, i find this slightly confusing and it sometimes throws off my expectation of how things will work. if my understanding is correct, {add, locate, rebuild} are independent of selection while {remove, copy, verify, unlock, and repair} are not. i don't really have a problem with add/remove. they are pretty understandable and use clear icons that follow a somewhat standard UI pattern. "locate" actually means to find a catalog file that exists on disk but does not exist in the list and add it to the list. in my most common use of this, however, i point at a media set in the list that can't find its catalog and then click "locate" to fix it, so it feels like it is an operation on the selected item even though it is not. perhaps this doesn't matter. "rebuild" suffers from the same issue. it feels intuitively like "rebuild" is an operation you apply to an existing media set. in fact, when you select "rebuild" (from disk), you are starting from scratch each time, specifying a set of member folders. ask yourself: is the user supposed to intuitively grock that "repair" is an operation on the selected media set while "rebuild" is not? "rebuild" is non-optimal in several ways: first, in the years i have been using retrospect, by far the most common scenario where i'm using rebuild is to simply reconstruct the catalog of an existing media set with the same set of members. thus, forcing me to locate the directory for each member is an unnecessary step and it introduces the possibility of potentially damaging user error. second, the dialog for selecting members to use in a rebuild has several problems. once you have located a member folder, there is an extra step after you have identified the member folder where you are asked to select an identified member from a list. in my experience, there is only ever one item in this list. so i have to manually select this item, then click "next" or whatever the button says. this is a modal window that pops up on top of an other modal window - not ideal from an interface standpoint in terms of making the process intuitive. also, it seems to me that in the (common) case of there being only one candidate member in the directory that i select, the program should just skip this unnecessary "choose from a list of one item" step and go directly back to the higher-level window where i can add another member or proceed with rebuild. third, after hitting the button on the aforementioned sub-dialog in the rebuild process, there is (at least potentially) a very long delay. beachball spins, the program becomes unresponsive. the program doesn't give any indication of what it is doing. this is bad. i think there are two possible improvements here. either take my input and save whatever "work" needs to be done based on those inputs for the end of the process or at least put up some indicator of what's happening - for example, if this process is enumerating files in the directory and processing them, then put up some kind of progress indicator that shows this. merely spinning the beachball and freezing the interface is annoying and makes it impossible to tell the whether the program is completely hosed vs. when it is just working on a very big task. fourth, in the years i have been using retrospect, by far the most common scenario where i'm using rebuild is to simply overwrite the existing catalog file. thus, forcing me to locate the directory to save the catalog is an unnecessary step and introduces the possibility of potentially damaging user error. it is extra-annoying because (for reasons i understand) this is not a standard mac file dialog. a suggestion: at least add a button in this dialog for "use default catalog folder". fifth, building on the first and fourth points above, i argue that there should be something like a "rebuild in-place" operation. unlike normal rebuild, this operation would use the selected media set. the "select members" part of the process could be skipped, since the user is requesting that you just use the existing set of member directories associated with the media set. similarly the "select catalog location" part of the process can be skipped - you just assume you will overwrite the existing catalog file. if this operation existed, it would be a time saver for me. i gather that this may be what the "repair" operation is possibly supposed to do - i.e., it looks at the media set and the catalog and if it determines that the catalog is messed up somehow and needs to be rebuilt, it does essentially the kind of "rebuild in place" operation i describe above. if the catalog only needs minor repairs, it does something else (not sure i understand the details there). so "rebuild" is the right idea, in my opinion. however, i have encountered numerous situations where rebuild completes quickly (and thus obviously decides that a full rebuild is not necessary), however certain operations (like grooming) don't work, but if i manually/tediously go through a full rebuild, it works. thus, while rebuild seems like the right concept, there's something lacking there. perhaps holding option key down could invoke a "force repair" or something?
  17. retrospect engine process in a new V10 upgrade is generating multiple pairs of log lines per second of the form: TVol::GetInfo: UGetVolumeInformation failed, /private/var/folders/Sw/blahblahblah MapError: unknown Mac error 22. i reported this some time back (under either v8 or v9). iirc, i was told that these are not a sign of anything wrong and can be ignored. even so, i consider it a significant bug and i'm not happy that a previously reported problem survived into v10. i don't like my log files getting spammed like this - for several reasons.
  18. in the end, grooming took 25:42:57. it ended in failure. the only message that was visible in the activities window was "execution incomplete" with a little red "x" next to it. if i click on the Log tab in the activities window, nothing at all is displayed. btw, i think this (not showing anything in the log tab) is a bug. if i click on the view menu in the retrospect app and select Log (apple-L), then i see that grooming failed with error -2242 "catalog file duplicated or ambiguous". it says i need to recreate the backup set's catalog file (i think this is strange wording for what the UI refers to as "rebuild"). so i'll do a rebuild (which will take 10-15 hrs), then i'll retry grooming again. but so far, this doesn't feel like any kind of big improvement - in either functionality or performance - in version 10 vs. earlier versions.
  19. in the above article, it does not mention how volume names with spaces should be handled. in fact, the article side-steps the issue by using an example volume name of "MacintoshHD", whereas a standard default root volume on macs is "Macintosh HD". so in this case, would you say: ExcludedVolumeName0=/Volumes/Macintosh HD/ or ExcludedVolumeName0=/Volumes/Macintosh\ HD/ or something else? UPDATE: sorry - i could have just tested this before posting - the correct answer is: spaces in the volume name seem to work fine w/o any form of special quoting or escaping needed.
  20. one further note: i complained earlier that grooming doesn't display progress indicator. this was certainly true in v8 and v9. as of now in version 10, retrospect is displaying "grooming segment 1835 of 2209" in the status window. so at least that's something. otoh, the progress bar underneath is a static candy cane pattern. no movement and it does not track progress through the segments, even if movement through segments does not track exactly with grooming progress, at least it would be better than nothing to have it progress from start to finish by tracking segments completed. also the "grooming segment k out of m" message goes away sometimes (replaced by some other message such as "analyzing catalog data" or something), so if you look at the status at any point in time, you may or may not be able to tell how far along it is. if i click on the "log" tab (vs. the "summary tab") looking at the grooming activity, it shows nothing. it doesn't even show the time the operation started! from past experience, even after completion, there will be nothing logged. it seems to me like more detailed logging would definitely help here. how many bytes/segments/files or whatever got processed? what was the rate in files/bytes/segments or whatever per second in each major phase of the operation? logging something like that might help me identify where my bottleneck is. by linear extrapolation (which may be wildly inaccurate, i realize), it looks like i'm getting it is processing a bit under 100 segments per hour, and thus will probably end up taking an entire day of wall-clock time to complete grooming of this modest media set. and that's assuming that processing my 2209 segments represents the bulk of the grooming operation and is not merely a first of several passes or something.
  21. i actually have a replacement machine with quad-core i7 standing by waiting to replace this machine, but i thought i would try head-to-head comparison of v10 vs. v9 on the same hardware while i had a chance to do so. as of now the groom op that i started yesterday has run for 20 hrs. it has consumed about 17 hours of cpu time (that's the time used by RetroEngine process and this has been the only job running since i installed v10 yesterday). the media set in question is only 1TB in size. i say "only" - i realize 1TB is a lot of data. but the laptops i'm backing up have 500GB or 750GB drives now, usually over half full. so by my standards, i don't have the feeling that a 1TB media set is large. on the contrary, i would have thought that 10TB media sets and up would be common for users who are backing up machines for small/medium businesses. if i were not facing these horrendous performance problems with retrospect (and i had confidence in its reliability), i would probably dedicate 4-6TB of storage to it. so that's what i mean when i say only 1TB. one thing i should add - as of today, the RetroEngine process is competing for resources with the new RetroISA process on my backup server. i believe RetroISA scanned all the drives attached to my server and is continually re-scanning them looking for changed files. so while RetroEngine has consumed ~17hrs, RetroISA has consumed ~10 cpu hrs. i think i need to look into making some mods to the RetroISA config file to exclude certain of my disks from scanning -- however this seems like a questionable design - it looks like going from v9 to v10, we replaced the slow/inefficient on-demand scanning process with a different highly inefficient process of continuous scanning. isn't there a better way? as a sanity check, i'll float these questions out there: - how many machines are people backing up with retrospect server? any small/medium businesses out there backing up ten or more? - how large are your media sets? - is anyone really using retrospect grooming in any serious sustainable workflows? if so, how? how does it perform? what is your hardware setup like? - anyone know what the limiting factor is on grooming performance? RAM? speed of access to catalog file? speed of access to member file system? mysteriously, when grooming, my machine seems to use a ton of CPU, but (oddly) does not seem to do a ton of disk i/o. what is grooming actually doing? is there some general rule of thumb regarding how long grooming should take? am i seeing some kind of unforeseen resource contention or something? bad interaction with some other Mac OS X process (such as spotlight)? some strange quirk of mac os x server? would Retrospect benefit from more RAM if it were available? some further thoughts on grooming... it has been a slow process getting to the meat of this issue - going back to early versions of retrospect 8. for a long time, i assumed the problem was just due to the idiosyncrasies of my own system: somewhat old non-server-grade hardware plus i was using Drobo's for my backup storage. i didn't want to blame retrospect for known Drobo performance problems. then for a while after that, i wondered if i was trying to use Retrospect in some crazy or unreasonable way - such as letting my media sets grown outside retrospect's design limits. however, in the case i describe above, the media set is what i think would be considered at most "medium sized" by reasonable objective standards. the mediaset is stored on a regular firewire hard drive (not Drobo) and the catalog file is stored on the internal SATA system drive. this is a freshly installed version of retrospect v10 which i installed based on the marketing claim of "IMPROVED! Automatic Disk Grooming". i know that there are others who are using retrospect in different ways - for example, forgoing the use of grooming and doing frequent/regular rotation of backup sets. if people are able to get what they need from retrospect this way, that is great for them. this is not particularly interesting to me as a solution. on rare cases, i want expect retrospect to be able to reach back into a past state of my machine to recover some data. constant media set rotation essentially defeats this abiltily. without this ability, it feels that i might as well just fall back to using simplistic disk imaging-type software for backup. i welcome any further discussion of grooming. if you are using it and not having probelms, please tell me. maybe i can figure out why it performs so badly on my system.
  22. another followup regarding the 10.7 machine. searching logs for "retroisa", i was seeing pairs of log lines like the following: 11/8/12 4:05:18.414 AM com.retrospect.retroisa: #3> ~TMonitor::Enter: couldn't lock pthread_mutex: 60, result 22 11/8/12 4:05:18.414 AM com.retrospect.retroisa: Assertion failure at "tmonitor_unix.cpp-95", on threadID 0x106607000 i restarted this machine and things seem possibly more healthy now. no more of the above log lines have appeared. RetroISA process is using some CPU, but it's only been a few minutes... so far, there is one (small) pair of files in /Library/.../RetroISAScans. so i'm hoping things are back to normal. another followup on the 10.6.8 (server) machine that i mentioned that also has a RetroISA process eating a lot of cpu... it appears from the logs that the initial scans of the attached volumes within about 15 minutes after installation of the new version of retrospect. however, there seems to be a lot of work being done on periodic updates for all the attached volumes.
  23. the process ran another 4+ hours and was still going at 200% cpu utilization. i killed it. looked in /Library/Application Support/Retrospect/ and RetroISAScans dir was no longer there, so i guess it went away when i killed the process. now the process is running again, but is using almost no CPU. the RetroISAScans dir has come back. files in it are small. so i'm not sure what this means... the scanner is no longer using a lot of CPU. otoh, it doesn't seem to have scanned my machine, either. for the record, this machine is running 10.7.5. i just looked at another machine on my local network (the machine running retrospect server) and i see that the RetroISA process is still running there also. it is competing for CPU with other processes (including RetroEngine). it has 5:20:00 of cumulative cpu time. this machine is running mac os x 10.6.8 server. it has some other drives attached - does RetroISA scan those drives as well? looking in /Library/.../RetroISAScans on that machine, i see a set of pairs of files (.dat, .inf) with different names, so i'm going to assume that those correspond to the various drives attached to my server and that the large runtime is warranted in this case.
  24. i know performance numbers (even crude ones) are meaningless w/o more context... the above is on an intel 2.4GHz core2 duo processor. it has only 6GB of ram but does not appear to be doing a lot of paging. the media set is on an external firewire drive. catalog is on the system (SATA) drive. mac os x 10.6.8 server i'm using "groom to retrospect defined policy" option on the backup set in question.
  25. not sure whether this is normal. i installed the new v10 client on my macbook pro. it is running steadily at 200% cpu utilization. it's been a bit over 4hrs since i installed. it has used 8hrs 37mins of cpu time. still going. this is a "normal" (to me, at least) laptop system with about 285GB of "normal" stuff on it. photos, music, apps, documents, etc. is it normal/expected for it to take this long (both wall-clock time and cumulative cpu time)? the two files in /Library/Application Support/Retrospect/RetroISAScans are both very small. the process memory footprint is also small. so i don't understand what it's doing. $ ls -lh /Library/Application\ Support/Retrospect/RetroISAScans total 16 -rwxr-xr-x 1 root admin 3.6K Nov 7 17:29 RetroISAScan-C49787A2-75B7-394B-A388-D4C5C9C96083.dat -rwxr-xr-x 1 root admin 256B Nov 7 17:29 RetroISAScan-C49787A2-75B7-394B-A388-D4C5C9C96083.inf
×