Bug 182968
Summary: | Seek meaning of recently appearing error message "Assertion `off' failed." | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Richard Bonomo <bonomo> |
Component: | xfsdump | Assignee: | Russell Cattelan <cattelan> |
Status: | CLOSED UPSTREAM | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 4 | CC: | cattelan |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-08-22 19:15:08 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Richard Bonomo
2006-02-24 20:07:56 UTC
I also noticed this behavior starting a couple of months ago. It got worse when I discovered I could not read the dumpset with xfsrestore until I removed the drive from the sytem, attached it to a second system, and then did the restore *remotely* from the first. Things got worse. I swapped tape drives. I found that I could do a "tar" save and read, but not an xfsdump. Whenever tried to do a dump, I would get a failure similar to this: <joining dump in progress> /usr/sbin/xfsdump: NOTE: pruned 21224 files: skip attribute set /usr/sbin/xfsdump: ino map phase 3: skipping (no pruning necessary) /usr/sbin/xfsdump: ino map phase 4: skipping (size estimated in phase 2) /usr/sbin/xfsdump: ino map phase 5: skipping (only one dump stream) /usr/sbin/xfsdump: ino map construction complete /usr/sbin/xfsdump: estimated dump size: 171930662400 bytes /usr/sbin/xfsdump: preparing drive /usr/sbin/xfsdump: ERROR: unexpected tape error: errno 16 nread -1 blksz 1048576 recsz 1048576 isvar 1 wasatbot 1 eod 0 fmk 0 eot 0 onl 1 wprot 0 ew 0 /usr/sbin/xfsdump: ERROR: unexpected error from do_begin_read: 10 /usr/sbin/xfsdump: dump size (non-dir files) : 0 bytes /usr/sbin/xfsdump: NOTE: dump interrupted: 1 seconds elapsed: may resume later using -R option /usr/sbin/xfsdump: Dump Status: INTERRUPT <end of quote> Just last night I rebooted the system into a earlier version of the kernel (2.6.14-1.1656_FC4) instead of the kernels thereafter (most recent 2.6.16-1.2108_FC4), which earlier kernel corresponds to the last time dumps went well. There is a dump in progress now, for the first time in weeks. I hope to test the dump with xfsrestore over the weekend. It looks like someone clobbered something in the update from .14 to .15. bonomo.YYY.eduYYY (drop the Y's). Goodness! I forgot that I made the original report in February! xfsdump only recently made it into fedora extras... do you still see this problem? I have been keeping the kernel at 2.6.14-1.1656_FC4, and have had no problems with the dumps with the kernel at this level. I am sure that if I reverted back to 2.6.16-1.2108_FC4, the problem would recur. I have not tried updating to the more recent kernels as I have seen no reports of the faults evidently introduced in going from .14 to .15 being found and fixed. This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks. Since filing the original report in February 2006, my status has changed: I have been layed-off (laid-off?) from my position, as of 11/30/2006, as a consequence of a budget shortfall. I am no longer in a position to supply additional information. I suggest checking for kernel changes between kernel versions referenced in comment # 4, and looking for tape-handling code which might have caused this. Then it is a question of whether the error has been propagated to the current release. I have removed my address from the CC list. This looks to me like an issue that needs to be addressed upstream with the xfsdump maintainers, if it hasn't already been addressed. http://www.oss.sgi.com/archives/xfs/2006-02/msg00100.html |