[ale] Topic ideas for November meeting

DJ-Pfulio DJPfulio at jdpfu.com
Mon Nov 2 18:46:20 EST 2015


My rules on this are simple.
a) ALWAYs use LVM on physical systems.
b) NEVER use LVM on VM storage (inside the VM).

In 20+ years,  I've never been able to guess correctly the amount of
storage needed for any specific partition. Being able to resize LVs
without rebooting is FANTASTIC! That's just 1 little thing. There are
many others. I love that formatting an LV with ext4 is basically
instantaneous, regardless of the amount of storage.

In this I equate LVM == ZFS == BTRFS. Enhanced volume management is the
goal. No need to be tied to some hardware limitation that MBR or even
GPT force onto us.


On 11/02/2015 05:28 PM, Steve Litt wrote:
> On Mon, 2 Nov 2015 22:00:47 +0000
> "Lightner, Jeff" <JLightner at dsservices.com> wrote:
> 
>> Maybe a presentation on why to use (or not use) simple partitioning
>> vs. metadisk software RAID vs. LVM.
> 
> I wish I could be there. I'd argue for simplicity (simple partitioning)
> *unless* a disk crash would totally ruin your day (in which case RAID)
> or if there's some reason that every year or so you can't resize
> partitions (probably on a newer, larger disk that will be available by
> that time), in which case of course you should use LVM.
> 
> From what I understand (I'll probably be corrected on this), the
> easiest way to encrypt disk content is with LVM, so that would be a use
> case for LVM too.
> 
> I guess what I'm saying is this: If one doesn't need the benefits
> bestowed by RAID, nor the benefits bestowed by LVM, then use simple
> partitioning. It's simpler. It leads to simpler initramfs. It's very
> robust if you use a good one. I use Ext4, and it never lets me down,
> and it has all the fixit tools you need. And if something goes wrong,
> you can pop in a System Rescue CD and ship the data over the wire to
> another computer, or send it to another disk.
> 
> Another debate, within simple partitioning, might be Ext4 vs btrfs vs
> zfs. I'd love to listen to *that* debate.
> 


More information about the Ale mailing list