Topic
4 replies Latest Post - ‏2012-11-16T16:31:34Z by vladimir_cnaf
vladimir_cnaf
vladimir_cnaf
59 Posts
ACCEPTED ANSWER

Pinned topic changing block size of existing file system

‏2012-11-15T14:39:11Z |
Hello,

I have 1 PB file system which has been created several years ago with a block size of 1MB. In the past, while migrating to a new hardware we have used standard non-disruptive procedure (add new disks, suspend, restripe and remove old ones), keeping the original block size. That was OK until recent upgrade when we found that new storage system works much faster if GPFS file system has 4MB block size.
I guess that changing block size of an existing file system is not possible at all (I'll be more than happy if I'm wrong with this assumption), so I'm looking for possible solutions of how to migrate 1 PB of data from one file system to another without interruption of service. There is an additional complication: the file system is under HSM, so there are additional (about 1 PB) data on tapes. Backup and restore is not practicable because of time. What I'm thinking about is a possibility to use AFM functionality and define new file system as "cache" for the old one, copy all "stub"-files to the new file system, then change mount point on clients, copy on-disk data from "home" to "cache" and then detach "home". Is it feasible?
Updated on 2012-11-16T16:31:34Z at 2012-11-16T16:31:34Z by vladimir_cnaf
  • kalcig
    kalcig
    21 Posts
    ACCEPTED ANSWER

    Re: changing block size of existing file system

    ‏2012-11-16T07:02:18Z  in response to vladimir_cnaf
    AFM can be setup only on fileset granularity and needs independent filesets. You can create a new fs with 4MB block size. Create single or multiple independent filesets in LU mode with new system as cache and old system as home. LU mode is basically to prevent any changes to be pushed back to old fs and once migration completes continue changing data. Another option is to use it as RO till migration completes and switching load to new fs.

    The critical data can be moved via mmafmctl --prefetch cmd. Once critical data is moved, you can either move the load/clients to new fs and let panache move files on demand or run a background job to move all data in iterations.

    The key complication though is that AFM cannot fetch stubs but rather will drive the present fs to recall the data from HSM and move the data to new fs. This implies you should have enough space to recall data...it will probably work as one file is recalled, another file might be HSMed out.
    • vladimir_cnaf
      vladimir_cnaf
      59 Posts
      ACCEPTED ANSWER

      Re: changing block size of existing file system

      ‏2012-11-16T12:28:24Z  in response to kalcig
      Thanks Kalyan!
      yes, we have all data in filesets in that FS, some of them are entirely under HSM and other are not. For those with HSM I would pre-migrate all data to tape, umount FS, rename it, create the new FS with 4MB block size with the name of old one, re-create filesets and directory structures (dsmc restore -dirsonly -subdir=yes <fs>), restore stubs from TSM (dsmmigundelete).
      This should settle down the HSM part of the file system. For the rest of it I'd use AFM (on "per fileset" basis) using old FS as "home".
      The only thing I'm not sure about is if I can do AFM inside single cluster, or I have to create a separate one for the new FS.
      • SystemAdmin
        SystemAdmin
        2092 Posts
        ACCEPTED ANSWER

        Re: changing block size of existing file system

        ‏2012-11-16T15:14:55Z  in response to vladimir_cnaf
        I would caution you that AFM was not designed for this purpose. It may work perfectly well. But, as always, when dealing with backup and restore of important data: caution, careful testing, and extra backups are strongly advised.
        • vladimir_cnaf
          vladimir_cnaf
          59 Posts
          ACCEPTED ANSWER

          Re: changing block size of existing file system

          ‏2012-11-16T16:31:34Z  in response to SystemAdmin
          it's clear that the primary use (by design) of AFM is not for data migration, but since it provides common name space and the means to replicate data from one FS to another, it's quite advantageous to use it also in this way...
          Actually, the root question in this post was about possibility to change block size of existing file system. GPFS has evolved a lot in the past five years, but how people could use advantages of newest versions if the file systems were created years ago? With current amount of data standard IBM's recommendation "Backup and restore" is not more practicable. If IBM could provide an utility to update various file system parameters without necessity to destroy data we would not need to look for shortcuts and undocumented features...