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?
This topic has been locked.
4 replies Latest Post - 2012-11-16T16:31:34Z by vladimir_cnaf
Pinned topic changing block size of existing file system
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2012-11-16T16:31:34Z at 2012-11-16T16:31:34Z by vladimir_cnaf
kalcig 270002R7E821 PostsACCEPTED ANSWER
Re: changing block size of existing file system2012-11-16T07:02:18Z in response to vladimir_cnafAFM 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.
Re: changing block size of existing file system2012-11-16T12:28:24Z in response to kalcigThanks 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 110000D4XK2092 PostsACCEPTED ANSWER
Re: changing block size of existing file system2012-11-16T15:14:55Z in response to vladimir_cnafI 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.
Re: changing block size of existing file system2012-11-16T16:31:34Z in response to SystemAdminit'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...