[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Linux-cluster] GFS2 file system maintenance question.

Thanks much Ryan,

Its good to know this situation can be handled via the CLVM layer even though GFS2 doesn't provide a method directly. I just needed to know there was a way to deal with those situations. I will hang on to the least bad old RAID system, rather than surplussing it, to use as a temp LUN.

I understand we are not a typical use case. We do re-purpose equipment for other experiments or tasks at times, and it would be great to be able without completely tearing down existing setups. Even though its not a common event, it sure would be nice to have the capability to move older data offline and reduce the file system in place if the situation arises.

Other than just griping, I'd also like to say its greatly appreciated that you (Red Hat) created and have made GFS2 available. We have been using XSan2/StorNext, and its great to have such an alternative. Now that Apple has discontinued its Server support we are looking to move to Red Hat's GFS2 SAN solution. We looked into other cluster file systems like GlusterFS, but we need a real SAN and not a distributed file system for this use case.

Thanks again,

On 03/15/2011 03:09 AM, Ryan Mitchell wrote:
On 03/15/2011 08:35 AM, Jack Duston wrote:
I planned to free up enough space on the GFS2 LV to migrate data off
one LUN. I could then decrease the GFS2 file system size, remove the
LUN from the LV, destroy the RAID LUN, replace 1TB HDDs with 3TB HDDs,
rebuild the RAID LUN, add the new larger LUN to the LV, increase the
GFS2 file system size, and repeat migrating data off the next LUN.


No you will not be able to use that procedure to swap LUNs.  If you have
the ability to present the new LUN's before removing the old LUN's from
the volume group, it would be possible to:
1) vgextend the volume group using the new LUN
2) pvmove the extents from the old LUN to the new LUN
3) vgreduce the old LUN to remove it from the volume group

This could be done 1 LUN at a time.  It doesn't even require you to grow
the filesystem (unless the new LUN's are larger than the old ones).
This is common and I've seen it done many times.  You could even use a
temporary staging LUN to shuffle the data around.

If you do not have the capacity to add additional LUNs before removing
the original LUNs, then you will face a difficult migration, possibly
using backup/restore as you mentioned.

The feature to reduce the filesystem has not been implemented; there is
no code as yet to manage it.  It isn't commonly required.


Ryan Mitchell

Linux-cluster mailing list
Linux-cluster redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]