Hello, I see your point. Which is faster, transferring the data between two separate file systems (i.e. over FC, ~210MB/s), or moving stuff within the same disk group? I'd imagine that moving data from a LUN to another will require the same I/O regardless of the method used.
Of course the "no user impact" sounds quite tempting. -j- -----Original Message----- From: Doug Hughes [mailto:[EMAIL PROTECTED] Sent: jueves, 12 de abril de 2007 14:49 To: Jarkko Airaksinen Cc: [EMAIL PROTECTED] Subject: Re: [Veritas-vx] resizing a device Jarkko Airaksinen wrote: > Summary! > > In case someone else is fighting with the same problems I thought I'd > share my conclusion with you. > > I've decided not to resize the LUNS / file systems at all as Solaris 8 > is quite restrictive with LUN resizing. I've overcome the need for > resizing them with a bit of thinking. > > Given the variables (Sol8, EVA, VVM5, Oracle9i, Tape / EVA backups and > most importantly, our needs) I've come to a conclusion that: > > 1. If we need more space for the growing data I'll just create another > file systems to their own groups, for example DATA01 and DATA02 to > data01dg and data02dg etc. Also for some reason distributing data / arch > / redo files to separate file systems a bit improves the performance of > our application. > > 2. With the practice mentioned above I only need to resize (shrink) a > disk when the data doesn't grow anymore and this happens only once a > year when the year is closed. I can do this by calculating the space > needed for the data and creating a new file system for it, move the data > on the new disk and destroy the old one. > > Wouldn't it be easier just to allocate the new disks/luns (as needed) and just move and resize the volume on the new space? There's really no need to create a new filesystem as long as you have the unused space someplace. You can do moves on the fly within the same diskgroup without anyone being the wiser and with no user impact. > As simple as that. No need to fiddle with temporary disks and the > one-lun-per-diskgroup is safe (no concat file systems). The only single > point of failure is the SAN and with its three-level internal data > protection the only reasonable threat is the complete destruction of it. > > > > __________________________________________________________________________ La informacion incluida en el presente correo electronico es CONFIDENCIAL, siendo para el uso exclusivo del/os destinatario/s arriba mencionado/s. Si usted recibe y lee este correo electronico y no es el destinatario senalado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion, uso o reproduccion del mismo, y le rogamos que nos lo notifique inmediatamente respondiendo al mensaje original a la direccion arriba mencionada y eliminando el mensaje a continuacion. The information contained in this e-mail is CONFIDENTIAL and is intended only for the use of the addressee named above.If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, or you have received this communication in error, please be aware that any diffusion, distribution or duplication of this communication is strictly forbidden, and please notify us immediately by return to the original message at the address above eliminating it afterwards. _______________________________________________ Veritas-vx maillist - [EMAIL PROTECTED] http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
