On Mon, 2016-07-04 at 10:15 +1000, Dave Chinner wrote: > The error you are seeing is with the last media file in the dump > which, IIRC, contains critical inventory information and so restore > cannot continue without that media file. You need to work out why > that last media file is returning a short read, once once you solve > that problem xfsrestore should work correctly. > I think every media file is returning a short read; looking at http://pastebin.com/UW9zRAZ0 this pattern repeats: xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = wprot onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk wprot onl xfsrestore: tape op: reading 245760 bytes xfsrestore: tape op read of 245760 bytes short: nread == 4096 i.e. it skips to the next filemark and the first read is short. Ah... https://wiki.zmanda.com/index.php/Installation/OS_Specific_Notes/Installing_Amanda_on_IRIX "When setting the tape device name in either amanda.conf or one of the changer configuration files, make sure you specify the "variable" device name, which has a 'v' on the end. If not, IRIX will write 4KByte blocks instead of the 32KByte blocks AMANDA tells it to. This apparantly works OK unless you take the tape to a non-IRIX system, where amrestore will complain about a short (4096) read." The page goes on to suggest using dd to skip the first eight 4k blocks, but that doesn't seem right to me (since the first blocks evidently contain sensible data.) So on the face of it this is a tape with fixed length blocks, in which case # mt -f /dev/<name> setblk 4096 might do the trick. (Also use '-m -b 4096' with xfsrestore.) -- Roger _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
