GPT vs MBR for swap devices

[Mark Millard]

On 2018-Jun-19, at 7:32 PM, bob prohaska <fbsd at www.zefox.net> wrote:

> On Tue, Jun 19, 2018 at 06:44:00PM -0700, Mark Millard wrote:
>> bob prohaska fbsd at www.zefox.net wrote on
>> Tue Jun 19 21:59:50 UTC 2018 :
>> 
>>> One more test has completed. The Pi3 was configured with 1 GB swap on the 
>>> microSD card. It was expected to run out of swap and start the OOM assassin. 
>>> Instead, it ran until the swap usage hit a little over 80% and then 
>>> traffic with da0d (/usr, likely /usr/obj) got stuck. 
>>> 
>>> Traffic to da0d remained stuck for several sampling cycles, swap
>>> usage dropped to a few percent, and I finally pulled the plug when the
>>> debugger would not start. The console messages are of a sort seen before
>>> and might suggest hardware trouble, but after rebooting and fsck the machine
>>> seems just fine and is running another test. It's completely unclear to me 
>>> what triggered the USB stoppage.
>>> 
>>> The relevant files are at
>>> 
>>> http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbsdflash_swapinfo/
>>> 
>>> I hope they're useful.
>> 
>> where the referenced place includes this console messaging in
>> one of the files:
>> 
>>> r = 5
>>> :48 www init[51271]: can't exec getty '/usr/libexec/getty' for port /dev/ttyu0: Input/output error
>>> (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 40 00 80 00 00 08 00 
>>> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
>>> (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
>>> (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 40 00 80 00 00 08 00 
>>> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
>>> (da0:umass-sim0:0:0:0): Retrying command, 2 more tries remain
>>> (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 40 00 80 00 00 08 00 
>>> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
>>> (da0:umass-sim0:0:0:0): Retrying command, 1 more tries remain
>>> (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 40 00 80 00 00 08 00 
>>> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
>>> (da0:umass-sim0:0:0:0): Retrying command, 0 more tries remain
>>> (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 40 00 80 00 00 08 00 
>>> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
>>> (da0:umass-sim0:0:0:0): Error 5, Retries exhausted
>>> g_vfs_done():da0d[WRITE(offset=20709376, length=4096)]error = 5
>>> g_vfs_done():da0d[WRITE(offset=36764549120, length=32768)]error = 5
>>> g_vfs_done():da0d[WRITE(offset=36862820352, length=32768)]error = 5
>>> g_vfs_done():da0d[WRITE(offset=36984651776, length=65536)]error = 5
>>> g_vfs_done():da0d[READ(offset=39455948800, length=32768)]error = 5
>>> g_vfs_done():da0d[WRITE(offset=51207864320, length=32768)]error = 5
>>> g_vfs_done():da0d[WRITE(offset=51207962624, length=32768)]error = 5
>>> g_vfs_done():da0d[WRITE(offset=51228348416, length=4096)]error = 5
>>> g_vfs_done():da0d[WRITE(offset=65536, length=4096)]error = 5
>>> :45 www init[51281]: can't exec getty '/usr/libexec/getty' for port /dev/ttyu0: Input/output error
>> 
>> 
>> As I understand this it indicates that the drive /dev/da0 is
>> failing to execute some requests and returning error status
>> information to FreeBSD.
>> 
>> I view this as evidence that you need to get the materials
>> off that drive and need to quit using the drive that was
>> /dev/da0. (Or similar status for connections or other stages
>> between the rpi3 and /dev/da0 [inclusive of both].)
>> 
> Possibly. An alternative to which I subscribe (for the moment)
> posits that FreeBSD has started talking rubbish to da0 and da0 
> is responding appropriately. The problem dissapears on reboot. 

I go the other direction: no one else is seeing such issues as
far as I can see from the lists. It seems unlikely that FreeBSD
would only get the above sort of "talking rubbish" thing for
your drive instead of fairly generally.

So, unless other folks are also seeing such behavior, including
the above sorts of messages, my guess is the problem is not
FreeBSD's generation of rubbish.

>> One classic problem, when not using a powered hub, is the rpi3
>> sometimes not providing sufficient quality power to the USB
>> device(s) plugged in.
>> 
> A powered hub is running da1 and da2. Most important, rebooting and 
> fsck clears the difficulty. If that didn't happen I'd agree with you. 

But not /dev/da0 (the problem drive)?

I've had such power problems and messages in the past. And normally
fsck would make the file system appear to be usable. (But there
still could be lots of corruption of some file content in various
files that were being written. I sometimes managed to verify such.
I tended to delete and reconstruct to avoid such.)

>> Whatever the case, with the above happening, it is not reasonable
>> to expect things to work.
>> 
> Indeed! 8-)

Folks may be more inclined to investigate further if you can reproduce
such problems and messages without that specific drive involved (not
even attached to the rpi3 during the reproduction).

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)