Re: [PLUG] Lost gigabytes?

[Rich Freeman <r-plug@thefreemanclan.net>]

On Fri, Dec 9, 2011 at 4:49 PM, JP Vossen <jp@jpsdomain.org> wrote:
> If you also mirror disks (I do), then this is really nice because you can
> migrate to bigger disks while the system is running, except for 2 reboots
> for hardware swaps! I have done this a few times (e.g., 2010-11 for my
> MythTV server), it's awesome.

Yup - works for any RAID configuration with redundancy including RAID5.

Actually one of my gripes with ZFS (which could have changed since I
last checked) was that it didn't permit re-shaping RAID-Z (the COW
equivalent of RAID5).  Linux software raid does allow online resizing
of raid5.  Btrfs doesn't support RAID5 at all yet but I saw a patch on
the mailing list - probably doesn't support resizing yet unless it
just happens to work due to architecture.

Actually, btrfs's treatment of RAID is somewhat non-traditional - any
file can be treated differently with regard to raid - you can have 6
copies of one file and it will spread them out across as many disks as
it can (probably with more than one copy on a disk unless you have a
big array).  Everything is versioned and checksummed so if it can find
one good copy it can use it.  I don't know if striping is in the usual
style, or if it just chops the file up and stores the blocks on
multiple drives without regard to identical placement - in a mixed
raid0/1 setup I'd think anything else would be hard to keep in sync.
Likewise I don't know that RAID5 will use traditional stripes - maybe
it will.  In most lots-of-seeks access patterns I'm not sure the
stripes add more value than they take away - having to lay down a
whole stripe for one block is a waste and I imagine you'd run out of
free stripes quickly.  It makes more sense to me to just store the
raid5 mappings at the extent level and just say that extents x,y,z are
related.

> As I understand it, all of the LVM type stuff will eventually go away
> if/when btrfs goes fully production.  But that's years out, as discussed
> elsewhere.

Yup.  To answer Adam's question in his last email, however, LVM is a
perfectly acceptable configuration.  The main reason it doesn't get
used as much as it should be is its complexity, but since the newer
distro installers just install it by default you don't have to worry
about that much.  It is far more flexible than ordinary partitions.  I
did once run into an LVM bug of some kind (fscking one partition
caused data loss in another partition), but that was a long time ago.
It is pretty rare for that sort of thing to happen and I was having
problems with a flaky drive and the array constantly degrading - maybe
a write-hole issue.  Google suggested that a few others had seen the
problem as well: http://xkcd.com/979/

In theory btrfs will greatly reduce the need for LVM since it supports
subvolumes and is much more dynamic.  It doesn't really fit the exact
same feature set so I'm sure LVM won't completely go away.  However,
with btrfs it is easy to just add and remove devices from a volume,
and it will just move the data around.  It is a bit cludgy at the
moment since you need to trigger "rebalancing" things manually or you
end up with non-redundant data and such.

I've been trying to learn more of the internals of btrfs - if there is
interest I might give a talk on it.  If nothing else playing around
with it on a VM gave me occasion to figure out how to capture and
debug kernel core dumps (that isn't as trivial as it sounds, though
some distros automate it).

Rich
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug