Re: Weird behavior writing to SSD on 2013 MacBook

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.
>