diff for duplicates of <4A61C3D9.6020200@zytor.com> diff --git a/a/1.txt b/N1/1.txt index 2a120c3..a62d5ba 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,47 +1,38 @@ David Woodhouse wrote: ->=20 +> > I'm only interested in what we can use directly within btrfs -- and > ideally I do want something which gives me an _arbitrary_ number of -> redundant blocks, rather than limiting me to 2. But the legacy code i= -s -> good enough for now=C2=B9. ->=20 +> redundant blocks, rather than limiting me to 2. But the legacy code is +> good enough for now¹. +> > When I get round to wanting more, I was thinking of lifting something -> like http://git.infradead.org/mtd-utils.git?a=3Dblob;f=3Dfec.c to sta= -rt -> with, and maybe hoping that someone cleverer will come up with someth= -ing +> like http://git.infradead.org/mtd-utils.git?a=blob;f=fec.c to start +> with, and maybe hoping that someone cleverer will come up with something > better. ->=20 +> > The less I have to deal with Galois Fields, the happier I'll be. ->=20 +> -Well, if you want something with more than 2-block redundancy you need=20 -something other than the existing RAID-6 code which, as you know, is a=20 -special case of general Reed-Solomon coding that I happen to have spent= -=20 -a lot of time optimizing. The FEC code is not optimized at all if I ca= -n=20 -tell, and certainly doesn't use SSE in any way -- never mind the GF=20 -accelerators that are starting to appear. That doesn't mean it=20 -*couldn't*, just that noone has done the work to either implement it or= -=20 +Well, if you want something with more than 2-block redundancy you need +something other than the existing RAID-6 code which, as you know, is a +special case of general Reed-Solomon coding that I happen to have spent +a lot of time optimizing. The FEC code is not optimized at all if I can +tell, and certainly doesn't use SSE in any way -- never mind the GF +accelerators that are starting to appear. That doesn't mean it +*couldn't*, just that noone has done the work to either implement it or prove it can't be done. -Either way, perhaps the Plank paper that Rik pointed to could be useful= -=20 -as a starting point; it's probably worth taking their performance=20 -numbers with a *major* grain of salt: their implementation of RAID-6=20 +Either way, perhaps the Plank paper that Rik pointed to could be useful +as a starting point; it's probably worth taking their performance +numbers with a *major* grain of salt: their implementation of RAID-6 "RS-Opt" which is supposed to be equivalent to my code performs at -400 MB/s, which is less than Pentium III-era performance of the real=20 -world code (they compare not to real code but to their own=20 -implementation in Java, called "Jerasure".) Implementability using rea= -l=20 +400 MB/s, which is less than Pentium III-era performance of the real +world code (they compare not to real code but to their own +implementation in Java, called "Jerasure".) Implementability using real array instruction sets is key to decent performance. -hpa -- -To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = -in +To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N1/content_digest index 5da0312..acc3c69 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -21,51 +21,42 @@ "\00:1\0" "b\0" "David Woodhouse wrote:\n" - ">=20\n" + "> \n" "> I'm only interested in what we can use directly within btrfs -- and\n" "> ideally I do want something which gives me an _arbitrary_ number of\n" - "> redundant blocks, rather than limiting me to 2. But the legacy code i=\n" - "s\n" - "> good enough for now=C2=B9.\n" - ">=20\n" + "> redundant blocks, rather than limiting me to 2. But the legacy code is\n" + "> good enough for now\302\271.\n" + "> \n" "> When I get round to wanting more, I was thinking of lifting something\n" - "> like http://git.infradead.org/mtd-utils.git?a=3Dblob;f=3Dfec.c to sta=\n" - "rt\n" - "> with, and maybe hoping that someone cleverer will come up with someth=\n" - "ing\n" + "> like http://git.infradead.org/mtd-utils.git?a=blob;f=fec.c to start\n" + "> with, and maybe hoping that someone cleverer will come up with something\n" "> better.\n" - ">=20\n" + "> \n" "> The less I have to deal with Galois Fields, the happier I'll be.\n" - ">=20\n" + "> \n" "\n" - "Well, if you want something with more than 2-block redundancy you need=20\n" - "something other than the existing RAID-6 code which, as you know, is a=20\n" - "special case of general Reed-Solomon coding that I happen to have spent=\n" - "=20\n" - "a lot of time optimizing. The FEC code is not optimized at all if I ca=\n" - "n=20\n" - "tell, and certainly doesn't use SSE in any way -- never mind the GF=20\n" - "accelerators that are starting to appear. That doesn't mean it=20\n" - "*couldn't*, just that noone has done the work to either implement it or=\n" - "=20\n" + "Well, if you want something with more than 2-block redundancy you need \n" + "something other than the existing RAID-6 code which, as you know, is a \n" + "special case of general Reed-Solomon coding that I happen to have spent \n" + "a lot of time optimizing. The FEC code is not optimized at all if I can \n" + "tell, and certainly doesn't use SSE in any way -- never mind the GF \n" + "accelerators that are starting to appear. That doesn't mean it \n" + "*couldn't*, just that noone has done the work to either implement it or \n" "prove it can't be done.\n" "\n" - "Either way, perhaps the Plank paper that Rik pointed to could be useful=\n" - "=20\n" - "as a starting point; it's probably worth taking their performance=20\n" - "numbers with a *major* grain of salt: their implementation of RAID-6=20\n" + "Either way, perhaps the Plank paper that Rik pointed to could be useful \n" + "as a starting point; it's probably worth taking their performance \n" + "numbers with a *major* grain of salt: their implementation of RAID-6 \n" "\"RS-Opt\" which is supposed to be equivalent to my code performs at\n" - "400 MB/s, which is less than Pentium III-era performance of the real=20\n" - "world code (they compare not to real code but to their own=20\n" - "implementation in Java, called \"Jerasure\".) Implementability using rea=\n" - "l=20\n" + "400 MB/s, which is less than Pentium III-era performance of the real \n" + "world code (they compare not to real code but to their own \n" + "implementation in Java, called \"Jerasure\".) Implementability using real \n" "array instruction sets is key to decent performance.\n" "\n" "\t-hpa\n" "--\n" - "To unsubscribe from this list: send the line \"unsubscribe linux-btrfs\" =\n" - "in\n" + "To unsubscribe from this list: send the line \"unsubscribe linux-btrfs\" in\n" "the body of a message to majordomo@vger.kernel.org\n" More majordomo info at http://vger.kernel.org/majordomo-info.html -f51f93d4e64b379b670854d60fd078d8c15a1705c7acb3d92c1dcc8bc1840145 +508708050515a044863bc880726590c7d7eafd7d8e56d541de9167c3c5b0e393
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.