backups/dumps/caches

backups/dumps/caches

[Richard Bonomo]

Hello!

I have been trying to come up to speed on
the issue of dumping file systems from
2.4.x kernels using dumps.  I located 
Linus' unequivocal words about the dangers
of using dump.   I have a couple of questions:

1. Do the same warnings apply to XFS and xfsdump?
   (Is the caching system used with the newer
    kernel used only with certain file system types?)

2. Perhaps, naively, is it possible to shut off
  caching temporarily (and without rebooting),
  accepting the performance hit, while a dump
  is done, and then restart caching afterwards?

Please cc a reply directly to me (bonomo@sal.wisc.edu),
as I am not a regular member of this list (at least,
not yet...)

Thank you!

Richard B.

-- 
************************************************
Richard Bonomo
UW Space Astronomy Laboratory
ph: (608) 263-4683 telefacsimile: (608) 263-0361
SAL-related email: bonomo@sal.wisc.edu
all other email: bonomo@ece.wisc.edu
web page URL: http://www.cae.wisc.edu/~bonomo
************************************************

Re: backups/dumps/caches

[Oliver Xymoron]

On Mon, 5 Aug 2002, Richard Bonomo wrote:

> Hello!
>
> I have been trying to come up to speed on
> the issue of dumping file systems from
> 2.4.x kernels using dumps.  I located
> Linus' unequivocal words about the dangers
> of using dump.   I have a couple of questions:
>
> 1. Do the same warnings apply to XFS and xfsdump?
>    (Is the caching system used with the newer
>     kernel used only with certain file system types?)

The essential problem with dump is that the current state of a filesystem
is a combination of what's in memory and what's on disk. With a journalled
filesystem, what's on disk at any given moment is self-consistent
(ignoring various levels of journalling). But dump can't see the whole
of the disk at any given moment, so it has no way of telling whether piece
A it read one second is consistent with piece B it read on the next.

There's no way to make this work cleanly short of snapshots (which 2.4 LVM
has), and the hacks to make dump mostly work (which is the best it can
ever possibly hope for on a live filesystem) were getting in the way of
doing other things right, so the dump approach of going under the
filesystem to the block device was officially declared stupid.

> 2. Perhaps, naively, is it possible to shut off
>   caching temporarily (and without rebooting),
>   accepting the performance hit, while a dump
>   is done, and then restart caching afterwards?

Yep. Switch to single user mode, sync all filesystems, unmount them for
good measure, dump, then switch back to multiuser mode.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: backups/dumps/caches

[Alan Cox]

On Tue, 2002-08-06 at 21:54, Oliver Xymoron wrote:
> > 2. Perhaps, naively, is it possible to shut off
> >   caching temporarily (and without rebooting),
> >   accepting the performance hit, while a dump
> >   is done, and then restart caching afterwards?
> 
> Yep. Switch to single user mode, sync all filesystems, unmount them for
> good measure, dump, then switch back to multiuser mode.

If you are using 2.4.19 then the actual bug dump hits is sorted. Dumping
a live fs still will mean you end up restoring a not 100% consistent
state of one file versus another and of file data for a given file. You
have to weigh that against downtime. In most cases the downtime isnt
worth it for having a few files that are logged in a transient state.

Re: backups/dumps/caches

[Nathan Scott]

On Mon, Aug 05, 2002 at 07:32:34PM -0500, Richard Bonomo wrote:
> 
> Hello!
> 
> I have been trying to come up to speed on
> the issue of dumping file systems from
> 2.4.x kernels using dumps.  I located 
> Linus' unequivocal words about the dangers
> of using dump.   I have a couple of questions:
> 
> 1. Do the same warnings apply to XFS and xfsdump?

xfsdump doesn't directly access the device, so the metadata
and data it sees is coherent with other filesystem activity;
so, no these warnings are not applicable to xfsdump.

cheers.

-- 
Nathan