[gpfsug-discuss] SOBAR questions

Wed Jul 19 12:09:48 BST 2017

Nils Haustein did such a migration from v7000 Unified to ESS last year.
Used SOBAR to avoid recalls from HSM. I believe he wrote a whitepaper on
the process..

-jf
tir. 18. jul. 2017 kl. 21.21 skrev Simon Thompson (IT Research Support) <
S.J.Thompson at bham.ac.uk>:

> So just following up on my questions from January.
>
> We tried to do 2. I.e. Restore to a new file-system with different block
> sizes. It got part way through creating the file-sets on the new SOBAR
> file-system and then GPFS asserts and crashes... We weren't actually
> intentionally trying to move block sizes, but because we were restoring
> from a traditional SAN based system to a shiny new GNR based system, we'd
> manually done the FS create steps.
>
> I have a PMR open now. I don't know if someone internally in IBM actually
> tried this after my emails, as apparently there is a similar internal
> defect which is ~6 months old...
>
> Simon
>
> From: <gpfsug-discuss-bounces at spectrumscale.org> on behalf of Marc A
> Kaplan <makaplan at us.ibm.com>
> Reply-To: "gpfsug-discuss at spectrumscale.org" <
> gpfsug-discuss at spectrumscale.org>
> Date: Friday, 20 January 2017 at 17:57
>
> To: "gpfsug-discuss at spectrumscale.org" <gpfsug-discuss at spectrumscale.org>
> Subject: Re: [gpfsug-discuss] SOBAR questions
>
> I worked on some aspects of SOBAR, but without studying and testing the
> commands - I'm not in a position right now to give simple definitive
> answers -
> having said that....
>
> Generally your questions are reasonable and the answer is: "Yes it should
> be possible to do that, but you might be going a bit beyond the design
> point..,
> so you'll need to try it out on a (smaller) test system with some smaller
> tedst files.
>
> Point by point.
>
> 1. If SOBAR is unable to restore a particular file, perhaps because the
> premigration did not complete -- you should only lose that particular file,
> and otherwise "keep going".
>
> 2. I think SOBAR helps you build a similar file system to the original,
> including block sizes.  So you'd have to go in and tweak the file system
> creation step(s).
> I think this is reasonable... If you hit a problem... IMO that would be a
> fair APAR.
>
> 3. Similar to 2.
>
>
>
>
>
> From:        "Simon Thompson (Research Computing - IT Services)" <
> S.J.Thompson at bham.ac.uk>
> To:        "gpfsug-discuss at spectrumscale.org" <
> gpfsug-discuss at spectrumscale.org>
> Date:        01/20/2017 10:44 AM
> Subject:        [gpfsug-discuss] SOBAR questions
> Sent by:        gpfsug-discuss-bounces at spectrumscale.org
> ------------------------------
>
>
>
> We've recently been looking at deploying SOBAR to support DR of some of
> our file-systems, I have some questions (as ever!) that I can't see are
> clearly documented, so was wondering if anyone has any insight on this.
>
> 1. If we elect not to premigrate certain files, are we still able to use
> SOBAR? We are happy to take a hit that those files will never be available
> again, but some are multi TB files which change daily and we can't stream
> to tape effectively.
>
> 2. When doing a restore, does the block size of the new SOBAR'd to
> file-system have to match? For example the old FS was 1MB blocks, the new
> FS we create with 2MB blocks. Will this work (this strikes me as one way
> we might be able to migrate an FS to a new block size?)?
>
> 3. If the file-system was originally created with an older GPFS code but
> has since been upgraded, does restore work, and does it matter what client
> code? E.g. We have a file-system that was originally 3.5.x, its been
> upgraded over time to 4.2.2.0. Will this work if the client code was say
> 4.2.2.5 (with an appropriate FS version). E.g. Mmlsfs lists, "13.01
> (3.5.0.0) Original file system version" and "16.00 (4.2.2.0) Current file
> system version". Say there was 4.2.2.5 which created version 16.01
> file-system as the new FS, what would happen?
>
> This sort of detail is missing from:
> https://www.ibm.com/support/knowledgecenter/STXKQY_4.2.2/com.ibm.spectrum.s
> cale.v4r22.doc/bl1adv_sobarrestore.htm
>
> But is probably quite important for us to know!
>
> Thanks
>
> Simon
>
> _______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>
>
>
> _______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20170719/9c42a70b/attachment-0002.htm>