diff for duplicates of <1297696565-sup-8163@think> diff --git a/a/1.txt b/N1/1.txt index d49aded..81f6b91 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,83 +1,61 @@ Excerpts from Andrew Lutomirski's message of 2011-02-11 19:35:02 -0500: -> On Fri, Feb 11, 2011 at 10:44 AM, Chris Mason <chris.mason@oracle.com= -> wrote: -> > Excerpts from Andrew Lutomirski's message of 2011-02-11 10:08:52 -0= -500: -> >> As I type this, I have an ssh process running that's dumping data = -into +> On Fri, Feb 11, 2011 at 10:44 AM, Chris Mason <chris.mason@oracle.com> wrote: +> > Excerpts from Andrew Lutomirski's message of 2011-02-11 10:08:52 -0500: +> >> As I type this, I have an ssh process running that's dumping data into > >> a fifo at high speed (maybe 500Mbps) and a tar process that's -> >> untarring from the same fifo onto btrfs. =C2=A0The btrfs fs is mou= -nted -o -> >> space_cache,compress. =C2=A0This machine has 8GB ram, 8 logical co= -res, and -> >> a fast (i7-2600) CPU, so it's not an issue with the machine strugg= -ling +> >> untarring from the same fifo onto btrfs. The btrfs fs is mounted -o +> >> space_cache,compress. This machine has 8GB ram, 8 logical cores, and +> >> a fast (i7-2600) CPU, so it's not an issue with the machine struggling > >> under load. > >> > >> Every few tens of seconds, my system stalls for several seconds. -> >> These stalls cause keyboard input to be lost, firefox to hang, etc= -=2E +> >> These stalls cause keyboard input to be lost, firefox to hang, etc. > >> -> >> Setting tar's ionice priority to best effort / 7 or to idle makes = -no difference. +> >> Setting tar's ionice priority to best effort / 7 or to idle makes no difference. > >> -> >> ionice idle and queue_depth =3D 1 on the disk (a slow 2TB WD) also= - makes +> >> ionice idle and queue_depth = 1 on the disk (a slow 2TB WD) also makes > >> no difference. > >> -> >> max_sectors_kb =3D 64 in addition to the above doesn't help either= -=2E +> >> max_sectors_kb = 64 in addition to the above doesn't help either. > >> -> >> latencytop shows regular instances of 2-7 *second* latency, variou= -sly +> >> latencytop shows regular instances of 2-7 *second* latency, variously > >> in sync_page, start_transaction, btrfs_start_ordered_extent, and > >> do_get_write_access (from jbd2 on my ext4 root partition). > >> -> >> echo 3 >drop_caches gave me 7 GB free RAM. =C2=A0I still had stall= -s when -> >> 4-5 GB were still free (so it shouldn't be a problem with importan= -t +> >> echo 3 >drop_caches gave me 7 GB free RAM. I still had stalls when +> >> 4-5 GB were still free (so it shouldn't be a problem with important > >> pages being evicted). > >> -> >> In case it matters, all of my partitions are on LVM on dm-crypt, b= -ut -> >> this machine has AES-NI so the overhead from that should be minima= -l. +> >> In case it matters, all of my partitions are on LVM on dm-crypt, but +> >> this machine has AES-NI so the overhead from that should be minimal. > >> In fact, overall CPU usage is only about 10%. > >> -> >> What gives? =C2=A0I thought this stuff was supposed to be better o= -n modern kernels. +> >> What gives? I thought this stuff was supposed to be better on modern kernels. > > -> > We can tell more if you post the full traces from latencytop. =C2=A0= -I have a -> > patch here for latencytop that adds a -c mode, which dumps the trac= -es +> > We can tell more if you post the full traces from latencytop. I have a +> > patch here for latencytop that adds a -c mode, which dumps the traces > > out to a text files. > > > > http://oss.oracle.com/~mason/latencytop.patch > > -> > Based on what you have here, I think it's probably a latency proble= -m -> > between btrfs and the dm-crypt stuff. =C2=A0How easily can setup a = -test +> > Based on what you have here, I think it's probably a latency problem +> > between btrfs and the dm-crypt stuff. How easily can setup a test > > partition without dm-crypt? ->=20 +> > Done, on the same physical disk as before. The latency is just as -> bad. On this test, I wrote a total of 3.1G, which is under half of m= -y -> RAM. That should rule out lots of VM issues. latencytop trace below= -=2E +> bad. On this test, I wrote a total of 3.1G, which is under half of my +> RAM. That should rule out lots of VM issues. latencytop trace below. Just to confirm, you say on a physical disk you mean without dm-crypt? ->=20 +> > The impression I get (from watching the disk activity light) is that > the disk is mostly idle but every now and then writes out a ton of > data. While it's writing, the system often becomes unusable. Could you please btrfs fi df /mnt (where /mnt is your test filesystem) ->=20 +> > P.S. How bad is this? I got it on both disks. > btrfs: free space inode generation (0) did not match free space cache > generation (11070) for block group 1103101952 @@ -109,8 +87,3 @@ you're still growing chunks to cover new writes. In this case the fsyncs done by firefox will lead to more expensive transaction commits. -chris --- -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 c4adda6..b661fcc 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -10,85 +10,63 @@ "\00:1\0" "b\0" "Excerpts from Andrew Lutomirski's message of 2011-02-11 19:35:02 -0500:\n" - "> On Fri, Feb 11, 2011 at 10:44 AM, Chris Mason <chris.mason@oracle.com=\n" - "> wrote:\n" - "> > Excerpts from Andrew Lutomirski's message of 2011-02-11 10:08:52 -0=\n" - "500:\n" - "> >> As I type this, I have an ssh process running that's dumping data =\n" - "into\n" + "> On Fri, Feb 11, 2011 at 10:44 AM, Chris Mason <chris.mason@oracle.com> wrote:\n" + "> > Excerpts from Andrew Lutomirski's message of 2011-02-11 10:08:52 -0500:\n" + "> >> As I type this, I have an ssh process running that's dumping data into\n" "> >> a fifo at high speed (maybe 500Mbps) and a tar process that's\n" - "> >> untarring from the same fifo onto btrfs. =C2=A0The btrfs fs is mou=\n" - "nted -o\n" - "> >> space_cache,compress. =C2=A0This machine has 8GB ram, 8 logical co=\n" - "res, and\n" - "> >> a fast (i7-2600) CPU, so it's not an issue with the machine strugg=\n" - "ling\n" + "> >> untarring from the same fifo onto btrfs. \302\240The btrfs fs is mounted -o\n" + "> >> space_cache,compress. \302\240This machine has 8GB ram, 8 logical cores, and\n" + "> >> a fast (i7-2600) CPU, so it's not an issue with the machine struggling\n" "> >> under load.\n" "> >>\n" "> >> Every few tens of seconds, my system stalls for several seconds.\n" - "> >> These stalls cause keyboard input to be lost, firefox to hang, etc=\n" - "=2E\n" + "> >> These stalls cause keyboard input to be lost, firefox to hang, etc.\n" "> >>\n" - "> >> Setting tar's ionice priority to best effort / 7 or to idle makes =\n" - "no difference.\n" + "> >> Setting tar's ionice priority to best effort / 7 or to idle makes no difference.\n" "> >>\n" - "> >> ionice idle and queue_depth =3D 1 on the disk (a slow 2TB WD) also=\n" - " makes\n" + "> >> ionice idle and queue_depth = 1 on the disk (a slow 2TB WD) also makes\n" "> >> no difference.\n" "> >>\n" - "> >> max_sectors_kb =3D 64 in addition to the above doesn't help either=\n" - "=2E\n" + "> >> max_sectors_kb = 64 in addition to the above doesn't help either.\n" "> >>\n" - "> >> latencytop shows regular instances of 2-7 *second* latency, variou=\n" - "sly\n" + "> >> latencytop shows regular instances of 2-7 *second* latency, variously\n" "> >> in sync_page, start_transaction, btrfs_start_ordered_extent, and\n" "> >> do_get_write_access (from jbd2 on my ext4 root partition).\n" "> >>\n" - "> >> echo 3 >drop_caches gave me 7 GB free RAM. =C2=A0I still had stall=\n" - "s when\n" - "> >> 4-5 GB were still free (so it shouldn't be a problem with importan=\n" - "t\n" + "> >> echo 3 >drop_caches gave me 7 GB free RAM. \302\240I still had stalls when\n" + "> >> 4-5 GB were still free (so it shouldn't be a problem with important\n" "> >> pages being evicted).\n" "> >>\n" - "> >> In case it matters, all of my partitions are on LVM on dm-crypt, b=\n" - "ut\n" - "> >> this machine has AES-NI so the overhead from that should be minima=\n" - "l.\n" + "> >> In case it matters, all of my partitions are on LVM on dm-crypt, but\n" + "> >> this machine has AES-NI so the overhead from that should be minimal.\n" "> >> In fact, overall CPU usage is only about 10%.\n" "> >>\n" - "> >> What gives? =C2=A0I thought this stuff was supposed to be better o=\n" - "n modern kernels.\n" + "> >> What gives? \302\240I thought this stuff was supposed to be better on modern kernels.\n" "> >\n" - "> > We can tell more if you post the full traces from latencytop. =C2=A0=\n" - "I have a\n" - "> > patch here for latencytop that adds a -c mode, which dumps the trac=\n" - "es\n" + "> > We can tell more if you post the full traces from latencytop. \302\240I have a\n" + "> > patch here for latencytop that adds a -c mode, which dumps the traces\n" "> > out to a text files.\n" "> >\n" "> > http://oss.oracle.com/~mason/latencytop.patch\n" "> >\n" - "> > Based on what you have here, I think it's probably a latency proble=\n" - "m\n" - "> > between btrfs and the dm-crypt stuff. =C2=A0How easily can setup a =\n" - "test\n" + "> > Based on what you have here, I think it's probably a latency problem\n" + "> > between btrfs and the dm-crypt stuff. \302\240How easily can setup a test\n" "> > partition without dm-crypt?\n" - ">=20\n" + "> \n" "> Done, on the same physical disk as before. The latency is just as\n" - "> bad. On this test, I wrote a total of 3.1G, which is under half of m=\n" - "y\n" - "> RAM. That should rule out lots of VM issues. latencytop trace below=\n" - "=2E\n" + "> bad. On this test, I wrote a total of 3.1G, which is under half of my\n" + "> RAM. That should rule out lots of VM issues. latencytop trace below.\n" "\n" "Just to confirm, you say on a physical disk you mean without dm-crypt?\n" "\n" - ">=20\n" + "> \n" "> The impression I get (from watching the disk activity light) is that\n" "> the disk is mostly idle but every now and then writes out a ton of\n" "> data. While it's writing, the system often becomes unusable.\n" "\n" "Could you please btrfs fi df /mnt (where /mnt is your test filesystem)\n" "\n" - ">=20\n" + "> \n" "> P.S. How bad is this? I got it on both disks.\n" "> btrfs: free space inode generation (0) did not match free space cache\n" "> generation (11070) for block group 1103101952\n" @@ -119,11 +97,6 @@ "you're still growing chunks to cover new writes. In this case the\n" "fsyncs done by firefox will lead to more expensive transaction commits.\n" "\n" - "-chris\n" - "--\n" - "To unsubscribe from this list: send the line \"unsubscribe linux-btrfs\" =\n" - "in\n" - "the body of a message to majordomo@vger.kernel.org\n" - More majordomo info at http://vger.kernel.org/majordomo-info.html + -chris -083d233e33d75073d7ce133254ba4f9eeaa6e474b1d706f6caec768dfbaa3335 +8952c6a177ebc97710647bf3dde1b14db4db38c9e2491fea54e278d02b01cb3a
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.