In regards to the incorrect size of the volume, I've seen this in the past when I was setting this up. I'm not sure why it does this, maybe a bug? Maybe the bug has been addressed already?
Chris Coffey Application Support Specialist Information Technology 928-779-7685 x7204 >>> Rafiu Fakunle <[EMAIL PROTECTED]> 11/29/2006 7:07 AM >>> Bill Pye wrote: > It seems that the simple answer was to do a vgimport of the 'storage' volume, that's now allowed me to create the new volume 'data' without editing the volume.xml file. Adding the information for the volume 'storage' has also made that visible in OF but the 'create new volume' tab has an entry for a file system type, I guess you format it at this point? Is it possible to create a volume without formatting if you already have a volume with data on it? Perhaps I'm talking nonsense here, don't forget I'm new to this (& linux). > Please see my earlier post regarding this. You need to edit volumes.xml to bring the volumes under Openfiler management. > As I mentioned earlier, I would have thought you should be able to create new disks & volumes with an exported volume plugged into the controller shouldn't you? That volume should be left exported while I create the rest of the volumes on my system. That's what appears to be causing the problem.o > Maybe, never tried it. > A minor point here, the volume storage is 1.7TB but in Volume Group Management/View member PVs it shows as double that size - 3538.06GB. > Cool, I'll look into it. > If the metadata for a volume is lost or overwritten, I was referring to Openfiler-specific metadata not the LVM metadata. > does that mean the data is irretrievably lost (I know the importance of backups) or can it be recovered by any linux utilities? I'm still learning about linux and wondered if I stupidly/accidentally overwrite the metadata is there any way to recover what's on there. > > An easy way to determine whether your data is still there is to mount the volume. So for example: VG=storage LV=data then do: vgchange -ay mkdir X mount /dev/storage/data X ls X R. > >> There's now functionality in the GUI that allows for backing up your >> metadata. >> > > > >> OK, so what you really need is the ability to access and manage the VG >> >> "storage" and any LVs associated with it. >> >> What I worry about however, is that your lvdisplay did not show any >> LVs >> associated with the "storage" VG. >> >> Do this: >> >> pvscan >> vgscan >> vgchange -ay >> lvdisplay (and look for LVs associated with "storage" VG) >> >> >> Go to /opt/openfiler/etc/ >> >> edit volumes.xml >> >> Make it look something like this: >> >> <volumes> >> <volume id="test" name="test" mountpoint="/mnt/data/test/" >> vg="data" fstype="ext3" >> incominguser="" >> incomingpassword="" outgoinguser="" outgoingpassword="" /> >> </volumes> >> >> The above should be pretty self explanatory. >> >> You'll need to edit your fstab and enter the relevant data to mount >> the >> volume(s) >> >> Then do: >> >> mount -a >> > > > >> It does indeed make it impossible to get at data. >> >> >> R. >> > > _______________________________________________ > Openfiler-users mailing list > [email protected] > https://lists.openfiler.com/mailman/listinfo/openfiler-users > _______________________________________________ Openfiler-users mailing list [email protected] https://lists.openfiler.com/mailman/listinfo/openfiler-users _______________________________________________ Openfiler-users mailing list [email protected] https://lists.openfiler.com/mailman/listinfo/openfiler-users
