Re: GFS2 file system maintenance question.

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

 



Thanks Yue, but your information would seem dated if this site is correct:

http://www.redhat.com/rhel/compare

Even if 100TB is what's officially supported in RHEL6, it doesn't mean
that larger file systems won't work. Most likely that is the largest
amount of storage that Red Hat had available to test. Since this is a
brand new setup, now is a great time to see if it works with the storage
I have available. If it doesn't, then I haven't lost anything other than
a little time, and I'll just chunk it up into 100TB Logical Volumes.
However, since it would be better for our purposes, I would like to keep
our data in one file system if possible.

Regards,
Jack

On 03/14/2011 09:35 PM, yue wrote:
> 1.
> GFS2 is based on a 64-bit architecture, which can theoretically
> accommodate an 8 EB file system. However, the current supported
> maximum size of a GFS2 file system is 25 TB. If your system requires
> GFS2 file systems larger than 25 TB, contact your Red Hat service
> representative.
>
>
> At 2011-03-15 06:35:30,"Jack Duston" <jduston@xxxxxxxxxx> wrote:
>
> >Hello folks,
> >
> >I am planning to create a 2 node cluster with a GFS2 CLVM SAN.
> >The following Note in the RHEL6 GFS2 manual jumped out at me:
> >
> >Chapter 3. Managing GFS2
> >Note:
> >Once you have created a GFS2 file system with the mkfs.gfs2 command, you 
> >cannot decrease the size of the file system. You can, however, increase 
> >the size of an existing file system with the gfs2_grow command, as 
> >described in Section 3.6, “Growing a File System”.
> >
> >This seems to me to make a GFS2 LV un-maintainable.
> >
> >What concerns me is the issue of how to remove a LUN from the GFS2 LV. 
> >This will be a necessity *when* there are hardware problems with a 
> >storage unit, End of Life/obsolescence (a la XRaid), or upgrade (replace 
> >1TB HDDS with 3 TB HDDs in the LUNs).
> >
> >Hardware does not last forever, and manufacturers do EOL products or go 
> >out of business.
> >I had also hoped to upgrade the 1TB HDDs in our current LUNs with 3 TB 
> >HDDs next year.
> >
> >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.
> >
> >If the above note is correct, it seems to only way to deal with a 
> >hardware issue, obsolescence/EOL, or upgrading components is to destroy 
> >the entire GFS2 file system, build a new GFS2 file system from scratch, 
> >and restore data from backups. This might not be too bad with a small 
> >SAN of 20TB, but our data will exceed 100TB and it would be good not to 
> >have to rebuild Rome in a day.
> >
> >Can anyone confirm that GFS2 file system cannot be decreased? If so, is 
> >there any plan to add this capability/fix this issue in a future 
> >release? Is there another/better way to remove a LUN from GFS2 than what 
> >I considered?
> >
> >Any info greatly appreciated.
> >
> >--
> >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



[Index of Archives]     [Corosync Cluster Engine]     [GFS]     [Linux Virtualization]     [Centos Virtualization]     [Centos]     [Linux RAID]     [Fedora Users]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Camping]

  Powered by Linux