0

I'll be creating a Linux storage server with several TB capacity using a hardware RAID array. But I was wondering, what are my options for extending it in the future?

To be more specifiec, if I create a volume group with the local RAID array as physical volume, I suppose it is not smart to include a iSCSI target in that same volume group and extend the size of the logical volume? I mean, when the iSCSI link is/goes down, the logical volume will probably be corrupted.

Is there a safe way to extent the size of that logical volume or should I just make another logical volume?

Halfgaar
  • 8,084
  • 6
  • 45
  • 86

2 Answers2

1

What's the file system in use on the LUN?

I ask because as far as I remember, you can't resize a VMFS volume. So if you're using VMFS and hosting VMs on this space, your best bet is to migrate your data to another LUN, then destroy and re-provision the LUN across the extra disks.

Edit: To clarify - Adding additional capacity to a LUN is feasible with extents, but not recommended practice (direct advice from VMWare support/techs). This was accurate as of 12 months ago.

Chris Thorpe
  • 9,953
  • 23
  • 33
  • The filesystem has not yet been decided. Can be Ext3, Ext4 or perhaps xfs. XFS would be a suitable canidate because it's going to handle large files. – Halfgaar Aug 02 '10 at 11:27
1

I have a similar scenario, I also fear that the VG might be corrupted if the iSCSI target goes down.

So, I have also been specifying the physical volume when I create LVs in the hopes that if one PV goes down, it will allow other LVs based on other PVs to continue. I plan to test this, and if I can think of it, I'll post back some results. Of course, if you want to have a single LV greater than the size of a single PV, that approach doesn't really fly.

In general, my longer-term plan is to expand the server later with SAS-attached storage arrays -- but I know that's not exactly what you asked. I would trust that a whole lot better than iSCSI targets -- I HAVE had really good luck with iSCSI, but reboots require a lot of thought about the order -- i.e. what needs to be shut down first.

mikehapner
  • 1,175
  • 10
  • 9