2005-12-22 07:34:49 +00:00
|
|
|
=head1 NAME
|
|
|
|
|
|
|
|
|
|
voldump - Dump an AFS volume without using the Volume Server
|
|
|
|
|
|
|
|
|
|
=head1 SYNOPSIS
|
|
|
|
|
|
2006-03-01 05:02:29 +00:00
|
|
|
=for html
|
|
|
|
|
<div class="synopsis">
|
2005-12-22 07:34:49 +00:00
|
|
|
|
2006-03-01 05:02:29 +00:00
|
|
|
B<voldump> S<<< B<-part> <I<partition>> >>> S<<< B<-volumeid> <I<volume id>> >>>
|
2013-06-14 22:03:40 +01:00
|
|
|
S<<< [B<-file> <I<dump file>>] >>> [B<-time> <I<dump from time>>]
|
volser: Don't NUL-pad failed pread()s in dumps
Currently, the volserver SAFSVolDump RPC and the 'voldump' utility
handle short reads from pread() for vnode payloads by padding the
missing data with NUL bytes. That is, if we request 4k of data for our
pread() call, and we only get back 1k of data, we'll write 1k of data
to the volume dump stream followed by 3k of NUL bytes, and log
messages like this:
1 Volser: DumpFile: Error reading inode 1234 for vnode 5678
1 Volser: DumpFile: Null padding file: 3072 bytes at offset 40960
This can happen if we hit EOF on the underlying file sooner than
expected, or if the OS just responds with fewer bytes than requested
for any reason.
The same code path tries to do the same NUL-padding if pread() returns
an error (for example, EIO), padding the entire e.g. 4k block with
NULs. However, in this case, the "padding" code often doesn't work as
intended, because we compare 'n' (set to -1) with 'howMany' (set to 4k
in this example), like so:
if (n < howMany)
Here, 'n' is signed (ssize_t), and 'howMany' is unsigned (size_t), and
so compilers will promote 'n' to the unsigned type, causing this
conditional to fail when n is -1. As a result, all of the relevant log
messages are skipped, and the data in the dumpstream gets corrupted
(we skip a block of data, and our 'howFar' offset goes back by 1). So
this can result in rare silent data corruption in volume dumps, which
can occur during volume releases, moves, etc.
To fix all of this, remove this bizarre NUL-padding behavior in the
volserver. Instead:
- For actual errors from pread(), return an error, like we do for I/O
errors in most other code paths.
- For short reads, just write out the amount of data we actually read,
and keep going.
- For premature EOF, treat it like a pread() error, but log a slightly
different message.
For the 'voldump' utility, the padding behavior can make sense if a
user is trying to recover volume data offline in a disaster recovery
scenario. So for voldump, add a new switch (-pad-errors) to enable the
padding behavior, but change the default behavior to bail out on
errors.
Change-Id: Ibd6e76c5ea0dea95e3354d9b34536296f81b4f67
Reviewed-on: https://gerrit.openafs.org/14255
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
2020-06-23 04:54:52 +01:00
|
|
|
[B<-pad-errors>] [B<-verbose>] [B<-help>]
|
2006-03-01 05:02:29 +00:00
|
|
|
|
|
|
|
|
B<voldump> S<<< B<-p> <I<partition>> >>> S<<< B<-vo> <I<volume id>> >>>
|
2013-06-14 22:03:40 +01:00
|
|
|
S<<< [B<-f> <I<dump file>>] >>> [B<-time> <I<dump from time>>]
|
|
|
|
|
[B<-ve>] [B<-h>]
|
2006-03-01 05:02:29 +00:00
|
|
|
|
|
|
|
|
=for html
|
|
|
|
|
</div>
|
2005-12-22 07:34:49 +00:00
|
|
|
|
|
|
|
|
=head1 DESCRIPTION
|
|
|
|
|
|
|
|
|
|
B<voldump> dumps an AFS volume in the format used by B<vos dump> without
|
|
|
|
|
using the Volume Server. It must be run on the file server machine and
|
|
|
|
|
usually must be run as the superuser C<root> to have permissions to read
|
|
|
|
|
the file server data. It's primary use is to recover data from a file
|
|
|
|
|
server machine where the Volume Server cannot be started for some reason.
|
|
|
|
|
|
|
|
|
|
The dump output will go to standard output, or to a file if B<-file> is
|
|
|
|
|
specified. B<vos restore> can be used to load the resulting dump into a
|
|
|
|
|
new AFS volume. B<voldump> always does a full dump.
|
|
|
|
|
|
|
|
|
|
=head1 CAUTIONS
|
|
|
|
|
|
|
|
|
|
Normally, use B<vos dump> instead of this command. B<voldump> is a tool
|
|
|
|
|
of last resort to try to extract data from the raw data structures stored
|
|
|
|
|
on the file server machine and is not as regularly tested or used as the
|
|
|
|
|
normal B<vos dump> implementation.
|
|
|
|
|
|
|
|
|
|
If the AFS volume being dumped changes while B<voldump> is running, the
|
|
|
|
|
results may be inconsistent. If the File Server and Volume Server are
|
|
|
|
|
running, stop them with B<bos shutdown> or a similar method before running
|
|
|
|
|
this command.
|
|
|
|
|
|
|
|
|
|
=head1 OPTIONS
|
|
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
|
|
=item B<-part> <I<partition>>
|
|
|
|
|
|
|
|
|
|
Names the partition on which the volume to be dumped is located.
|
|
|
|
|
B<voldump> does not take the normal full range of ways of specifying a
|
|
|
|
|
partition. Instead, I<partition> must be either a single letter between
|
|
|
|
|
C<a> and C<z>, corresponding to F</vicepa> through F</vicepz>, or the full
|
|
|
|
|
path to the file server partition. C<aa> is not recognized; use
|
|
|
|
|
F</vicepaa> instead.
|
|
|
|
|
|
|
|
|
|
=item B<-volumeid> <I<volume id>>
|
|
|
|
|
|
|
|
|
|
Specifies the ID of the volume to dump. The volume must be specified by
|
|
|
|
|
numeric ID, not by name.
|
|
|
|
|
|
|
|
|
|
=item B<-file> <I<dump file>>
|
|
|
|
|
|
|
|
|
|
Specifies the output file for the dump. If this option is not given, the
|
|
|
|
|
volume will be dumped to standard output.
|
|
|
|
|
|
2013-06-14 22:03:40 +01:00
|
|
|
=item B<-time> <I<dump from time>>
|
|
|
|
|
|
|
|
|
|
Specifies whether the dump is full or incremental. Omit this argument to create
|
|
|
|
|
a full dump, or provide one of the valid values listed in L<vos_dump(1)>.
|
|
|
|
|
|
volser: Don't NUL-pad failed pread()s in dumps
Currently, the volserver SAFSVolDump RPC and the 'voldump' utility
handle short reads from pread() for vnode payloads by padding the
missing data with NUL bytes. That is, if we request 4k of data for our
pread() call, and we only get back 1k of data, we'll write 1k of data
to the volume dump stream followed by 3k of NUL bytes, and log
messages like this:
1 Volser: DumpFile: Error reading inode 1234 for vnode 5678
1 Volser: DumpFile: Null padding file: 3072 bytes at offset 40960
This can happen if we hit EOF on the underlying file sooner than
expected, or if the OS just responds with fewer bytes than requested
for any reason.
The same code path tries to do the same NUL-padding if pread() returns
an error (for example, EIO), padding the entire e.g. 4k block with
NULs. However, in this case, the "padding" code often doesn't work as
intended, because we compare 'n' (set to -1) with 'howMany' (set to 4k
in this example), like so:
if (n < howMany)
Here, 'n' is signed (ssize_t), and 'howMany' is unsigned (size_t), and
so compilers will promote 'n' to the unsigned type, causing this
conditional to fail when n is -1. As a result, all of the relevant log
messages are skipped, and the data in the dumpstream gets corrupted
(we skip a block of data, and our 'howFar' offset goes back by 1). So
this can result in rare silent data corruption in volume dumps, which
can occur during volume releases, moves, etc.
To fix all of this, remove this bizarre NUL-padding behavior in the
volserver. Instead:
- For actual errors from pread(), return an error, like we do for I/O
errors in most other code paths.
- For short reads, just write out the amount of data we actually read,
and keep going.
- For premature EOF, treat it like a pread() error, but log a slightly
different message.
For the 'voldump' utility, the padding behavior can make sense if a
user is trying to recover volume data offline in a disaster recovery
scenario. So for voldump, add a new switch (-pad-errors) to enable the
padding behavior, but change the default behavior to bail out on
errors.
Change-Id: Ibd6e76c5ea0dea95e3354d9b34536296f81b4f67
Reviewed-on: https://gerrit.openafs.org/14255
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
2020-06-23 04:54:52 +01:00
|
|
|
=item B<-pad-errors>
|
|
|
|
|
|
|
|
|
|
When reading vnode data from disk, if B<voldump> encounters an I/O error or
|
|
|
|
|
unexpected EOF, by default B<voldump> will print an error and exit. If
|
|
|
|
|
B<-pad-errors> is given, instead B<voldump> will pad the unreadable region with
|
|
|
|
|
NUL bytes, and continue with the dump.
|
|
|
|
|
|
|
|
|
|
This option may be useful when trying to extract data from volumes where the
|
|
|
|
|
underlying disk is failing, or the volume data is corrupted. Data may be
|
|
|
|
|
missing from files in the volume in such cases (replaced by NUL bytes), but at
|
|
|
|
|
least some data may be extracted.
|
|
|
|
|
|
2005-12-22 07:34:49 +00:00
|
|
|
=item B<-verbose>
|
|
|
|
|
|
|
|
|
|
Asks for a verbose trace of the dump process. This trace information will
|
|
|
|
|
be sent to standard error.
|
|
|
|
|
|
2013-06-14 22:03:40 +01:00
|
|
|
=item B<-help>
|
|
|
|
|
|
|
|
|
|
Prints the online help for this command. All other valid options are
|
|
|
|
|
ignored.
|
|
|
|
|
|
2005-12-22 07:34:49 +00:00
|
|
|
=back
|
|
|
|
|
|
|
|
|
|
=head1 EXAMPLES
|
|
|
|
|
|
|
|
|
|
The following command dumps the volume 1936964939 on the F</vicepb>
|
|
|
|
|
partition to the file F</tmp/volume.dump>:
|
|
|
|
|
|
|
|
|
|
% voldump -part /vicepb -volumeid 1936964939 -file /tmp/volume.dump
|
|
|
|
|
|
|
|
|
|
=head1 PRIVILEGE REQUIRED
|
|
|
|
|
|
|
|
|
|
The issuer must have read access to the file server data stored in the
|
|
|
|
|
specified partition. Usually, this means that the issuer must be the
|
|
|
|
|
local superuser C<root> on the file server machine.
|
|
|
|
|
|
|
|
|
|
=head1 SEE ALSO
|
|
|
|
|
|
|
|
|
|
L<bos_shutdown(8)>,
|
2009-08-22 02:12:39 +01:00
|
|
|
L<restorevol(1)>,
|
2005-12-22 07:34:49 +00:00
|
|
|
L<volserver(8)>,
|
|
|
|
|
L<vos_dump(1)>,
|
|
|
|
|
L<vos_restore(1)>
|
|
|
|
|
|
|
|
|
|
=head1 COPYRIGHT
|
|
|
|
|
|
|
|
|
|
Copyright 2005 Russ Allbery <rra@stanford.edu>
|
|
|
|
|
|
|
|
|
|
This documentation is covered by the IBM Public License Version 1.0. This
|
|
|
|
|
man page was written by Russ Allbery for OpenAFS.
|
