🚀 go-pugleaf

Has anyone tried using "dd" for file system dumps?  Alternatively, does
anyone know of a way restore could be made to run at a reasonable speed?

The problem is this.  Our Sun disk needs are growing.  We'll soon have
about 1.5GB on one of our servers.  Dumping these takes a while; we could
probably improve this by bringing up 4.3BSD dump.

More worrying, though, is the speed of restore, which we found by painful
experience after a flurry of disk controller failures last spring to
average around 50 Kbytes/s -- on a 3/280, Ciprico controller and pretty
fast Fujitsu Swallow disks.  At that rate, even if all goes well, it'll
take a full 12 hours to reload a wrecked file server.

I suspect the far slower restore speed is because the file system code is
taking care to do directory and inode updates synchronously to ensure
consistency, a laudable feature but one I wish we could defeat at times
like that.

So it's tempting to switch to using "dd" rather than "dump" for dumps.
It would have some advantages...
  - dumps would be much faster, maybe 2-3x SunOS 3.3's dump
  - restores would be at least an order of magnitude faster
  - inode numbers would not be changed by a restore so NFS clients wouldn't
	need to be rebooted
but some disadvantages...
  - restoring individual files from a backup would be a pain, we'd need
	to keep a large free disk partition for the purpose
  - dumps would be somewhat larger, though since our file systems normally
	run close to full we probably wouldn't waste much
  - incrementals wouldn't work as well; we could use tar, sort of
	(but with full dumps being much faster we could do them more often)
  - they might be inconsistent when done on (even slightly) active file systems

Of course potential inconsistency is the most worrisome.  I've tried a
couple such dumps and found nothing which fsck won't fix routinely.

But can anyone suggest a reason why "dd" dumps should do much worse than
"dump" dumps on live file systems?  Should files which weren't changing
during the dump be affected?

	Stuart Levy, Minnesota Supercomputer Center
	slevy@uc.msc.umn.edu