diff for duplicates of <20120306003716.GD4191@shiny> diff --git a/a/1.txt b/N1/1.txt index d39ab9f..8b4fc39 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -6,42 +6,30 @@ On Mon, Mar 05, 2012 at 12:32:45PM +0100, Jacek Luczak wrote: > >>>> 2012/3/2 Chris Mason <chris.mason@oracle.com>: > >>>> > On Fri, Mar 02, 2012 at 11:05:56AM +0100, Jacek Luczak wrote: > >>>> >> -> >>>> >> I've took both on tests. The subject is acp and spd_readdir u= -sed with +> >>>> >> I've took both on tests. The subject is acp and spd_readdir used with > >>>> >> tar, all on ext4: -> >>>> >> 1) acp: http://91.234.146.107/~difrost/seekwatcher/acp_ext4.p= -ng -> >>>> >> 2) spd_readdir: http://91.234.146.107/~difrost/seekwatcher/ta= -r_ext4_readir.png -> >>>> >> 3) both: http://91.234.146.107/~difrost/seekwatcher/acp_vs_sp= -d_ext4.png +> >>>> >> 1) acp: http://91.234.146.107/~difrost/seekwatcher/acp_ext4.png +> >>>> >> 2) spd_readdir: http://91.234.146.107/~difrost/seekwatcher/tar_ext4_readir.png +> >>>> >> 3) both: http://91.234.146.107/~difrost/seekwatcher/acp_vs_spd_ext4.png > >>>> >> -> >>>> >> The acp looks much better than spd_readdir but directory copy= - with +> >>>> >> The acp looks much better than spd_readdir but directory copy with > >>>> >> spd_readdir decreased to 52m 39sec (30 min less). > >>>> > -> >>>> > Do you have stats on how big these files are, and how fragment= -ed they -> >>>> > are? =A0For acp and spd to give us this, I think something has= - gone wrong +> >>>> > Do you have stats on how big these files are, and how fragmented they +> >>>> > are? For acp and spd to give us this, I think something has gone wrong > >>>> > at writeback time (creating individual fragmented files). > >>>> > >>>> How big? Which files? > >>> > >>> All the files you're reading ;) > >>> -> >>> filefrag will tell you how many extents each file has, any file w= -ith -> >>> more than one extent is interesting. =A0(The ext4 crowd may have = -better +> >>> filefrag will tell you how many extents each file has, any file with +> >>> more than one extent is interesting. (The ext4 crowd may have better > >>> suggestions on measuring fragmentation). > >>> -> >>> Since you mention this is a compile farm, I'm guessing there are = -a bunch -> >>> of .o files created by parallel builds. =A0There are a lot of cha= -nces for -> >>> delalloc and the kernel writeback code to do the wrong thing here= -=2E +> >>> Since you mention this is a compile farm, I'm guessing there are a bunch +> >>> of .o files created by parallel builds. There are a lot of chances for +> >>> delalloc and the kernel writeback code to do the wrong thing here. > >>> > >> > > [Most of files are B and K size] @@ -51,8 +39,7 @@ nces for > >> Total size of fragmented files: 7GB (~13% of dir size) Ok, so I don't have a lot of great new ideas. My guess is that inode -order and disk order for the blocks aren't matching up. You can confir= -m +order and disk order for the blocks aren't matching up. You can confirm this with: acp -b some_dir diff --git a/a/content_digest b/N1/content_digest index 6d26b18..0cd7859 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -27,42 +27,30 @@ "> >>>> 2012/3/2 Chris Mason <chris.mason@oracle.com>:\n" "> >>>> > On Fri, Mar 02, 2012 at 11:05:56AM +0100, Jacek Luczak wrote:\n" "> >>>> >>\n" - "> >>>> >> I've took both on tests. The subject is acp and spd_readdir u=\n" - "sed with\n" + "> >>>> >> I've took both on tests. The subject is acp and spd_readdir used with\n" "> >>>> >> tar, all on ext4:\n" - "> >>>> >> 1) acp: http://91.234.146.107/~difrost/seekwatcher/acp_ext4.p=\n" - "ng\n" - "> >>>> >> 2) spd_readdir: http://91.234.146.107/~difrost/seekwatcher/ta=\n" - "r_ext4_readir.png\n" - "> >>>> >> 3) both: http://91.234.146.107/~difrost/seekwatcher/acp_vs_sp=\n" - "d_ext4.png\n" + "> >>>> >> 1) acp: http://91.234.146.107/~difrost/seekwatcher/acp_ext4.png\n" + "> >>>> >> 2) spd_readdir: http://91.234.146.107/~difrost/seekwatcher/tar_ext4_readir.png\n" + "> >>>> >> 3) both: http://91.234.146.107/~difrost/seekwatcher/acp_vs_spd_ext4.png\n" "> >>>> >>\n" - "> >>>> >> The acp looks much better than spd_readdir but directory copy=\n" - " with\n" + "> >>>> >> The acp looks much better than spd_readdir but directory copy with\n" "> >>>> >> spd_readdir decreased to 52m 39sec (30 min less).\n" "> >>>> >\n" - "> >>>> > Do you have stats on how big these files are, and how fragment=\n" - "ed they\n" - "> >>>> > are? =A0For acp and spd to give us this, I think something has=\n" - " gone wrong\n" + "> >>>> > Do you have stats on how big these files are, and how fragmented they\n" + "> >>>> > are? \302\240For acp and spd to give us this, I think something has gone wrong\n" "> >>>> > at writeback time (creating individual fragmented files).\n" "> >>>>\n" "> >>>> How big? Which files?\n" "> >>>\n" "> >>> All the files you're reading ;)\n" "> >>>\n" - "> >>> filefrag will tell you how many extents each file has, any file w=\n" - "ith\n" - "> >>> more than one extent is interesting. =A0(The ext4 crowd may have =\n" - "better\n" + "> >>> filefrag will tell you how many extents each file has, any file with\n" + "> >>> more than one extent is interesting. \302\240(The ext4 crowd may have better\n" "> >>> suggestions on measuring fragmentation).\n" "> >>>\n" - "> >>> Since you mention this is a compile farm, I'm guessing there are =\n" - "a bunch\n" - "> >>> of .o files created by parallel builds. =A0There are a lot of cha=\n" - "nces for\n" - "> >>> delalloc and the kernel writeback code to do the wrong thing here=\n" - "=2E\n" + "> >>> Since you mention this is a compile farm, I'm guessing there are a bunch\n" + "> >>> of .o files created by parallel builds. \302\240There are a lot of chances for\n" + "> >>> delalloc and the kernel writeback code to do the wrong thing here.\n" "> >>>\n" "> >>\n" "> > [Most of files are B and K size]\n" @@ -72,8 +60,7 @@ "> >> Total size of fragmented files: 7GB (~13% of dir size)\n" "\n" "Ok, so I don't have a lot of great new ideas. My guess is that inode\n" - "order and disk order for the blocks aren't matching up. You can confir=\n" - "m\n" + "order and disk order for the blocks aren't matching up. You can confirm\n" "this with:\n" "\n" "acp -b some_dir\n" @@ -93,4 +80,4 @@ "\n" -chris -47c9cc5a86cdb7b90b9a4193b2af22fed43f48129f80b9630fccd0476b781e79 +d7b9edc04c4b080495c7c1472415775de676d0354baa17c8304c3b93655931e0
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.