Re: [PLUG] Lost gigabytes?

[John Karr <brainbuz@brainbuz.org>]

While I regret missing Lee's talk on ZFS, I would really love a good
talk on BTRFS, as it seems to be building a lot of momentum, and seems
like something I'm going to want to use at some point!

On Fri, 2011-12-09 at 19:05 -0500, Rich Freeman wrote: 
> 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


___________________________________________________________________________
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