Re: Weird behavior writing to SSD on 2013 MacBook

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 <bright_at_mu.org> 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 <kostikbel_at_gmail.com>
> 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 the
> >>>> 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 also
> >>>> in dumbbell's github fork:
> >>>>
> >>>>
> https://github.com/dumbbell/freebsd/commit/83723416a6bb8695d60c6573722a81086899f521
> >>>
> >>> 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
> >>> _at__at_ -1393,7 +1393,7 _at__at_ softdep_flush(addr)
> >>>              VFSTOUFS(mp)->softdep_jblocks->jb_suspended))
> >>>              kthread_suspend_check();
> >>>          ACQUIRE_LOCK(ump);
> >>> -        while ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) ==
> 0)
> >>> +        if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) == 0)
> >>>              msleep(&ump->softdep_flushtd, LOCK_PTR(ump), PVM,
> >>>                  "sdflush", hz / 2);
> >>>          ump->softdep_flags &= ~FLUSH_CLEANUP;
> >>> _at__at_ -1423,10 +1423,9 _at__at_ worklist_speedup(mp)
> >>>
> >>>      ump = VFSTOUFS(mp);
> >>>      LOCK_OWNED(ump);
> >>> -    if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) == 0) {
> >>> +    if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) == 0)
> >>>          ump->softdep_flags |= FLUSH_CLEANUP;
> >>> -        wakeup(&ump->softdep_flushtd);
> >>> -    }
> >>> +    wakeup(&ump->softdep_flushtd);
> >>>  }
> >>>
> >>>  static int
> >>> _at__at_ -1471,11 +1470,10 _at__at_ softdep_speedup(ump)
> >>>              TAILQ_INSERT_TAIL(&softdepmounts, sdp, sd_next);
> >>>              FREE_GBLLOCK(&lk);
> >>>              if ((altump->softdep_flags &
> >>> -                (FLUSH_CLEANUP | FLUSH_EXIT)) == 0) {
> >>> +                (FLUSH_CLEANUP | FLUSH_EXIT)) == 0)
> >>>                  altump->softdep_flags |= 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.
> >
>

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
---
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.