Re: open archive per level

Tobias <[email protected]> Sun, 20 Oct 2013 23:24:02 +0200
Newsgroups gmane.comp.sysutils.backup.dar.libdar
Message-ID <1382304242.2709.41.camel@localhost>
I understand the problem.

1: I think memory shouldn't be the problem, so we could store the
uncompressed catalogue in memory.

2: This example is from your documentation of the Dar 5 archive format:
- toto
   | titi
   | tutu
   | tata
   |  | blup
   |  +---
   | boum
   | coucou
   +---

+-------+------+------+------+------+-----+------+--------+-----+
| toto  | titi | tutu | tata | blup | EOD | boum | coucou | EOD |
|       |      |      |      |      |     |      |        |     |
+-------+------+------+------+------+-----+------+--------+-----+

When parsing the filesystem tree, would it be possible to skip the
subdirectories when building up the catalogue in memory?
Based on the example. You want to list the content of toto. 
So you go toto, titi, tutu, tata. Now you are leaving the desired level
and your going to search for the next EOD to come back to the toto
level. So your only reading blup but don't add it to the struct in
memory.
Of course this is a really simple example. In reale world you have some
more subdirs and determining the point where your back on the desired
level will not that easy. 
But do you understand what I mean?
Shouldn't this boost up the process, because you don't have to add
hundreds of (in this moment uninteresting) inodes to the struct in
memory?

Ok, I admit when you want to build up the whole tree, this technique
costs more CPU cycles. But then I only want to extract one directory
from the archive I don't wont to wate over half a minute until the
catalogue is read.

Tobias

Am Sonntag, den 20.10.2013, 19:15 +0200 schrieb Denis Corbin:
> On 20/10/2013 15:06, Tobias wrote:
> > Hi,
> 
> Hello,
> 
> > 
> > i'm programming a graphical user interface for restoring Dar backups.
> 
> nice to hear about that :)
> 
> > 
> > To list the archive content I'm using the dynamic archive content
> > listing option like described in chapter 7 of your API tutorial.
> > Thank you for that, it's working really well. 
> > But it seams like the "read" constructor reads the whole catalogue.
> 
> Yes that's correct
> 
> > Is it possible to change that behavior in a way
> > that the catalogue gets read per level?
> 
> it would be difficult to be implemented that way, because:
> 1 - the catalogue is compressed as a whole (thus this per level read of
> a catalogue would imply uncompressing the same data several time to read
> further catalogue entries
> 2 - even without compression, to find the contents of a given directory
> would require a lot of work: the directory tree is stored using a
> "in-depth" tree order. In other words, at creation time when comes the
> time to write down the catalogue, when a subdirectory is found its whole
> contents is written down to the archive before proceeding to the next
> file or next subdirectory found at that level.
> 
> So its more efficient to build in memory the whole catalogue from the
> archive and then to extract by level the requested information from it.
> 
> > That would really boost the performance.
> 
> I don't think so. Even, if you just want to read the contents of one
> directory it would takes almost the same amount of time and will reduce
> memory requirement. But for the next directory reading you would have to
> do the same operation another time ... so globally I think this is
> faster the way it is actually implemented (with all the CPU cycle being
> done before being able to read any archive content).
> 
> > 
> > Kind regards
> > Tobias
> > 
> > 
> 
> Kind Regards,
> Denis.
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> _______________________________________________
> Dar-libdar_api mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dar-libdar_api



------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk