Photorec - not sure if stuck or still doing something

Question

Hi!
I'm trying to recover files from a ~8GB thumb drive (or sd cards? not sure.) image I dumped to disk a few years ago. Because I don't remember what exactly I was trying to rescue there, I started photorec with just about everything enabled (including brute force), set to the "fat32/fat16/ntfs" mode and selected - among other things - the "find deleted partition" mode on the whole image even though there's also a working partition on it (figured I'd try the whole / raw file first, partition later).
It's been running for ~2 days now @100% CPU (one core only) but barely takes up any RAM / Disk-IO at all. There are a hand full of "recup / inode" directories + recovered files in the recovery directory + xml files, but all of that has not changed since the very beginning. The tty still looks like this:
PhotoRec 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <[email protected]>
http://www.cgsecurity.org
Disk /home/user/Desktop/stick.raw.image - 7948 MB / 7580 MiB (RO)
Partition Start End Size in sectors
No partition 0 0 1 966 80 10 15523840 [Whole disk]
Stop
... and nothing is moving / changing.
Now... I'm not sure if it's still doing anything or if I should try to "Stop" / kill it. Also not sure if I can safely attach strace or gdb or something without disturbing the running process and loosing (potential) progress. No idea how photorec is supposed to look/act - and if this is normal.
So - is there anything I should be aware of before I decide how long I'll let it run (or stay frozen) like this?

Answer 1

Thanks!
Those change constantly:
< nonvoluntary_ctxt_switches: 8151747
> nonvoluntary_ctxt_switches: 8152751
everything else in io + status:
cat /proc/26077/io /proc/26077/status | grep -v nonvol >| /tmp/proc1 && while true; do; cat /proc/26077/io /proc/26077/status | grep -v nonvol >| /tmp/proc2 && date +%T; diff -s /tmp/proc? || cat /proc/26077/io /proc/26077/status | grep -v nonvol >| /tmp/proc1; sleep 60; done;
14:33:56
Files /tmp/proc1 and /tmp/proc2 are identical
.. has been identical for an hour or so unless I did something wrong with that oneliner.
Not sure what htop should tell me except that the process is using 4GB of ram. I've also been keeping an eye on conky for a while now - I think that photorec periodically stops using 100% of one core and starts using 10% of all 6 cores instead... but this forth and back could probably just be the kernel trying to optimize cpu usage depending on what else I do? Photorec leads my conky CPU top5 most of the time and also is holding its spot between firefox + Xorg in the top5 for memory usage.
According to iotop, the PID is - maybe - writing to disk very slowly ("actual disk write") (it "flickers" to ~200K/s every few seconds and then goes back to 0). No reading, also for some reason "total disk write" also stays at 0. I haven't seen photorec pop up in my (always visible) "top 5 IO" from conky since I started it (most of the time that's "sleep, sleep, another sleep and 2 kworkers" with a total of 0), so I might just be using iotop wrong here.
strace - when attached to the PID - says nothing at all (except for the debug output which I don't understand. Haven't used strace often except to monitor file access, maybe I'm doing it wrong).
sudo strace -ff -d -p 26077
new tcb for pid 26077, active tcbs:1
ptrace_setoptions = 0x1f
attach to pid 26077 succeeded
Process 26077 attached
[wait(0x80057f) = 26077] WIFSTOPPED,sig=SIGTRAP,EVENT_STOP (128)
pid 26077 has TCB_STARTUP, initializing it
^Ccleanup: looking at pid 26077
detach wait: event:128 sig:5
Process 26077 detached
dropped tcb for pid 26077, 0 remain
I don't know if that means:
(a) That it's definitely stuck
(b) That it's still doing some sort of bute-force / expensive algorithms on those 4GB of data it has in RAM - without (currently) finding anything useful though that could change any second (or never)?
Last edited by whoops (2015-04-02 13:37:14)