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: <[email protected]<mailto:[email protected]>> on behalf of Marc A Kaplan <[email protected]<mailto:[email protected]>> Reply-To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Friday, 20 January 2017 at 17:57 To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 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)" <[email protected]<mailto:[email protected]>> To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: 01/20/2017 10:44 AM Subject: [gpfsug-discuss] SOBAR questions Sent by: [email protected]<mailto:[email protected]> ________________________________ 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
