Re: Q: Error: mount_mfs: mmap: Cannot allocate memory

[Stuart Henderson]

On 2023-02-12, Why 42? The lists account.  wrote:
>
> You're exactly right. With this entry in fstab:
>> swap /tmp mfs rw,nodev,nosuid,-s=4194304 0 0 
>
> I now have this /tmp space:
>> mjoelnir:~ 12.02 13:15:07 % df -h
>> Filesystem SizeUsed   Avail Capacity  Mounted on
>> /dev/sd1a 1005M537M418M57%/
>> mfs:67535  1.9G   29.0K1.8G 1%/tmp
>> ...
>
> That's right after a reboot. I'll start Chrome now and it can really chow
> down on some /tmp space :-)

It maybe worth checking whether mfs is actually helping -
it's easy to assume that because it's in RAM it must be fast,
but I've had machines where mfs was slower than SSD
(https://marc.info/?l=openbsd-misc=164942119618029=2),
also it's taking memory that could otherwise be used by
buffer cache.

The main benefit to me from mfs is for things which I explicitly
don't want to hit permanent storage.

Re: Safely remove USB drive

[Crystal Kolipe]

On Thu, Feb 09, 2023 at 09:20:48PM -0300, Crystal Kolipe wrote:
> There is no reason why we couldn't implement support for 'eject -t' for sd
> devices, (which is internally treated as a tape retension command).
> 
> In fact, I just made a patch to do that out of curiosity and was able to
> access the usb device again after 'reloading' it.

Over the weekend I received a few emails off-list asking me about this, so
I've written up and posted a brief explainer here:

https://research.exoticsilicon.com/articles/eject_command_hacking