Bug#726731: #726731: dump: Huge RAM usage on restore

2017-08-24 Thread Elliott Mitchell
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

Bug#726731: #726731: dump: Huge RAM usage on restore

2017-08-24 Thread Alexander Zangerl
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

Bug#726731: #726731: dump: Huge RAM usage on restore

2017-07-17 Thread Elliott Mitchell
I should mention a reasonable alternative method. I /think/ it should be reasonable to replace restoresymtable with a small directory tree. The first level of directories corresponding to the first digit of a restored file, then inside each directory include a hard link to the new file. Say if

Bug#726731: #726731: dump: Huge RAM usage on restore

2017-06-29 Thread Elliott Mitchell
Perhaps there should be a caution about filesystems with large numbers of i-nodes. Notice the numbers provided are just under 330 bytes for every i-node. The current `restore` program no longer acts as the traditional 4.4BSD `restore` did. Instead of restoring a near-exact image of the