--On 24 February 2007 5:04:33 PM +0200 Leon Kolchinsky
<leonk@xxxxxxxxxxxxxxxxxxxxx> wrote:
(...)
> Yes it is meant to handle a changing filesystem - you do see warning
msgs sometimes because
> it can't see a particular inode anymore, which can happen as we do
multiple
> scans of the inodes and if they get deleted then it obviously can't do
anything
> with it anymore or if the inode is reused as a dir instead of a reg-file
etc...
Hmm,
I suppose he asked about something else:
Unless you use lvm snapshots (or something alike) you may get incorrect
files that are in use. Consider having 20GB file:
1. Dump starts reading the file
2. Dump is at 18th GB
3. You change the data in 1-5 GB region.
4. You have inconsistent data.
So after dump you get consistent filesystem but not necessairly
consistent data.
Yep, consistent FS is what I care about in the case of disaster.
I'm not sure I know exactly what you are getting at.
After the restore you should have a consistent FS because it is _not_
a low level filesystem dumper. It is mostly a high lever dump/restore
program and to the extent that it can generally restore to a foreign filesystem
e.g. ext2.
(For example, it does know about file extents but it only uses this info on
restore to
preserve holes by seeking and writing.)
So as it is just doing standard system calls on restore, it can't really
violate filesystem consistency.
Now, when I've tried to make non-interactive xfsdump I'vo got > prompt with
no action, like this
# xfsdump -f /data/backup2.file -L 'session1' -M 'media1" /
Presumably quoting problem as Donald pointed out - it definitely works otherwise
without extra input.
--Tim
|