Date: Mon, 17 Oct 2016 06:46:18 +0000 (UTC) From: LinkedIn Security <security-noreply@linkedin.com> To: =?UTF-8?Q?Eduardo_Morr=C3=A1s?= <freebsd-geom@freebsd.org> Subject: Eduardo, your password was successfully reset Message-ID: <1197183931.339178.1476686778004.JavaMail.app@ltx1-app5241.prod.linkedin.com>
next in thread | raw e-mail | index | archive | help
Hi Eduardo, You've successfully changed your LinkedIn password. Thanks for using LinkedIn! The LinkedIn Team When and where this happened: Date:October 17, 2016, 8:46 AM Browser:Firefox Operating System:BSD Approximate Location:Baranain, Navarre, Spain Didn't do this? Be sure to change your password right away: https://www.lin= kedin.com/e/v2?e=3D4mcl8b-iudp6fo2-po&a=3Duas-request-password-reset&midTok= en=3DAQEFaL8h98sJTg&ek=3Dsecurity_reset_password_notification © 2016 LinkedIn Ireland Limited. LinkedIn, the LinkedIn logo, and InMa= il are registered trademarks of LinkedIn Corporation in the United States a= nd/or other countries. All rights reserved. This email was intended for Eduardo Morr=C3=A1s (.).=20 Learn why we included this: https://www.linkedin.com/e/v2?e=3D4mcl8b-iudp6f= o2-po&a=3DcustomerServiceUrl&midToken=3DAQEFaL8h98sJTg&ek=3Dsecurity_reset_= password_notification&articleId=3D4788 If you need assistance or have questions, please contact LinkedIn Customer = Service: https://www.linkedin.com/e/v2?e=3D4mcl8b-iudp6fo2-po&a=3DcustomerS= erviceUrl&midToken=3DAQEFaL8h98sJTg&ek=3Dsecurity_reset_password_notificati= on LinkedIn is a registered business name of LinkedIn Ireland Limited. Registered in Ireland as a private limited company, Company Number 477441 Registered Office: Wilton Plaza, Wilton Place, Dublin 2, Ireland From owner-freebsd-geom@freebsd.org Mon Oct 17 22:13:23 2016 Return-Path: <owner-freebsd-geom@freebsd.org> Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3DACCC151DE for <freebsd-geom@mailman.ysv.freebsd.org>; Mon, 17 Oct 2016 22:13:23 +0000 (UTC) (envelope-from 1983-01-06@gmx.net) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A468D96F for <freebsd-geom@freebsd.org>; Mon, 17 Oct 2016 22:13:22 +0000 (UTC) (envelope-from 1983-01-06@gmx.net) Received: from [192.168.1.8] ([79.247.126.144]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MUoma-1cS7vx37Ma-00YCSw for <freebsd-geom@freebsd.org>; Tue, 18 Oct 2016 00:13:13 +0200 Subject: Re: Abysmally slow write to geom class volume over network To: freebsd-geom@freebsd.org References: <33da0f73-48f1-4727-fe76-41343dc4955b@gmx.net> <18314f27-849b-31df-d88d-af64e89c133f@gmx.net> <346c7da7-02b2-ba34-1463-f3f0a5a3cd9a@rlwinm.de> <15e9cb94-7ad8-e547-b06a-699ce2250624@gmx.net> <20161013014143.GA1669@funkthat.com> <636763f0-a732-18ba-262b-c3fc01f4342c@gmx.net> <20161014114330.396fe534@fabiankeil.de> <5a12f70d-3488-e799-b875-9b358ef7aff9@gmx.net> <20161015132249.607b374c@fabiankeil.de> From: Michael Osipov <1983-01-06@gmx.net> Message-ID: <4e20df2e-9e9f-cdfd-5ad5-712cc9859890@gmx.net> Date: Tue, 18 Oct 2016 00:13:09 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161015132249.607b374c@fabiankeil.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Ytx0bRYR7Zf66gI2DQes7I4un5ahqwrDlnFUwD/enWHAJU4davs 7Pl19hkf6VGFCOW9lKBUra+T+zDHYGzve9mLsMR6e3NqzIHTKR3tumM6nuHZYXNwSFMPAUj MZswvAYqzcdcplUO6T8+BiddxZU24cYgngm9Qtt5Y4nLL8QyoL3SllnHPMs0K/fCBrbkS87 ABcP3pn4/nLQaK+n50SpA== X-UI-Out-Filterresults: notjunk:1;V01:K0:f+8qAHpq5UQ=:Iqjvrhw515+9nJoFsFZnwA 57uMbD4Y/k2PJ2XMQHiuNeT+YaKXFp+pQ1GY5oJuoZ27qgDJXCCQLNmjq4vCrRg7Uu7PX/D5r p6/HVTiJj2PLP7TdCRYR1rJjUfK1kqAyAY4A7msfntFD0y6MUb6lCCmcJPoU4xj1joVKuxscm Skt/LJegJ1eIwRYizkTBDKTo7xWsxWNpYV9S4n0hRFPY41yIWw5GWu8lhLrxJyO107DeJKUA0 NcUjkbjdRSYVTfcqFZkxW+QWrdfTapeEpdz7aiql1YlnUBc8QxqKPKgAa1yHOEIrbfAPDDjEB KDuqJ5aCZFN5njG/KcKzHEkLpsEidRrftAxcgZQEk/XMxc0P6rqW/KZfK0rTyTqfBaHB2dHBG mu0v4KJuaZbUpYL4KWaWs13uufNLQPTscdYP76Ocl0+KKqcThtGBuFLd/GRN5GT5pZTgVemi1 0dcde2McG5JwAYthyNscrCVlSk6Q1hT3pS1AIwxibWFR2y6doi8EFsotbW8fFk/yMIvfsfES/ MKzJI8KoiznbrWJoY9rQ/dksCQhBO1vuyyURZVb5L+KIzXzLFbUYTG9RkAExGKADPw1M1fxD2 EOWWohq0yqSrzFHmm93yOk74q7WJk1wa3X/3xRVUsoT/KsCPresPntKhI4cBplHrHalROMezc 7VY55baIGYvBEfX6OhYL4R704++tmqImQly/OzXOUAUpCmWOJvrBCPp1MAOKRdpO8Ik22jkS+ hrPIAwPVi/UHSvSIzd3Xv/59HJ9r79UmHq4Q2wtDV2FDRKls15QYj4QkXIoA8039OXMi6nPtf VTz6Qb4 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: GEOM-specific discussions and implementations <freebsd-geom.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-geom>, <mailto:freebsd-geom-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-geom/>; List-Post: <mailto:freebsd-geom@freebsd.org> List-Help: <mailto:freebsd-geom-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-geom>, <mailto:freebsd-geom-request@freebsd.org?subject=subscribe> X-List-Received-Date: Mon, 17 Oct 2016 22:13:23 -0000 Am 2016-10-15 um 13:22 schrieb Fabian Keil: > Michael Osipov <1983-01-06@gmx.net> wrote: > >> Am 2016-10-14 um 11:43 schrieb Fabian Keil: >>> Michael Osipov <1983-01-06@gmx.net> wrote: >>> >>>> Am 2016-10-13 um 03:41 schrieb John-Mark Gurney: >>>>> Michael Osipov wrote this message on Wed, Oct 12, 2016 at 20:54 >>>>> +0200: >>>>>> As if there is a bottleneck between socket read and geom write to >>>>>> FS. >>>>>> >>>>>> Is that better? >>>>> >>>>> Have you run gstat on the system to see if there is an IO bottle >>>>> neck? Since you are using graid3, you want to look to see if >>>>> it's %busy is ~100, while the underlying components are not. >>>> >>>> This is hardly impossible because as soon as I start some SFTP >>>> transfer, all of my SSH sessions free or receive connetion >>>> timeout/abort. Doing a SFTP from FreeBSD to FreeBSD gives me on both >>>> physical disks and RAID3 volume a busy of zero to one perfect. In >>>> other terms, the drives are bored. >>> >>> Try checking the FAIL and SLEEP columns in the "vmstat -z" output. >> >> I assume that you expect a rise on those numbers. I have made several >> runs. Rebooted the machine and then started SFTP transfer. After seconds >> my SSH sessions locked up. The transfer was aborted manually after 10 >> minutes which should have saturated the entire connection. After that, I >> reran vmstat -z, no or minimal rise in FAIL and SLEEP. > > IIRC the SLEEP column only showns currently sleeping requests, > therefore you may want to run "vmstat -z" multiple times while > the transfer is ongoing. Having said that, a custom DTrace script > would probably be a better tool to diagnose the issue anyway. > >> Interesting to say that this happens if is is a UFS volume on >> gconcat/graid3/gvinum/gstripe configuration. Regular gpart with GPT has >> no performance penalty. Additionally, it is not limited to SSH but >> virtually everything with sockets: nc, ggate, smb. >> >>> This could be related to: >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209680#c2 >> >> It pretty much sounds like it, though I do not use ipfw, pf or any NAT >> stuff. I will try your first patch and let you know. >> >> Do you want me to add my usecase to the issue? > > If the patch helps, that could be useful once a committer > finds the time to look at the PR. Just finished testing your patch. Switched to 11-STABLE. First tests were w/o the patch: 1. gstripe, slow, SSH connection drops 2. graid3, slow, SSH connection drops 3. raidz, varies from 6 to 11 MB/s, SSH responding, CPU is at maximum. zfs is too much for this machine. Tests with the patch: absolutely no change. All three tests yielded to the same results. It is not a socket-related issue I think. If zfs works w/o dropouts after several gigabytes, it must be some geom class bug causing this. I am back where I was: at the beginning of the quest. Unless someone else has a good idea, I will bury any multidisk geom class and will likely resort to plain GPT with UFS SU+J partitions. zfs is probably is not an option on this old Pentium 4 machine. Michael
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1197183931.339178.1476686778004.JavaMail.app>