GPT vs MBR for swap devices

[Mark Millard]

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.

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

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

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