Bug 120881
| Summary: | 4.11 dumps cause restore(8) to panic with "lost data" | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Diomidis Spinellis <dds> |
| Component: | bin | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 8.0-CURRENT | ||
| Hardware: | Any | ||
| OS: | Any | ||
State Changed From-To: open->closed Duplicate of 118087 (which was forwared to dwmalone today). State Changed From-To: closed->open This problem is different from 118087, and occurs with restore patched as proposed in 118087. Responsible Changed From-To: freebsd-bugs->dwmalone I'll have a look at this. David. mckusick 2008-05-22 22:19:33 UTC
FreeBSD src repository
Modified files:
sbin/restore tape.c
Log:
This fixes the "getfile: lost data" panic when restoring dumps
on a 7.0 or later system that were created on a pre-5.0 system.
We must ensure that restore zeros out the previously undefined
birthtime and external attribute size fields when reading dump
tapes made by the UFS1 dump program.
The problem is that UFS2 dump carefully zeros out the unused
birthtime and external attribute size fields in the dump header
when dumping UFS1 filesystems, but the UFS1 dump didn't know about
those fields (they were spares) so just left whatever random junk
was in them. So, when restoring one of these pre-UFS2 dumps,
the new restore would eventually trip across a header that had
a non-zero external attribute size and try to extract it. That
consumed several tape blocks which left it totally out of sync
and very unhappy (i.e., the panic). The fix is in the gethead()
function which modernizes old headers by copying old fields to
their new location (and with this fix) zeroing out previously
undefined fields.
PR: bin/120881
Review by: David Malone & Scott Lambert
MFC after: 1 week
Revision Changes Path
1.53 +3 -0 src/sbin/restore/tape.c
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
State Changed From-To: open->closed This should be fixed in RELENG_6, RELENG_7 and -current now. David. Responsible Changed From-To: dwmalone->freebsd-bugs over to the pool (approved by bugmeister) |
Restoring a level-0 dump generated on a 4.11 system with dump -h 0 -au -f - /vol on a CURRENT system with restore -dv -rN -f - causes restore to panic on tape.c line 1025 with curblk having the value of 1. Previous files verify OK. Here is the excerpted output of restore: Verify tape and initialize maps Dump date: Fri Jan 11 21:36:29 2008 Dumped from: the epoch Level 0 dump of /vol on [...]:/dev/ad2c Label: none Begin level 0 restore Initialize symbol table. Extract directories from tape [...] Extract new leaves. Check pointing the restore extract file ./du.out skipping 1 junk block(s) File header, ino 3 extract file ./errors skipping 1 junk block(s) File header, ino 4 extract file ./music/[...] skipping 1 junk block(s) File header, ino 540672 extract file ./music/... File header, ino 540676 File continuation header, ino 540676 [... 16 identical lines] File continuation header, ino 540676 Missing address (header) block for ./[...] at 0 blocks extract file ./music/[...] File header, ino 540677 File continuation header, ino 540677 [... 18 identical lines] File continuation header, ino 540677 Missing address (header) block for ./[...] at 0 blocks getfile: lost data abort? [yn] Fix: It seems that the culprit is the following sequence in tape.c if (curblk > 0) panic("getfile: lost data\n"); This was introduced in version 1.48 Version 1.44.2.1 of tape.c shipped with FreeBSD 6.2 has a different handler: if (curblk > 0) (*fill)((char *)buf, (long)((curblk * TP_BSIZE) + size)); which doesn't panic. How-To-Repeat: See above. The dump in question is 190GB, but I could work on creating a subset, if needed.