When it rains it pours....

When it rains it pours....

[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

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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

xfs_restore -R -- recovering a previous restore...does it work?

[Linda A. Walsh]

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?



Linda A. Walsh wrote:
> 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
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs_restore -R -- recovering a previous restore...does it work?

[Linda A. Walsh]

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

Chris Wedgwood wrote:
> On Wed, Jun 30, 2010 at 09:21:02AM -0700, Linda A. Walsh wrote:
> 
>> 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 ...
> 
> see anything?
> 
>> 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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs_restore -R -- recovering a previous restore...does it work?

[Linda A. Walsh]

Chris Wedgwood wrote:
> On Wed, Jun 30, 2010 at 10:52:00AM -0700, Linda A. Walsh wrote:
> 
>> 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.


> 
>> 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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs_restore -R -- recovering a previous restore...does it work?

[Linda A. Walsh]

Chris Wedgwood wrote:
>>> 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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: When it rains it pours....

[Dave Chinner]

On Wed, Jun 30, 2010 at 05:25:58AM -0700, Linda A. Walsh wrote:
> 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?

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. ;)

> 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....

>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.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs