| |||||||||||||
Actually RAID/volume management is superlimited when not in filesystem...Actually RAID/volume management is superlimited when not in filesystem...Posted Jan 8, 2009 2:54 UTC (Thu) by Da_Blitz (subscriber, #50583)In reply to: Actually RAID/volume management is superlimited when not in filesystem... by khim Parent article: Btrfs aims for the mainline
you can do some of the thinks you mentioned with LVM
to keep most of the data on one partion you create a new pv with the vgcreate -p 1 <name> <dev> <dev>, -p limits the maximum amount of physical volumes for pv
while you cant do raid 5 in LVM (something i am assuming can be patched in) you can do RAID 1 using LVM with support for migrating the data from one drive to another should you remove or fail a drive, use lvcreate --mirrors 3 <volume name> <pvname>/-m
this will create one partition that is mirrored to 3 other drives
at the end you would end up with 2 volume groups, one for your DVDs that contains one lv partition and another volume group that includes all 4 drives that is replicated 4 times by lvm
i would pay for raid5 support in lvm as i could then specify different levels of replication for different partitions like you suggested,
(Log in to post comments)
I don't need volume groups! Posted Jan 8, 2009 3:48 UTC (Thu) by khim (subscriber, #9252) [Link] Yes, that's more or less how I do it today. But it's insane: I have a perfectly capable system developed to automate tasks, it can do billions of operations per second and yet it can not automagically reallocate space for me? Pathetic. Plus I want ALL metainformation keept on ALL drives: it's small amount of data, after all, and even if I can restore all files from DVDs it's certainly easier to do if I'll know what exactly was stored on that broken drive! Sure I can develop a lot of palliatives (I do ls -lR regularly and store it on RAIDed partition), but it's all ugly and stupid.
I don't need volume groups! Posted Jan 8, 2009 5:43 UTC (Thu) by Ze (guest, #54182) [Link] In reply to: Actually RAID/volume management is superlimited when not in filesystem... by Da_Blitz Parent article: Btrfs aims for the mainline Yes, that's more or less how I do it today. But it's insane: I have a perfectly capable system developed to automate tasks, it can do billions of operations per second and yet it can not automagically reallocate space for me? Pathetic. Plus I want ALL metainformation keept on ALL drives: it's small amount of data, after all, and even if I can restore all files from DVDs it's certainly easier toes, that's more or less how I do it today. But it's insane: I have a perfectly capable system developed to automate tasks, it can do billions of operations per second and yet it can not automagically reallocate space for me? Pathetic. Plus I want ALL metainformation keept on ALL drives: it's small amount of data, after all, and even if I can restore all files from DVDs it's certainly easier to do if I'll know what exactly was stored on that broken drive! Sure I can develop a lot of palliatives (I do ls -lR regularly and store it on RAIDed partition), but it's all ugly and stupid. do if I'll know what exactly was stored on that broken drive! So what you really want is one logical volume with arbitrary tags on block allocation and replication on a per file basis. Tux3 approach of keeping metadata information in normal files strikes me as being the nicest way to map meta-data onto multiple physical volumes. Perhaps in the future we'll handle proper separation of concerns when it comes to different layers properly instead of munging em all in one. The real bitch though with that is backward compatibility. Since we'd effectively be splitting existing file systems up into two separate concerns , a block format and a file system format composed of blocks.
|
|||||||||||||