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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
