Vincent -- Thanx for your testing. I wish I had a test system at the client, but I do not (long story, and none of which I can share). You're saving me a lot of time. If I can do anything for you in the future, don't hesitate to ask.
Sounds like we don't want the risk at this point. Last night I toyed with an alternative migration procedure to VxFS using the new storage, instead of trying to resize Ext3. Long story short, the services/processes can be discretely SIGHUP'd or restarted, so we could change the disk access to another mount. Once that is done, we can recycle the existing subdisk, containing the plex/volume with Ext3, as part of the new plex/volume, with VxFS. I think this is going to be the best option going forward, for a completely on-line solution. Thank you everyone for your information, and even more so for any testing. I'm constrained in my access and options at my client. If it was all RHCS, CLVM, etc... I could give solid answers. But the Veritas aspect of the stack, when I can't test, is a limiting detail for myself. Thanx again for testing Vertias 5.1 on RHEL5.7 for me Vincent. I owe you a big one there. Didn't expect such complete assistance. ----- Original Message ----- From: "vinc...@cojot.name" <vinc...@cojot.name> Sent: Thursday, October 20, 2011 7:16 AM Err, I just tried an online resize of a test ext3 FS on a test VxVM virtual machine and resize2fs froze the system (fully patched 5.7 host, though). So, YMMV but it's true that it -should- work but perhaps its safer to do that vxresize says.. The offline method works, of course: ... cut ... _______________________________________________ rhelv5-list mailing list rhelv5-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv5-list
