On Sun, Sep 21, 2014 at 16:51:09 CEST, Sven Eschenberg wrote: > Hi Arno, > > On Sun, September 21, 2014 11:58, Arno Wagner wrote: > > On Sat, Sep 20, 2014 at 02:29:43 CEST, Sven Eschenberg wrote: > >> Well, it is not THAT easy. > > > > Actially it is. > > > >> If you want resilience/availability, you'll need RAID. Now what do you > >> put > >> ontop of the RAID when you need to slice it? > > > > And there the desaster starts: Don't slice RAID. It isnot a good > > idea. > > While in principle this is true, in practise you cannot have different > filesystems on the same RAID then in such a setup. So you'll need as many > RAIDs as filesystems. Which in turn means you will have to go for RAID on > partitions in respect to current disk sizes. Yes? So? Is there a problem anywhere here? > The second aspect I mentioned is spanning filesystems over RAIDs. The > reasonable number of disks in a single RAID is quite limited and as such > really huge filesystems need to span multiple RAIDs. I know, as long as > single files don't exceed the size of a reasonable RAID you could still > use multiple FSes. If you do huge storage installations, your needs change. This list kind of assumes as default that you stay in conventional sizes, say no more than 8 disks in an array. Things that you need to do for really large storage do not translate well to normal sizes. We can still discuss huge installations of course, but please mark this clearly, as users that never will have to deal with these may get confused and think it applies to them. My personal experience also ends at about 8 disks per RAID, as that was the maximum I could cram into my research servers and budget, so please take everything I say without qualification for storage size to be said in that context. Now, this is not meant in any way as discrimination against people that have to deal with huge storage volumes, please feel free to discuss anything you want here, but please always state that this is from a huge-storage perspective so as to not confuse people. The same applies when you talk about things needed to automatize changes for multiple machines, which again is not the "default" perspective for most people. There, I have a little more experience, as I had a cluster with 25 machines and that is already enough to not want to do anything manually. And of course, the possibility of EB-sized arrays with hundreds of disks does not justify putting LVM on a laptop with a single disk. One size does not fit all. > > > > > >> Put a disklabel/partition on > >> top of it and stick with a static setup or use LVM which can span > >> multiple > >> RAIDs (and types) supports snapshotting etc. . Depending on your needs > >> and > >> usage you will end up with LVM in the end. If you want encryption, > >> you'll > >> need a crypto layer (or you put it in the FS alongside volume slicing). > >> Partitions underaneath the RAID, not necessary if the RAID > >> implementation > >> can subslice physical devices and arrange for different levels on the > >> same > >> disk. Except unfortunately, when you need a bootloader. > >> > >> I don't see any alternative which would be KISS enough, except merging > >> the > >> layers to avoid collissions due to stacking order etc. . Simple usage > >> and > >> debugging for the user, but the actual single merged layer would be > >> anything but KISS. > > > > You miss one thing: LVM breaks layereing and rather badly so. That > > is a deadly sin. Partitioning should only ever been done on > > monolithic devices. There is a good reason for that, namely that > > parition-raid, filesystems and LUKS all respect partitioning per > > default, and hence it actually takes work to break the container > > structure. > > That is true, usually slicing, RAIDs and subvolumes are all part of the > RAID layer and as such RAID subvolumes are monolithic devices from an OS > point of view (read with HW-RAID HBAs). AFAIK with DDF metadata mdraid > takes this path and LVM could (except for spanning/snapshotting) be taken > out of the equation. One problem here is that dmraid on paritions is conceptually on the wrong layer compared to hardware RAID. But quite frankly, hardwre RAID never reached any reasonable degree of sophistication and was more of a "magic box" solution that yu could not look into. I do not think there is any problem doing RAID on partitions and not partitioning the array again, but it is different from what people used to hardware RAID expect. > > > > LVM rides all over that and hence it is absolutely no surprise > > at all that people keep breaking things using it. It is like > > a chainsaw without safety features. Until those safety-features > > are present and work reliably, LVM should be avoided in all > > situation where there is an alternative. There almost always is. > > > > I doubt you'll ever get foolproofness and sophistication/flexibility at > the same time, just look at cryptsetup and the libgcrypt/whirlpool issues. > Foolproof mostly means lack of choise or 'features' ;-). It is a balance. My take is that most people do not need the flexibility LVM gives them and at the sametime cannot really master its complexity, and then they end up sawing off a foot. There are cases where you do need it, I do not dispute that. But an ordinary, self-administrated end-user installation is not one of them. And yes, even the "chainsaw without safety features" has valid applications, but you will never, ever give it to a non-expert and you will only use it if there is no better way. > > But please, be my guest shooting yourself in the foot all > > you like. I will just not refrain from telling you "I told > > you so". > > In a way you are right, then again, at some point in time, you'll let kids > use forks, knives and fire, you know ;-). Indeed. But only when you see them being able to handle it. What I see happeingn is that people keep breaking things with LVM in situations where there was no need for it in the first place. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
