diff for duplicates of <4A61C4D5.6020707@redhat.com> diff --git a/a/1.txt b/N1/1.txt index 3787d8d..b55ad54 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,61 +1,50 @@ On 07/18/2009 07:53 AM, David Woodhouse wrote: > On Fri, 2009-07-17 at 11:49 -0400, H. Peter Anvin wrote: -> =20 +> >> Ric Wheeler wrote: ->> =20 ->>>> The bottom line is pretty much this: the cost of changing the enco= -ding ->>>> would appear to outweigh the benefit. I'm not trying to claim the = -Linux ->>>> RAID-6 implementation is optimal, but it is simple and appears to = -be +>> +>>>> The bottom line is pretty much this: the cost of changing the encoding +>>>> would appear to outweigh the benefit. I'm not trying to claim the Linux +>>>> RAID-6 implementation is optimal, but it is simple and appears to be >>>> fast enough that the math isn't the bottleneck. ->>>> =20 ->>> Cost? Thank about how to get free grad student hours testing out th= -ings +>>>> +>>> Cost? Thank about how to get free grad student hours testing out things >>> that you might or might not want to leverage on down the road :-) >>> ->>> =20 +>>> >> Cost, yes, of changing an on-disk format. ->> =20 +>> > -> Personally, I don't care about that -- I'm utterly uninterested in th= -e -> legacy RAID-6 setup where it pretends to be a normal disk. I think th= -at +> Personally, I don't care about that -- I'm utterly uninterested in the +> legacy RAID-6 setup where it pretends to be a normal disk. I think that > model is as fundamentally wrong as flash devices making the similar > pretence. > > 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. +> 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. > > The less I have to deal with Galois Fields, the happier I'll be. > -> =20 +> -I think that we are generally fine with the RAID5/6 support given a=20 -small number of drives. The fancier erasure encodings are much more=20 -interesting when you have a large number of drives - for example, we=20 -just ordered 4 shelves of SATA drives (15/shelf) that will be driven by= -=20 -a single server. You can certainly imagine profiling a lot of=20 +I think that we are generally fine with the RAID5/6 support given a +small number of drives. The fancier erasure encodings are much more +interesting when you have a large number of drives - for example, we +just ordered 4 shelves of SATA drives (15/shelf) that will be driven by +a single server. You can certainly imagine profiling a lot of interesting variations with that many things to play with. Ric -- -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 9b11bcd..09f02ae 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -24,64 +24,53 @@ "b\0" "On 07/18/2009 07:53 AM, David Woodhouse wrote:\n" "> On Fri, 2009-07-17 at 11:49 -0400, H. Peter Anvin wrote:\n" - "> =20\n" + "> \n" ">> Ric Wheeler wrote:\n" - ">> =20\n" - ">>>> The bottom line is pretty much this: the cost of changing the enco=\n" - "ding\n" - ">>>> would appear to outweigh the benefit. I'm not trying to claim the =\n" - "Linux\n" - ">>>> RAID-6 implementation is optimal, but it is simple and appears to =\n" - "be\n" + ">> \n" + ">>>> The bottom line is pretty much this: the cost of changing the encoding\n" + ">>>> would appear to outweigh the benefit. I'm not trying to claim the Linux\n" + ">>>> RAID-6 implementation is optimal, but it is simple and appears to be\n" ">>>> fast enough that the math isn't the bottleneck.\n" - ">>>> =20\n" - ">>> Cost? Thank about how to get free grad student hours testing out th=\n" - "ings\n" + ">>>> \n" + ">>> Cost? Thank about how to get free grad student hours testing out things\n" ">>> that you might or might not want to leverage on down the road :-)\n" ">>>\n" - ">>> =20\n" + ">>> \n" ">> Cost, yes, of changing an on-disk format.\n" - ">> =20\n" + ">> \n" ">\n" - "> Personally, I don't care about that -- I'm utterly uninterested in th=\n" - "e\n" - "> legacy RAID-6 setup where it pretends to be a normal disk. I think th=\n" - "at\n" + "> Personally, I don't care about that -- I'm utterly uninterested in the\n" + "> legacy RAID-6 setup where it pretends to be a normal disk. I think that\n" "> model is as fundamentally wrong as flash devices making the similar\n" "> pretence.\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" + "> 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" ">\n" "> The less I have to deal with Galois Fields, the happier I'll be.\n" ">\n" - "> =20\n" + "> \n" "\n" - "I think that we are generally fine with the RAID5/6 support given a=20\n" - "small number of drives. The fancier erasure encodings are much more=20\n" - "interesting when you have a large number of drives - for example, we=20\n" - "just ordered 4 shelves of SATA drives (15/shelf) that will be driven by=\n" - "=20\n" - "a single server. You can certainly imagine profiling a lot of=20\n" + "I think that we are generally fine with the RAID5/6 support given a \n" + "small number of drives. The fancier erasure encodings are much more \n" + "interesting when you have a large number of drives - for example, we \n" + "just ordered 4 shelves of SATA drives (15/shelf) that will be driven by \n" + "a single server. You can certainly imagine profiling a lot of \n" "interesting variations with that many things to play with.\n" "\n" "Ric\n" "\n" "\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 -a15d0346688ff657748d9b20ae031f3b6ed0b1061e300c5182ce39156c21ef31 +7e0a3c759ad9ca3f2f79dcd836cb6421e83d0fe8c2f7bbcf163a87b011a602af
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.