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. 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. > > >> 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. > > 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' ;-). > 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 ;-). > > > Arno > Regards -Sven >> Regards >> >> -Sven >> >> On Tue, September 16, 2014 10:07, Arno Wagner wrote: >> > On Tue, Sep 16, 2014 at 08:39:45 CEST, Heinz Diehl wrote: >> >> On 16.09.2014, Boylan, Ross wrote: >> >> >> >> > 1. Partition >> >> > 2. RAID >> >> > 3. LVM >> >> > 4. LUKS >> >> >> >> > That is decidedly too many. KISS is not even in the building >> >> > anymore with that. >> >> >> >> It is. Every single process does one thing. The problem is that most >> >> of the distributions out there automatically install LVM. In my case, >> >> I always chose four primary partitions manually, because they fit my >> >> needs and are simple to manage, while not adding more complexity than >> >> neccessary (/, /boot, /home, swap). >> > >> > The primary indicator that it is too complex is that debugging >> > this fails. There is siome modern "engineering" faction that >> > likes to pile up complexity until things start to fail. This is >> > a symptom. >> > >> > 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 >> > >> >> >> _______________________________________________ >> dm-crypt mailing list >> dm-crypt@xxxxxxxx >> http://www.saout.de/mailman/listinfo/dm-crypt > > -- > 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 > _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
