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?
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 270002R7E826 Posts
Re: changing block size of existing file system2012-11-16T07:02:18ZThis is the accepted answer. This is the accepted answer.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.
Re: changing block size of existing file system2012-11-16T12:28:24ZThis is the accepted answer. This is the accepted answer.
- kalcig 270002R7E8
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 Posts
Re: changing block size of existing file system2012-11-16T15:14:55ZThis is the accepted answer. This is the accepted answer.
- vladimir_cnaf 0600023AGP
Re: changing block size of existing file system2012-11-16T16:31:34ZThis is the accepted answer. This is the accepted answer.
- SystemAdmin 110000D4XK
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...