Re: [Dump-users] Unable to handle removed files via incremental dumps

[Delian K. <kr...@kr...>]

On Wednesday 04 February 2004 03:40, Florian Zumbiehl wrote:
> Dunno, UTSL - or maybe some developer will be able to help you out with
> that one?!
>
> But can't you use some separate filesystem for that mirror?

It is a separate filesystem. But I'm going to restore over it everytime,
since I'm going to use only level 1 dump|restore.

> BTW, how do you think should dump read blocks from the filesystem
> without context switches? The only thing dump does not use is the kerne=
l's
> filesystem code. The block device drivers and the block buffering
> mechanisms are just the same as with the kernel's filesystem driver.

Read the FAT(inode tables) from the block device, parse it and see which=20
inodes are changed.

>
> However, I don't know whether dump optimizes block device access by
> sorting requests or something.

This is not needed, the inode tables locations are well known and located
on adjacent blocks.

>
> Maybe you could provide some more detailled information on the problem
> you want to solve/the kind of data you have to backup?
>

It is quite simple. I've got an ext3 over lvm. The filesystem is 30GB,
13GB full. There are about 1 million inodes used on that filesystem.
The hard drive is ide. I've decided to perform the test before
writing back too You. Unfortunately, the test failed.=20

The dump processes were quite small 1-2 MB, restore took about 92 MB.
I've created the snapshot:
lvcreate -s -L1G -n snaphome /dev/vg1/home

I've created a fresh filesystem, mounted it, and cd to it's top level dir=
=2E

[root@smtp0 bkp]# cat /root/bin/tmp/dump.sh
#!/bin/sh

dump -0uf - /dev/vg1/snaphome |restore -ruf -
[root@smtp0 bkp]# time /root/bin/tmp/dump.sh
  DUMP: Date of this level 0 dump: Wed Feb  4 14:58:19 2004
  DUMP: Dumping /dev/vg1/snaphome (an unlisted file system) to standard o=
utput
  DUMP: Added inode 8 to exclude list (journal inode)
  DUMP: Added inode 7 to exclude list (resize inode)
  DUMP: Label: none
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 12540221 tape blocks.
  DUMP: Volume 1 started with block 1 at: Wed Feb  4 14:58:48 2004
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
  DUMP: 2.41% done at 289 kB/s, finished in 11:43
  DUMP: 4.48% done at 418 kB/s, finished in 7:57
  DUMP: 6.32% done at 480 kB/s, finished in 6:46
  DUMP: 8.07% done at 519 kB/s, finished in 6:09
  DUMP: 9.88% done at 551 kB/s, finished in 5:41
  DUMP: 11.59% done at 570 kB/s, finished in 5:23
  DUMP: 13.31% done at 586 kB/s, finished in 5:09
  DUMP: 15.05% done at 599 kB/s, finished in 4:56
  DUMP: 16.94% done at 615 kB/s, finished in 4:41
  DUMP: 18.72% done at 626 kB/s, finished in 4:31
  DUMP: 20.56% done at 636 kB/s, finished in 4:20
  DUMP: 22.40% done at 645 kB/s, finished in 4:11
  DUMP: 24.25% done at 654 kB/s, finished in 4:02
  DUMP: 26.22% done at 664 kB/s, finished in 3:52
  DUMP: 27.96% done at 668 kB/s, finished in 3:45
  DUMP: 29.85% done at 674 kB/s, finished in 3:37
  DUMP: 31.74% done at 680 kB/s, finished in 3:29
  DUMP: 33.67% done at 686 kB/s, finished in 3:21
  DUMP: 35.65% done at 693 kB/s, finished in 3:13
  DUMP: 37.67% done at 699 kB/s, finished in 3:06
  DUMP: 39.61% done at 704 kB/s, finished in 2:59
  DUMP: 41.51% done at 707 kB/s, finished in 2:52
  DUMP: 43.23% done at 708 kB/s, finished in 2:47
  DUMP: 45.72% done at 720 kB/s, finished in 2:37
  DUMP: 47.96% done at 728 kB/s, finished in 2:29
  DUMP: 49.86% done at 730 kB/s, finished in 2:23
  DUMP: 51.85% done at 734 kB/s, finished in 2:17
  DUMP: 53.74% done at 736 kB/s, finished in 2:11
  DUMP: 55.96% done at 742 kB/s, finished in 2:03
  DUMP: 57.90% done at 744 kB/s, finished in 1:58
  DUMP: 59.73% done at 745 kB/s, finished in 1:52
  DUMP: 61.65% done at 746 kB/s, finished in 1:47
  DUMP: 63.68% done at 749 kB/s, finished in 1:41
  DUMP: 65.53% done at 750 kB/s, finished in 1:36
  DUMP: 67.60% done at 753 kB/s, finished in 1:29
  DUMP: 69.53% done at 754 kB/s, finished in 1:24
  DUMP: 71.51% done at 756 kB/s, finished in 1:18
  DUMP: 73.49% done at 758 kB/s, finished in 1:13
  DUMP: 75.48% done at 759 kB/s, finished in 1:07
  DUMP: 77.40% done at 760 kB/s, finished in 1:02
  DUMP: 79.35% done at 762 kB/s, finished in 0:56
  DUMP: 81.28% done at 763 kB/s, finished in 0:51
  DUMP: 83.15% done at 763 kB/s, finished in 0:46
  DUMP: 85.14% done at 764 kB/s, finished in 0:40
  DUMP: 87.09% done at 765 kB/s, finished in 0:35
  DUMP: 89.14% done at 767 kB/s, finished in 0:29
  DUMP: 91.05% done at 768 kB/s, finished in 0:24
  DUMP: 92.96% done at 768 kB/s, finished in 0:19
  DUMP: 94.87% done at 769 kB/s, finished in 0:13
  DUMP: 96.85% done at 770 kB/s, finished in 0:08
  DUMP: 98.35% done at 767 kB/s, finished in 0:04
  DUMP: 99.82% done at 765 kB/s, finished in 0:00
  DUMP: 100.00% done at 762 kB/s, finished in 0:00
  DUMP: 100.00% done at 759 kB/s, finished in 0:00
  DUMP: 100.00% done at 756 kB/s, finished in 0:00
  DUMP: 100.00% done at 753 kB/s, finished in 0:00
  DUMP: 100.00% done at 751 kB/s, finished in 0:00
  DUMP: 100.00% done at 749 kB/s, finished in 0:00
  DUMP: 100.00% done at 746 kB/s, finished in 0:00
  DUMP: 100.00% done at 744 kB/s, finished in 0:00
  DUMP: Broken pipe
  DUMP: The ENTIRE dump is aborted.

real    324m1.259s
user    1m21.260s
sys     3m44.360s
[root@smtp0 bkp]#

I've tried the same on a smaller partition, it worked just fine.
The snapshot was NOT exausted and removed by the kernel. I've
removed it manually later. Btw as You could see, the times reported
by dump are not accurate, at least if it counts real time.

> PS: Could you please limit your quoting to the parts needed?

n.p.


p.s. Any ideas on this topic, Stelian ? ;))