[linux-lvm] offtopic but ...

Fri May 10 08:46:01 UTC 2002

On Wed, May 08, 2002 at 04:12:48PM +0200, Oliver Jovic wrote:
> On Wed, 8 May 2002, Tim wrote:
> 
> > > Hehe Tim,
> > >
> > > that was fast, but as i told little bit lower in the email I dont want to
> > > put everything in a RAID. The RAID controller isnt the problem if you buy
> > > me a further 160GB Maxtor i will buy the RAID contoller or do
> > > software-RAID. ;-)
> >
> > Fair enough.  Personally (having to do this at work) I feel like an IDE
> > enclosure or a hardware RAID card is a relatively small investment in
> > data security, but then again, the 500GB I have live right now is not
> > content that I can tolerate data loss on.  We probably should not use
> > IDE drives for it at all, except that it is replicated onto a whole
> > steaming mess of SCSI drives, also RAIDed up...
> 
> I would also use RAID if i had important data to store. No doubt about
> that. But the data i have isnt so important. If I lose it i can live with
> it but well if i would lost only the data which was on the harddrive which
> gave up would be better. ;)

With recent LVM1 versions, you need to put the LVM metadata stored on the lost
disk onto an accessable on (which can be a loop device) using vgcfgrestore.
The you can rectivate your Volume Group and access all data but that
on the gone disk.

With 1.1-rcX, you can activate a Volume Group which lost quorum (that means
that not all of its Physical Volumes are accessable) anyway (vgchange -qn).

Both ways, you should be able to get the still accessable data. What your
filesystem makes out of this, is for suse very much depending on the particular
filesystems metadata and data layout.

Regards,
Heinz    -- The LVM Guy --

> 
> >
> > I think your requirements are different than the ones I am used to.
> >
> 
> I think also. We have a couple of machines here with RAID5 for important
> data.
> 
> >
> > > The goal is simply to combine more diskspace+more security then just a
> > > LVM+one logical unit (mountpoint/device where you dont have to care all
> > > the time
> > > how the data gets stored and where)+better usage of the diskspace (you
> > > dont have on the one everything free and the other is halffull.
> >
> > Makes sense, but I'm not sure how one would dynamically reallocate
> > parity information while everything is in-flight (eg. live).
> >
> 
> I think its easy. Maybe i just didnt described it good enough.
> 
> >
> > > Or just imagine you would like to have 500gb and have only 4x3,5 slots to
> > > build the harddrives in and the maximum size is at the moment 160GB. How
> > > would you do it and you would give up some security for the advantage to
> > > have more space but not to lose everything if one drive fails.
> > > And the idea i described in the email below is somehow between a RAID0/LVM
> > > and a RAID5.
> >
> > Again, the difference between my requirements and the ones you're
> > outlining is that I simply call a vendor and order another enclosure
> > when I need another 500GB.
> 
> Hehe wait i am searching for my postal address where you can also send me
> some 500GB. ;-)
> 
> >
> > I think I am beginning to see what your idea is, but the logistics of
> > having LVM take care of the metadata seem rather daunting.
> >
> 
> Well the idea had nothing to do with LVM. Its something 'totaly'
> different. I wouldnt need to use LVM at all if there would be such a
> solution i described.
> 
> Take a look at this:
> 
> 
> 			   application
> 				|
> +----------------------------------------------------------------------
> |
> |			virtual device
> |
> +----------------------------------------------------------------------
>     |             |            |            |
> +----------+ +----------+ +----------+ +----------+
> |          | |          | |          | |          |
> | /dev/hda | | /dev/hdb | | /dev/hdc | | /dev/hdd |
> |   ext3   | | reiserfs | |   xfs    | |  ext2    |
> +----------- +----------+ +----------+ +----------+
>  index file == index file
> 
> 
> The index file contain the dirstructure/dirtree. Its stored/updated on
> /dev/hda and /dev/hdb simultaneous so have always the index. Should be
> configurable where to put the index file. Maybe also on more then 2
> drives, simply how and where the user wants it.
> 
> Lets imagine the virutal device would be totally empty (this would mean
> all drives are also empty, but already with a filesystem which could
> differ as you see) and already defined with the drives /dev/hd[a-b].
> 
> If you know would create now there lets say a dir called "pub" he would
> create it on /dev/hda.
> We would put/cp now some files in that "pub" dir. He should still put it
> on /dev/hda:/pub (strange syntax but describes it ;)).
> When i know would create on my virtual device (lets call it VD) in VD:/pub
> a dir called "linux" he should put this dir "linux" on /dev/hdb:/linux.
> 
> If i would now ls VD:/ i would see just the dir "pub" like it should als
> be. If i change into pub my VG would know through the index file that
> "linux" is a subdir form "pub" and that "linux" is physicaly stored on
> /dev/hdb:linux.
> 
> It would simply doenst matter on which harddisk and with which fs the
> harddrive is formated with. The VD doesnt cares about this. It would make
> ti to me totaly transparent like LVM also doenst shows me where it stores
> what.
> 
> If now lets say /dev/hdb would fail i would still have the directorytree
> because i have these data in the index file on /dev/hda. The dirtree would
> be complete but all files which where on /dev/hdb would be lost but i
> would still have all data on /dev/hda and it would still run. Maybe i had
> to reboot coz the harddrive would stop the machine .. but well after i
> removed the failed harddrive from the VG i would have the rest still
> accessable. The VG could then remove the dirs out of the tree which where
> on /dev/hdb or i could simply mount /dev/hda and see whats on it but a
> little bit unsorted ;) so its maybe better to do it then over the VG.
> 
> Well thats my idea. I hope this time a little bit clearer.
> 
> OJ :)
> 
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm at sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen at Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-