On Sun, Jan 04, 2015 at 03:22:53AM +0000, Duncan wrote:
> sys.syphus posted on Sat, 03 Jan 2015 12:55:27 -0600 as excerpted:
> 
> >> But btrfs raid56 mode should be complete with kernel 3.19 and
> >> presumably btrfs-progs 3.19 tho I'd give it a kernel or two to mature
> >> to be sure. N-way-mirroring (my particular hotly awaited feature) is
> >> next up, but given the time raid56 took, I don't think anybody's
> >> predicting when it'll be actually in-tree and ready for use.
> >>
> >>
> > is that the feature where you say i want x copies of this file and y
> > copies of this other file? e.g. raid at the file level, with the ability
> > to adjust redundancy by file?
> 
> Per-file isn't available yet, tho at least per-subvolume is roadmapped, 
> and now that we have the properties framework working via xattr for files 
> as well, at least in theory, there is AFAIK no reason to limit it to per-
> subvolume, as per-file should be about as easy once the code that 
> currently limits it to per-filesystem is rewritten.

   "roadmapped" --> "fond wish".

   Also, per-file is a bit bloody awkward to get working. Having sat
and thought about it hard for a while, I'm not convinced that it would
actually be worth the implementation effort.

   Certainly, nobody should be thinking about having (say) a different
RAID config for every file -- that way lies madness. I would expect,
at most, "small integers" (<=3) of different profiles for data in any
given filesystem, with the majority of data being of one particular
profile. Anything trying to get more spohisticated than that is likely
asking for intractable space-allocation problems. Think, "requiring
regular full-balance operations".

   The behaviour of the chunk allocator in the presence of merely two
allocation profiles (data/metadata) is awkward enough. Introducing
more of them is something that will require a separate research
programme to understand fully.

   I will probably have an opportunity to discuss the basics of
multiple allocations schemes with someone more qualified than I am on
Tuesday, but I doubt that we'll reach any firm conclusion for many
months at best (if ever). The formal maths involved gets quite nasty,
quite quickly.

   Hugo.

> But actually fully working per-filesystem raid56 is enough for a lot of 
> people, and actually working per-filesystem N-way-mirroring is what I'm 
> after, since I already setup multiple filesystems in ordered to keep my 
> data eggs from all being in the same filesystem basket.
> 

-- 
Hugo Mills             | If it's December 1941 in Casablanca, what time is it
hugo@... carfax.org.uk | in New York?
http://carfax.org.uk/  |
PGP: 65E74AC0          |                               Rick Blaine, Casablanca