GPT vs MBR for swap devices

Tue Jun 19 04:27:54 UTC 2018

On Mon, Jun 18, 2018, 10:15 PM Mark Millard via freebsd-arm <
freebsd-arm at freebsd.org> wrote:

>
>
> On 2018-Jun-18, at 8:42 PM, bob prohaska <fbsd at www.zefox.net> wrote:
>
> > On Mon, Jun 18, 2018 at 06:31:40PM -0700, Mark Millard wrote:
> >> On 2018-Jun-18, at 5:55 PM, bob prohaska <fbsd at www.zefox.net> wrote:
> >>
> >> . . .
> >> I see a ms/w (and ms/r) that is fairly large (but notably
> >> smaller than the ms/w of over 12000):
> >>
> >> Mon Jun 18 13:12:58 PDT 2018
> >> Device          1K-blocks     Used    Avail Capacity
> >> /dev/da0b         1048576        0  1048576     0%
> >> dT: 10.400s  w: 10.000s
> >> L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w    d/s   kBps
>  ms/d   %busy Name
> >>    0      4      0      0    0.0      4     66    3.4      0      0
> 0.0    1.3  mmcsd0
> >>    8     18      1     32   1991     17    938   2529      0      0
> 0.0   88.1  da0
> >>    0      4      0      0    0.0      4     63    3.5      0      0
> 0.0    1.3  mmcsd0s3
> >>    0      4      0      0    0.0      4     63    3.5      0      0
> 0.0    1.3  mmcsd0s3a
> >>    6     11      1     32   1991     10    938   3207      0      0
> 0.0   94.7  da0d
> >> Mon Jun 18 13:13:19 PDT 2018
> >> Device          1K-blocks     Used    Avail Capacity
> >> /dev/da0b         1048576        0  1048576     0%
> >>
> >>
> > Yes, but again, it's on /usr, not  swap. One could argue that there are
> other
> > write delays, not seen here, that do affect swap. To forestall that
> objection
> > I'll get rid of the ten second sleep in the script when the present test
> run
> > finishes.
> >
>
> If the drive /dev/da0 has any partitions with large ms/w (or ms/r)
> figures sometimes, all partitions on the drive are likely subject
> to the same if /dev/da0 is a flash or SSD drive. At least that
> is my understanding.
>

Yes partitioning is a logical thing. You never know for sure what is taking
a long time or the cause. All you can see is the effect.

Also if /dev/da0 has any partition with an active I/O that takes
> a long time, it may well block I/O on any other partition on the
> same drive until it completes. (As far as I know for a USB flash
> and FreeBSD. I'm no expert at such issues.)
>

Usually with usb flash it does. SSDs have multiple channels to the NAND.
USB often does not...

My suggestions have been trying to see if eliminating all the
> large ms/w (and ms/r) on the drive(s) used for swap makes the
> problem go away, not just on the swap partitions.
>
> If FreeBSD might have more overall cross-device "large ms/w"
> interference was also something I was trying to avoid having
> any chance of being involved. (I've no clue if such has a
> chance of being an issue.)
>

Large latencies usually means slow page cleaning. No page cleaning means
OOM.

Warner

> >>  . .
> >> Can you get a failure without involving da0, the drive that is
> >> sometimes showing these huge ms/w (and ms/r) figures? (This question
> >> presumes having sufficient swap space, so, say, 1.5 GiByte or more
> >> total.)
> >>
> > If you mean not using da0, no; it holds /usr. If you mean not swapping
> > to da0, yes it's been done. Having 3 GB swap on microSD works.
> > Which suggests an experiment: use 1 GB SD swap and 1.3 GB mechanical
> > USB swap. That's easy to try.
>
> For what I was thinking of testing you would have to have /usr and the
> rest being on some other drive than one that gets the large ms/w
> (and/or ms/r) figures: you would need to avoid that drive because
> all partitions on that drive are likely subject to the large
> ms/w (and ms/r) figures.
>
> Avoiding swap being on any partition of /dev/da0 is a less extreme
> form of isolating  things.
>
> >> Having the partition(s) each be sufficiently sized but for which
> >> the total would not produce the notice for too large of a swap
> >> space was my original "additional" suggestion. I still want to
> >> see what such does as a variation of a failing context.
> >
> > I'm afraid you've lost me here. With two partitions, one USB and
> > the other SD of one GB each OOM kills happen at 8% utilization,
> > spread evenly across both. Does the size of the partition affect
> > the speed of it? Capacity does not seem the problem.
>
> Being able to just turn off one of two partitions allows testing if
> it is having more than one that makes the difference if OOM killing
> of processes happens. (Similarly exchanging which is off.) But only
> if each is large enough to allow the run to complete.
>
> Not that such is the actual issue or likely, but imagine that some
> test for OOM process killing was using the size of the smallest
> active swap partition to test if OOM was needed instead of testing
> the total.
>
> (The log files are just sampling and are unlikely to show peak swap
> space "used" figures.)
>
> >> it would seem to be a good idea to avoid da0 and its sometimes
> >> large ms/w and /ms/r figures.
> >>
> >
> > I think the next experiment will be to use 1 GB of SD swap and
> > 1.3 GB of mechanical USB swap. We know the SD swap is fast enough,
> > and we know the USB mechanical swap is fast enough. If that
> > combination works, maybe the trouble is congestion on da0. If the combo
> > fails as before I'll be tempted to think it's USB or the swapper.
>
> Sounds like a plan if large ms/w (and ms/r) figures for /dev/da0
> can not interfere with other drives.
>
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
>
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>