Re: estimating lazarus runtime
Udi Mottelo <[email protected]> Sat, 15 Mar 2008 19:05:46 +0200 (Jerusalem Standard Time)
| Newsgroups | gmane.comp.security.forensics.tct |
|---|---|
| Message-ID | <Pine.WNT.4.64.0803151826100.3232@y-3672d8fbe8874> |
On Fri, 14 Mar 2008, Jay Borkenhagen wrote:
> Hi,
>
> I'm new to this list, and to TCT.
>
> I'm following the instructions in
>
> http://www.fish2.com/tct/help-recovering-file
>
> and my 'bin/lazarus -h unrm_output' has been running now for 2 days.
> It has generated more than 500k files (and climbing) under the blocks
> directory processing the 7GB unrm_output file.
>
> Are there any ways to understand whether lazarus is creating
> meaningful files and will finish its work at some point (hopefully
> soon), or is there any way to estimate for when it will finish? I am
> not expecting any involved calculation based on my processor speed,
> etc, but for starters it would be useful for me to estimate the number
> of files lazarus will ultimately produce from this unrm_output file.
I had this problem, but I have no resolve. Unfortunately you
will see that the Load-Average will start climbing too. I
guess that the reason is that Lazarus use flat-directory
and every new file add new Inode. The program runs on table
which grows up more and more (500k Inodes in your case, yet!)
The solution that I got from this mailing-list is to run the
recover on XFS filesystem where the number of the Inodes is not
poison.
I had suggested that Lazarus will set the files in subdirectory
named like 093/432/ for files are names started with 093432...
it can reduce and split the dirs table in 1000*1000. Jay, if
you know Perl and change Lazarus I'll appreciate if you send the
patch here because Dan Farmer answered that he is not going to do
so, not now and not in the future. (:-(
Bye,
Udi
>
> Thanks!
>
> Jay B.
>
> --
> Jay Borkenhagen [email protected]
>