From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 11:43:25 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90F9778D for ; Thu, 5 Feb 2015 11:43:25 +0000 (UTC) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 44D49D2B for ; Thu, 5 Feb 2015 11:43:24 +0000 (UTC) Received: by mail-vc0-f178.google.com with SMTP id im6so1256124vcb.9 for ; Thu, 05 Feb 2015 03:43:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=lnea0gkrqzi+yqwiteErtxf18Xq3uMt/YC339HXyS7E=; b=T87rGDck7fx8QtGONPGz2Rr3Lau0R8tgySfAYKWeGROhXd4/JgrrMNnSDWPLGNyvF/ 9af47HvQ5rT9lB+VgI04jrP42IAoauV4CElFoS0K88W6lmd+jPQx003k1mp486hzw6Bg C+RF5QRY1V5jQFRdlGU8NE0mTAHlqFyPT9EnVUQX7udIi01r3WUsl5xH/cRLsL3BpFSM Vsh5DJczRBOWBs6zqPAn+zp8U3dfT81pVcX4ql6JrO2RmKbt7uIlprWx0/As1N8bw10i AUNbIeFA7mVhlZ1o6aPihsupu7Od3i0F/tkjzrjBb66rRNYgn9aGXWBi0uKAG1qWzNk0 YXGw== X-Gm-Message-State: ALoCoQmoJN0eFjw7JX/aXNXpxiQbBA3K0zjKvTzTfjbpjfZAlHrD3ufg0oaLFzUenM0nOUmnF+hiVFH8K64Wph5Pajgm+THqhBpkApqrGGayXtu8nHM3Cicm2HOdstaUinPXNvyqfxEM X-Received: by 10.52.136.98 with SMTP id pz2mr1473350vdb.26.1423130654280; Thu, 05 Feb 2015 02:04:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.128.165 with HTTP; Thu, 5 Feb 2015 02:03:57 -0800 (PST) In-Reply-To: References: <54D2C3DA.4060205@freebsd.org> <54D319EA.5020709@freebsd.org> <20150205083035.GF42409@kib.kiev.ua> <54D32DC3.6020409@mu.org> <20150205090324.GI42409@kib.kiev.ua> From: "Lundberg, Johannes" Date: Thu, 5 Feb 2015 19:03:57 +0900 Message-ID: Subject: Re: Weird behavior writing to SSD on 2013 MacBook To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Konstantin Belousov , FreeBSD Current , Dimitry Andric , Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 11:43:25 -0000 It seems like the patch solved my problem. No more freezing of the filesystem. -- Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Thu, Feb 5, 2015 at 6:19 PM, Alfred Perlstein wrote: > It's possible original intent of that construct was just a pause/throttle > if it used to be an if(). Makes sense although should investigate further= . > > Sent from my iPhone > > > On Feb 5, 2015, at 1:03 AM, Konstantin Belousov > wrote: > > > >> On Thu, Feb 05, 2015 at 12:45:55AM -0800, Alfred Perlstein wrote: > >> > >> > >>> On 2/5/15 12:30 AM, Konstantin Belousov wrote: > >>>> On Thu, Feb 05, 2015 at 08:56:59AM +0100, Dimitry Andric wrote: > >>>> If you let bsdtar continue, and press control-T a few times, does th= e > >>>> user time (u) increase at all? Does it ever go any further, if you > let > >>>> it run for a very long time? > >>>> > >>>> I believe a problem may have been introduced by r277922, leading to > >>>> filesystem hangs in some scenarios. It looks like this commit is al= so > >>>> in dumbbell's github fork: > >>>> > >>>> > https://github.com/dumbbell/freebsd/commit/83723416a6bb8695d60c6573722a81= 086899f521 > >>> > >>> Would be nice if you mailed me with your findings. > >>> > >>> Please try this. > >>> > >>> diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c > >>> index 79783c8..700854e 100644 > >>> --- a/sys/ufs/ffs/ffs_softdep.c > >>> +++ b/sys/ufs/ffs/ffs_softdep.c > >>> @@ -1393,7 +1393,7 @@ softdep_flush(addr) > >>> VFSTOUFS(mp)->softdep_jblocks->jb_suspended)) > >>> kthread_suspend_check(); > >>> ACQUIRE_LOCK(ump); > >>> - while ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) = =3D=3D > 0) > >>> + if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) =3D= =3D 0) > >>> msleep(&ump->softdep_flushtd, LOCK_PTR(ump), PVM, > >>> "sdflush", hz / 2); > >>> ump->softdep_flags &=3D ~FLUSH_CLEANUP; > >>> @@ -1423,10 +1423,9 @@ worklist_speedup(mp) > >>> > >>> ump =3D VFSTOUFS(mp); > >>> LOCK_OWNED(ump); > >>> - if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=3D 0= ) { > >>> + if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=3D 0= ) > >>> ump->softdep_flags |=3D FLUSH_CLEANUP; > >>> - wakeup(&ump->softdep_flushtd); > >>> - } > >>> + wakeup(&ump->softdep_flushtd); > >>> } > >>> > >>> static int > >>> @@ -1471,11 +1470,10 @@ softdep_speedup(ump) > >>> TAILQ_INSERT_TAIL(&softdepmounts, sdp, sd_next); > >>> FREE_GBLLOCK(&lk); > >>> if ((altump->softdep_flags & > >>> - (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=3D 0) { > >>> + (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=3D 0) > >>> altump->softdep_flags |=3D FLUSH_CLEANUP; > >>> - altump->um_softdep->sd_cleanups++; > >>> - wakeup(&altump->softdep_flushtd); > >>> - } > >>> + altump->um_softdep->sd_cleanups++; > >>> + wakeup(&altump->softdep_flushtd); > >>> FREE_LOCK(altump); > >>> } > >>> } > >>> _______________________________________________ > >> > >> Why the conversion of while() to if()? > >> > >> > >> The reason for a while() when doing msleep/wakeup is typically to > >> prevent superfluous wakeups from signalling early. > > > > if()->while() was one of the changes in r277922, and I suspect that it > > is the cause of the issue. I.e. my thought right now is that > > softdep_process_worklist() does not keep up with the requests. > > > > If this is true, then real fix is somewhere else, but restoring > > pre-r277922 behaviour should get rid of immediate pain. > > > --=20 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- =E7=A7=98=E5=AF=86=E4=BF=9D=E6=8C=81=E3=81=AB=E3=81=A4=E3=81=84=E3=81=A6=EF= =BC=9A=E3=81=93=E3=81=AE=E9=9B=BB=E5=AD=90=E3=83=A1=E3=83=BC=E3=83=AB=E3=81= =AF=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E3=81=AB=E9=80=81=E4=BF=A1=E3=81=97= =E3=81=9F=E3=82=82=E3=81=AE=E3=81=A7=E3=81=82=E3=82=8A=E3=80=81=E7=A7=98=E5= =8C=BF=E7=89=B9=E6=A8=A9=E3=81=AE=E5=AF=BE=E8=B1=A1=E3=81=A8=E3=81=AA=E3=82= =8B=E6=83=85=E5=A0=B1=E3=82=92=E5=90=AB=E3=82=93=E3=81=A7=E3=81=84=E3=81=BE= =E3=81=99=E3=80=82 =E3=82=82=E3=81=97=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E4=BB=A5=E5=A4=96=E3= =81=AE=E6=96=B9=E3=81=8C=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5=A0= =B4=E5=90=88=E3=80=81=E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AE= =E7=A0=B4=E6=A3=84=E3=80=81=E3=81=8A=E3=82=88=E3=81=B3=E3=81=93=E3=81=AE=E3= =83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E9=96=A2=E3=81=99=E3=82=8B=E4=B8=80=E5=88= =87=E3=81=AE=E9=96=8B=E7=A4=BA=E3=80=81 =E8=A4=87=E5=86=99=E3=80=81=E9=85=8D=E5=B8=83=E3=80=81=E3=81=9D=E3=81=AE=E4= =BB=96=E3=81=AE=E5=88=A9=E7=94=A8=E3=80=81=E3=81=BE=E3=81=9F=E3=81=AF=E8=A8= =98=E8=BC=89=E5=86=85=E5=AE=B9=E3=81=AB=E5=9F=BA=E3=81=A5=E3=81=8F=E3=81=84= =E3=81=8B=E3=81=AA=E3=82=8B=E8=A1=8C=E5=8B=95=E3=82=82=E3=81=95=E3=82=8C=E3= =81=AA=E3=81=84=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81= =97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82 --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message.