Re: btrfs-RAID(3 or 5/6/etc) like btrfs-RAID1?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Feb 13, 2014 at 11:32:03AM -0500, Jim Salter wrote:
> That is FANTASTIC news.  Thank you for wielding the LART gently. =)

   No LART necessary. :) Nobody knows everything, and it's not a
particularly heavily-documented or written-about feature at the moment
(mostly because it only exists in Chris's local git repo).

> I do a fair amount of public speaking and writing about next-gen
> filesystems (example: http://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/)
> and I will be VERY sure to talk about the upcoming divorce of stripe
> size from array size in future presentations.  This makes me
> positively giddy.
> 
> FWIW, after writing the above article I got contacted by a
> proprietary storage vendor who wanted to tell me all about his
> midmarket/enterprise product, and he was pretty audibly flummoxed
> when I explained how btrfs-RAID1 distributes data and redundancy -
> his product does something similar (to be fair, his product also
> does a lot of other things btrfs doesn't inherently do, like
> clustered storage and synchronous dedup), and he had no idea that
> anything freely available did anything vaguely like it.

   That's quite entertaining for the bogglement factor. Although,
again, see my comment above...

   Hugo.

> I have a feeling the storage world - even the relatively
> well-informed part of it that's aware of ZFS - has little to no
> inclination how gigantic of a splash btrfs is going to make when it
> truly hits the mainstream.
> 
> >>This could be a pretty powerful setup IMO - if you implemented
> >>something like this, you'd be able to arbitrarily define your
> >>storage efficiency (percentage of parity blocks / data blocks) and
> >>your fault-tolerance level (how many drives you can afford to lose
> >>before failure) WITHOUT tying it directly to your underlying disks,
> >>or necessarily needing to rebalance as you add more disks to the
> >>array.  This would be a heck of a lot more flexible than ZFS'
> >>approach of adding more immutable vdevs.
> >>
> >>Please feel free to tell me why I'm dumb for either 1. not realizing
> >>the obvious flaw in this idea or 2. not realizing it's already being
> >>worked on in exactly this fashion. =)
> >    The latter. :)
> 

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
         --- Nothing right in my left brain. Nothing left in ---         
                             my right brain.                             

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux