[Linux-cluster] GFS2 file system maintenance question.
Jack Duston
jduston at ll.mit.edu
Tue Mar 15 18:14:24 UTC 2011
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,
Jack
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.
>>
> Hi,
>
> 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.
>
> Regards,
>
> Ryan Mitchell
>
> --
> Linux-cluster mailing list
> Linux-cluster at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-cluster
More information about the Linux-cluster
mailing list