On Thu, Aug 24, 2017 at 11:52:26PM +1000, Alexander Zangerl wrote: > On Mon, 17 Jul 2017 20:55:04 -0700, Elliott Mitchell writes: > >I should mention a reasonable alternative method. > > i'm not sure i'd want to go to a dir tree for this; if > one just wants to handle level 0 backups then my understanding > is that the restoresymtable could be skipped completely. > > there's no code for such a skip at this time, but i suspect that > that would be a cheap remedy - at least for full backups.
That would be mode -x or -X which extracts files, rather than than attempting to do a full restore. That certainly has benefits if you're merely trying to retrieve copies of file from a dump. Since the original bug specifically mentioned "restore", implying mode -r that doesn't sound like an acceptable resolution (though possibly acceptable to the original reporter). > >I /think/ it should be reasonable to replace restoresymtable with a > >small directory tree. > > right now i don't see why the symtable cannot be dumped incrementally > instead of being held in memory. If the i-nodes in a dump can be *guaranteed* to be in-order then such should be possible. I'm guessing right now either hash table(s) or a tree is being used, since an old i-node number needs to be mapped to a new i-node number/file. If they're guaranteed in-order then that can be optimized to a list-type structure with a provision for skipping ahead quickly. I'm pretty sure e2dumpfs upholds this guarantee, but do *all* dump implementations uphold this guarantee? (ideally `restore` would be able to handle foreign dumps) Speaking of which, I'm inclined to suggest `dump` should have a -t option similar to the -t option of `mount`. Alas -t for `restore` has already been allocated for a behavior like `tar`'s -t behavior. -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | ehem+sig...@m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
