the restore program to restore all dumped extended attributes.
If the restore is running as root, it will always be able
to restore all extended attributes. If it is not running
as root, it makes a best effort to set them. Using the -v
command line flag or the `verbose' command in interactive
mode will display all the extended attributes being set on
files (and at the end on directories) that are being restored.
It will note any extended attributes that could not be set.
The extended attributes are placed on the dump image immediately
following each file's data. Older versions of restore can work
with the newer dump images. Old versions of restore will
correctly restore the file data and then (silently) skip
over the extended attribute data and proceed to the next file.
This resolves PR 93085 which will be closed once the code
has been MFC'ed.
Note that this code will not compile until these header
files have been updated: <protocols/dumprestore.h> and
<sys/extattr.h>.
PR: bin/93085
Comments from: Poul-Henning Kamp and Robert Watson
MFC after: 3 weeks
unlinked as soon as the dump starts (and removed when the dump is
completed, and the dump process exits). Previous wording was confusing
because users might expect the snapshot to be visible in the .snap
subdirectory while dump is running.
MFC after: 1 week
output to setproctitle(3) in order to get rid of the ugly two-character
escape sequence "\n" in the ps(1) output of a dump(8) process:
<< [...] finished in 0:00 at Sat Aug 5 14:44:39 2006\n (dump)
>> [...] finished in 0:00 at Sat Aug 5 14:44:39 2006 (dump)
to match the number of inodes on the disk. If we find a directory
entry with a crazy inode number in it, don't look beyond the end
of the bitmap to find that inode's state. Instead skip that directory
entry and print a warning.
Reviewed by: iedowse
MFC after: 3 weeks
with a signal handler. This fixes a race condition introduced by
compiler reordering that caused dump to sometimes get stuck,
especially while dumping large filesystems.
generate snapshots in when -L is requested. If the .snap directory
does not exist, or is not a directory, issue a warning and revert
to the non- live behavior.
Obtained from: St. Bernard Software RAPID
Print the ETA of dump being finished, rather than a cryptic delta
time. Also, if we have written more blocks than the tapesize, assume
that we are 99.99% done and that we'll be finished 'soon'.
use backup methods other than files and tapes. The -P argument is
a normal sh(1) pipeline with either $DUMP_VOLUME or $RESTORE_VOLUME
defined in the environment, respectively.
For example, I can back up my home to three DVD+R[W]s as so:
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/ad0s2e 40028550 10093140 26733126 27% /home
green# dump -0 -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0' /home
in the .snap directory in the root of the filesystem being dumped.
Document that if the .snap directory is missing that it must be
created manually and that it should be owned by user root and
group operator and set to mode 770 before a live dump can be run.
of trying to directly create the snapshot itself. This change allows
users logged into the system as operator to run live dumps.
Note that dump no longer tries to create the snapshot in the root of
the filesystem, but rather in a .snap directory in the root of the
filesystem. The reason is that the operator is usually not permitted
to write into the root of the filesystem. The newfs command and
background fsck have both been modified to create a .snap directory
in the root of the filesystem, but if neither of these have been run,
then the .snap directory must be created manually by the superuser
before a live dump can be run. The .snap directory should be owned
by user root and group operator and set to mode 770.
- using (intmax_t) and %j
- giving a non-empty format string to msg()
Include <stdint.h> directly instead of depending on <inttypes.h>
to do it.
Tested by: make universe
has been called, since it points to a shared inode buffer that may
be overwritten. The two cases where `dp' was used incorrectly appear
to have been overlooked when "nodump" inheritance was first added
in revision 1.12.
This is reported to correct propagation of the nodump flag on
directories that are larger than one block in size.
PR: bin/58912
Submitted by: Volker Paepcke <vpaepcke@incore.de>
MFC after: 1 week
1024-byte boundaries. For many years this was a reasonable
assumption. However, in recent years we have begun seeing
devices with 2048-byte sectors. These devices return errors
when dump tries to read starting in the middle of a sector
or when it tries to read only the first half of a sector.
Rather than change the native block size used by dump (and
thus create an incompatible dump format), this fix checks
for transfer requests that start and/or end on a non-sector
boundary. When such a read is detected, the new code reads
the entire sector and copies out just the part that dump
needs.
Reviewed by: Poul-Henning Kamp <phk@critter.freebsd.dk>
Approved by: re (John Baldwin <jhb@FreeBSD.org>)
Sponsored by: DARPA & NAI Labs.
