When it rains it pours....
Due to another bug in lvm, my restore of this partition crashed after running a few hours (takes alot longer to restore than to backup).
So I decided to use the "-R" option to Resume my previously left off dump:
# xfsrestore -R -p 180 -f /backups/Ishtar/torrents/torrents-100629-0-1611.dump . xfsrestore: using file dump (drive_simple) strategy xfsrestore: version 3.0.4 (dump format 3.0) - Running single-threaded xfsrestore: resuming restore previously begun Wed Jun 30 04:41:57 2010 xfsrestore: examining media file 0 xfsrestore: seeking past portion of media file already restored
Looks good so far!..Yup, and..
xfsrestore: drive_simple.c:770: do_seek_mark: Assertion `nreadneeded64 <= ( ( intgen_t ) ( ( ( 1ull << ( ( unsigned long long )sizeof( intgen_t ) * ( unsigned long long )8 - ( 1ull + 1ull ))) - 1ull ) * 2ull + 1ull ))' failed. Aborted (core dumped)
Say what? Um...is that supposed to be an error message?
Why can't it just tell me why "'nreadneeded64' > 0xbfffffffffffffd" is 'bad', or what it means?
I have a feeling that the 'core dumped' message means that if I want my filesystem restored in the near future, I should just restart...
*sigh*
-l
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
xfs_restore -R -- recovering a previous restore...does it work?
So why is this crashing?
I just had it happen again -- something killed off the window it was executing in -- system didn't go down, but it got a hangup -- a cleaner shutdown -- but it still doesn't recover.
Under what circumstances should this work? Or does it work?
Quoted 26 lines · Linda A. Walsh
Due to another bug in lvm, my restore of this partition crashed after running a few hours (takes alot longer to restore than to backup).
So I decided to use the "-R" option to Resume my previously left off dump:
# xfsrestore -R -p 180 -f /backups/Ishtar/torrents/torrents-100629-0-1611.dump . xfsrestore: using file dump (drive_simple) strategy xfsrestore: version 3.0.4 (dump format 3.0) - Running single-threaded xfsrestore: resuming restore previously begun Wed Jun 30 04:41:57 2010 xfsrestore: examining media file 0 xfsrestore: seeking past portion of media file already restoredLooks good so far!..Yup, and..
xfsrestore: drive_simple.c:770:
do_seek_mark: Assertion `nreadneeded64 <= ( (intgen_t) ( ( ( 1ull << ( ( unsigned long long )sizeof(intgen_t) * ( unsigned long long )8 - ( 1ull + 1ull ))) - 1ull ) * 2ull + 1ull ))' failed. Aborted (core dumped)Say what? Um...is that supposed to be an error message?
Why can't it just tell me why "'nreadneeded64' >
0xbfffffffffffffd" is 'bad', or what it means?I have a feeling that the 'core dumped' message means that if I want my filesystem restored in the near future, I should just restart...
Quoted 7 lines
*sigh*
-l_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
A message that is not in the archive (sent off-list or not yet received): [email protected]
Re: xfs_restore -R -- recovering a previous restore...does it work?
Dmesg shows nothing revealing.
I am not using tape -- I'm restoring from a file.
Does it only work with tapes? I didn't recall it saying so.
-l
Quoted 8 lines · Chris Wedgwood
Quoted 3 lines · Linda A. Walsh
I just had it happen again -- something killed off the window it was executing in -- system didn't go down, but it got a hangup -- a cleaner shutdown -- but it still doesn't recover.
dmesg ...
Quoted 7 lines
see anything?
Quoted 1 line
Under what circumstances should this work? Or does it work?
it used to work for me, i've not tried it recently though, i basically gave up tapes (and xfsdump/restore) some time back due to size/cost contraints
----
Do you not keep backups at all anymore? Or if you do, do you not care about the metastuff?
Only other backup util, that I know of, that speaks meta, is 'star'.
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
A message that is not in the archive (sent off-list or not yet received): [email protected]
Re: xfs_restore -R -- recovering a previous restore...does it work?
Quoted 5 lines · Chris Wedgwood
Quoted 1 line · Linda A. Walsh
Dmesg shows nothing revealing.
it seems odd the subprocess killed you terminal then
----
No...it was attached to a terminal window that got closed
by accident.
Quoted 10 lines
Quoted 4 lines
I am not using tape -- I'm restoring from a file.
Does it only work with tapes? I didn't recall it saying so.
files should work, i've just not used them personally aside from some testing
how large is the image to be restored?
A few bytes...
2362017678616
( 2.15TB)
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
A message that is not in the archive (sent off-list or not yet received): [email protected]
Re: xfs_restore -R -- recovering a previous restore...does it work?
Quoted 4 lines · Chris Wedgwood
Quoted 2 lines
Quoted 1 line
how large is the image to be restored?
( 2.15TB)
out of interest, so smaller images work?
I don't know...this was my first time I ever tried it.
Usually smaller images don't have so many opportunities to get interrupted. :-)
This one took 3h 18m, .. a crappy 189MB/s!
I was just unlucky enough to have something interrupt it 3 times in a row (since it was the partition that was corrupt -- I'm a bit scattered as I have no idea what might have caused that partition to go corrupt and no idea if it is just going turn around and happen again. Unfortunately, it's not like it is the easiest partition to backup & restore.
Guess I can experiment! ;-)
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 12 lines · Linda A. Walsh
Due to another bug in lvm, my restore of this partition crashed after running a few hours (takes alot longer to restore than to backup).
So I decided to use the "-R" option to Resume my previously left off dump:
# xfsrestore -R -p 180 -f /backups/Ishtar/torrents/torrents-100629-0-1611.dump . xfsrestore: using file dump (drive_simple) strategy xfsrestore: version 3.0.4 (dump format 3.0) - Running single-threaded xfsrestore: resuming restore previously begun Wed Jun 30 04:41:57 2010 xfsrestore: examining media file 0 xfsrestore: seeking past portion of media file already restored
Quoted 7 lines
Looks good so far!..Yup, and..
xfsrestore: drive_simple.c:770:
do_seek_mark: Assertion `nreadneeded64 <= ( (intgen_t) ( ( ( 1ull << ( ( unsigned long long )sizeof(intgen_t) * ( unsigned long long )8 - ( 1ull + 1ull ))) - 1ull ) * 2ull + 1ull ))' failed. Aborted (core dumped)Say what? Um...is that supposed to be an error message?
No, it's an assert failure. i.e. something a developer considered fatal and requiring debugging if it ever occurred. It's not an error message an end user is expected to understand. ;)
Quoted 2 lines
Why can't it just tell me why "'nreadneeded64' >
0xbfffffffffffffd" is 'bad', or what it means?
Asserts generally indicate that design constraints or assumptions have been violated which canbe hard to explain in one line to an end user....
Quoted 1 line
From a brief look at the code, it appears that the distance between
the stream offset and the next tape mark is greater than MAXINTGENT. MAXINTGEN evaluates as 0x7fffffff (more commonly known as INT_MAX).
Normally the file is read mark by mark, but when resuming a restore we skip from the initial header to the checkpointed file mark in one step. It seems like marks are normally less that 2GB apart, but in the case of resuming, the attempt to seek from the header to the checkpointed mark is way more than 2GB and hence it triggers the assert.
I'm not sure yet how to fix this - I have't dug into the drive code in xfs_restore before so it'll take a while to understand well enough to work out a solution.
In the mean time, I think restarting your restore from scratch is your best bet.
Cheers,
Dave.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs