[prev in list] [next in list] [prev in thread] [next in thread] 

List:       evms-devel
Subject:    [Evms-devel] Re: A way to dump the object tree in EVMS?
From:       Matthias Ferdinand <mf () 14v ! de>
Date:       2005-09-08 17:45:51
Message-ID: 0DC6A5D6BBE572097855B781 () [192 ! 168 ! 11 ! 24]
[Download RAW message or body]

--On Donnerstag, September 01, 2005 20:20:06 -0700 
evms-devel-request@lists.sourceforge.net wrote:

> A way to dump the object tree in EVMS?

Hi, sorry for late reply, vacation + mail backlog. I am working on
something similar to this, although I am not into XML. So far I
managed to compress output of the script evms_gather_info into
something more compact and (with  another script) to walk this tree
from a volume down to the disks, showing only the parts relevant for
this volume. Sample output from my script (excerpt), showing data
for a disk, a segment, a region, a container and a volume.

##############
d: sda, 8:0, active, 76.34GB, CHSB=9964/255/63/512
      ei: Name=sda, Size=160086528 sec, Cyl=9964, Heads=255, Sectors=63, 
SectorSize=512 bytes, BlockSize=4096 bytes, BootLimit=16434495, Segments=6, 
Type=SCSI
      parents: sda_mbr, sda1, sda2, sda3, sda4, sda_freespace1

d: sdb, 8:16, active, 76.34GB, CHSB=9964/255/63/512
      ei: Name=sdb, Size=160086528 sec, Cyl=9964, Heads=255, Sectors=63, 
SectorSize=512 bytes, BlockSize=4096 bytes, BootLimit=16434495, Segments=6, 
Type=SCSI
      parents: sdb_mbr, sdb1, sdb2, sdb3, sdb4, sdb_freespace1

s: sda3, 254:7, active, 65.00GB, Data
      ei: Name=sda3, Size=136311525 sec, Start=4176900, Flag=Yes, Type=83, 
BootInd=0
      parents: md/md1
      children: sda

s: sdb3, 254:8, active, 65.00GB, Data
      ei: Name=sdb3, Size=136311525 sec, Start=4176900, Flag=Yes, Type=83, 
BootInd=0
      parents: md/md1
      children: sdb

r: lvm/stripevol/reg02, 254:35, active, 10.00GB, Data
      o: name
      c: Expand
         o: add_extents [2878], add_size [94306304], pv_names []
      c: Shrink
         o: remove_extents [1], remove_size [32768]
      t: move_extent
         o: le, pv, pe
      ei: LV_Name=lvm/stripevol/reg02, VG_Name=lvm/stripevol, LV_Number=2, 
LV_Size=20971520 sec, Extents=640, Permissions=Read-Write
      parents: /dev/evms/vol02
      children: md/md1

r: md/md1, 254:9, active, 130.00GB, Data
      ei: name=md/md1, state=Discovered/Active, personality=RAID0, 
superblock=(null), nr_disks=2, child_object0=sda3, child_object1=sdb3
      parents: lvm/stripevol/reg01, lvm/stripevol/reg02, 
lvm/stripevol/Freespace
      children: sda3, sdb3

c: lvm/stripevol, 129.97GB
      c: Expand
      t: move_pv
      ei: VG_Name=lvm/stripevol, VG_Number=0, VG_Size=272564224 sec, 
VG_Free_Size=94306304 sec, VG_Percent_Allocated=65.40, PE_Size=32768 sec, 
Total_PEs=8318, Available_PEs=2878, Current_PVs=1, Current_LVs=8, 
Max_LV_Size=2147483648 sec, VG_UUID=0gjVoP-cERm-mbNq-RjBt-s3Ga-pgWW-Kkt4DQ
      parents: lvm/stripevol/Freespace, lvm/stripevol/reg01, 
lvm/stripevol/reg02
      children: md/md1

v: /dev/evms/vol02, 254:36, active, 10.00GB, ReiserFS, no mnt, max 16.00TB, 
min 1.13GB
      c: Check, Delete, Expand, Format, Rename, Revert, Shrink, Unformat
      f: Drive Linking Feature
      ei: MagicNumber=ReIsEr2Fs, Version=2, VolLabel=, UsableSize=20905856 
sec, LogSize=65536 sec
      children: lvm/stripevol/reg02
#############

So far I have not worked on rebuilding the structure on another
system, mostly because I don't see yet how to implement this without
major disasters if the destination system isn't exactly like the
first one. And if it is the same, there is already
evms_metadata_backup / evms_metadata_restore.
But for documenting the structure underlying a volume it does an
ok job.

There are some obstacles to the publication of my scripts:
  1) don't know if I am allowed by my employer
  2) requires patching evms (cli software) and evms_gather_info
        - auto-linebreaking in evms output makes it a nightmare
          to parse (not that it was easy without that :-)
        - I wanted "extended info" on volumes

If people are interested, I will ask for permission to publicize.

Best regards
Matthias Ferdinand



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Evms-devel mailing list
Evms-devel@lists.sourceforge.net
To subscribe/unsubscribe, please visit:
https://lists.sourceforge.net/lists/listinfo/evms-devel
[prev in list] [next in list] [prev in thread] [next in thread]