ZFS RESOLVED: USB based Swap

SoBe

SoBe

Is there a way to configure a usb based swap and plug it into my pfSense system and edit the folder pointing to /etc/fstab for the usb swap and use that? I have a 128GB ssd but the software didn’t configure a swap.

My compex WiFi card is crashing and going into system panic when it runs full tilt. I need swap enabled.

Is it better to use a usb or create a partition on the SSD?

Thank you Jimp on Netgate forum said USB is the way to go and planted the swap idea in my head….
 
USB3 maybe, but I would consider anything else to be too slow. Just create a swap on the SSD, if you have enough memory it'll barely be used anyway.

And, remember, pfSense is not supported here.

forums.freebsd.org

GhostBSD, pfSense, TrueNAS, and all other FreeBSD Derivatives

Questions about 'derivative FreeBSDs', like GhostBSD DesktopBSD TrueNAS XigmaNAS OPNsense pfSense PacBSD BSD Router Project NomadBSD helloSystem should be asked on the forums and/or mailing lists for these specific products. See below for links. If you still think your questions should be...
forums.freebsd.org forums.freebsd.org
 
On FreeBSD systems USB sticks show up as da(4) devices, which means that they look just like other (SCSI) disks.

You can partition them with gpart(8), and allocate a partition to swap space.

I have a USB stick mounted on /dev/da0p1 with a UFS file system:
Code: 
[gunsynd.246] $ mount | grep stick
/dev/da0p1 on /stick (ufs, local, noatime, soft-updates, journaled soft-updates)
[gunsynd.247] $ gpart show da0
=>       40  242501808  da0  GPT  (116G)
         40  242501808    1  freebsd-ufs  (116G)
I could redeploy the partition for (".eli" enables encrypted) swap by un-mounting it, and adding the following to /etc/fstab:
Code: 
/dev/da0p1.eli none swap sw 0 0
I think that this is a perfectly acceptable method to get a crash dump. But, beware, as SirDice suggests, using a USB thumb drive for swap will slow you down if you start swapping regularly. USB3 (the thumb drive and the port it plugs into) is the fastest USB option.
 
As pretty much everyone has suggested, swapping to a USB device is going to be slower than to an SSD, and inherently less reliable because of the external cable, and possibly inferior electronics. Also a lot slower for USB < 3, and thumb drives.

Swapping to a swap file on a UFS file system is a good solution.

However there has been persistent scuttlebutt that swapping to a file on a ZFS file system can cause kernel deadlock. This certainly used to happen, and I have not yet seen any definitive assertion that it still can't happen. You may be adding another problem to a system that's already compromised.

Your description "going into system panic" doesn't impart the reason you want swap space. We can probably fine tune the advice if you tell us precisely why you want the swap space. i.e.
  1. Are you Out Of Memory (OOM) or do you just want a crash dump?
  2. Is the new swap space to be permanent?
  3. What sort of file systems you have (UFS or ZFS)?
 
Swap on ZFS may be an issue for crash-dumps in case of panic but how many non-developers actually do anything with crashdumps?
 
Thanks everyone, It is working now like this, however the SSD manufacture had this to say about me using it like this...
"Hi Jonathan,

This will damage the drive, it is not safe. Moreover, the response speed and read and write speed are far inferior to RAM. We recommend you not to use it this way, it will probably cause the SSD to become defective."

I really want to use something long term as I am limited on what I can do with this box it has hard set ram without any way to add or remove them. The NVMe drive is the only solution outside of a USB based HDD however that like you said is very slow.

The ZFS yes is a concern with the drive however it shows with gpart as FreeBSD

I triggered a panic and it works with crash dumps also. I had Netgate forum help me with this and FreeBSD forum. I am thinking I should use a actual USB based HDD in the long run to abuse it with swap use however with a firewall that would really slow it down.

Check out
ada0s3
Shell Output - gpart list -a
Code: 
Geom name: ada0
modified: false
state: OK
fwheads: 16
fwsectors: 63
last: 250069679
first: 1
entries: 4
scheme: MBR
Providers:
1. Name: ada0s1
   Mediasize: 272629760 (260M)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 512
   Mode: r0w0e0
   efimedia: HD(1,MBR,00000000,0x1,0x82000)
   rawtype: 239
   length: 272629760
   offset: 512
   type: efi
   index: 1
   end: 532480
   start: 1
2. Name: ada0s2
   Mediasize: 67108864 (64M)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 272630272
   Mode: r0w0e0
   efimedia: HD(2,MBR,00000000,0x82001,0x20000)
   rawtype: 11
   length: 67108864
   offset: 272630272
   type: fat32
   index: 2
   end: 663552
   start: 532481
3. Name: ada0s3
   Mediasize: 127695937024 (119G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 339739136
   Mode: r2w2e3
   efimedia: HD(3,MBR,00000000,0xa2001,0xedda2af)
   attrib: active
   rawtype: 165
   length: 127695937024
   offset: 339739136
   type: freebsd
   index: 3
   end: 250069679
   start: 663553
Consumers:
1. Name: ada0
   Mediasize: 128035676160 (119G)
   Sectorsize: 512
   Mode: r2w2e5

Geom name: ada0s3
modified: false
state: OK
fwheads: 16
fwsectors: 63
last: 249406126
first: 0
entries: 8
scheme: BSD
Providers:
1. Name: ada0s3a
   Mediasize: 120590425600 (112G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 339747328
   Mode: r1w1e1
   rawtype: 27
   length: 120590425600
   offset: 8192
   type: freebsd-zfs
   index: 1
   end: 235528190
   start: 16
2. Name: ada0s3b
   Mediasize: 7105150976 (6.6G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 120930172928
   Mode: r1w1e0
   rawtype: 1
   length: 7105150976
   offset: 120590433792
   type: freebsd-swap
   index: 2
   end: 249405438
   start: 235528191
Consumers:
1. Name: ada0s3
   Mediasize: 127695937024 (119G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 339739136
   Mode: r2w2e3

Also /etc/

Code: 
# Device        Mountpoint    FStype    Options        Dump    Pass#
/dev/msdosfs/EFISYS    /boot/efi    msdosfs    rw,noatime,noauto    0    0
/dev/msdosfs/DTBFAT0    /boot/msdos    msdosfs    rw,noatime,noauto    0    0
/dev/ada0s3b        none    swap    sw        0    0
Shell Output -
Code: 
# dumpon -l
ada0s3b

I didn't even know you could do this until a couple weeks ago, thanks this really is expanding my knowledge. I could actually see ClamAV fully run on my system without issues for 24 hours I was amazed.

Again I disabled it per manufacture recommendations and it is only set to be used in case of a crash now
 
bakul said:
Swap on ZFS may be an issue for crash-dumps in case of panic but how many non-developers actually do anything with crashdumps?
Click to expand...
I needed it for a redmine ticket the ath driver is causing system crashes when it runs at full speed it never did when I had a 6mb line now I have 1gbps and it reboots and gives me a crash dump that points to that driver, I even installed a new card out of box did the same thing. Problem with the AR9280 chipset and the Ath0 driver for use with the Compex WLE200NX

It ran for years perfectly until you run it full tilt now it crashes.

Bug #15472: potential bug with the ath driver - pfSense Plus - pfSense bugtracker

Redmine
redmine.pfsense.org redmine.pfsense.org

Yes this is for pfSense.. just in case you are wondering why I needed swap here is my issue..

Thanks again the commands are all the same mostly as it runs on a openbsd freebsd type flavor.

Thanks I will return here again when I get a nice HDD for a usb to play around with.

They really should make SSD SWAP safe ram expanders with build in partitions in my opinion but that is not a thing, not many people want to expand memory like that.
 
Most Unix systems don't swap a lot these days. If they do, they tend to be somewhat unpleasant to use.

I have several appliances (including two firewalls) which boot from, and also swap on, USB thumb drives. The trick with these systems is that they load all they need to run in memory, and don't need to swap a lot. Where there's "disk" I/O involved, I use USB3 thumb drives on USB3 ports (you need to match the drive specs to the port specs). Most of what gets written to "disk" is logs. In this context USB3 is quite adequately fast -- but you're not going to do databases or log processing!

I am not a fan of USB disks. Every time I look at the specs, I get depressed. Caveat emptor.

Heavy swap onto an SSD will wear it out faster that than normal, but there's plenty of people with swap on SSD (onto both partitions and file systems) -- the trick is to not swap a lot!

I still do not have any sense if your system is going to swap a lot. If it is, get more memory. If it is not, the what you swap onto does not really matter (but probably best to avoid a swap file on a ZFS file system).

If all you really want is a crash dump, then any USB stick would do the job of providing a "disk partition" to swap on.
 
gpw928 said:
I still do not have any sense if your system is going to swap a lot. If it is, get more memory.
Click to expand...
OP says the primary reason for swap is to capture crash dumps, said dumps are part of the data to provide to a bug ticket. System has fixed RAM and can't add any or replace with bigger devices.
 
It does crash dump to the swap correctly and functions thank you all. I got what I needed for development on redmine ticket for ath0 driver issue
 
gpw928 said:
Most Unix systems don't swap a lot these days. If they do, they tend to be somewhat unpleasant to use.

I have several appliances (including two firewalls) which boot from, and also swap on, USB thumb drives. The trick with these systems is that they load all they need to run in memory, and don't need to swap a lot. Where there's "disk" I/O involved, I use USB3 thumb drives on USB3 ports (you need to match the drive specs to the port specs). Most of what gets written to "disk" is logs. In this context USB3 is quite adequately fast -- but you're not going to do databases or log processing!

I am not a fan of USB disks. Every time I look at the specs, I get depressed. Caveat emptor.

Heavy swap onto an SSD will wear it out faster that than normal, but there's plenty of people with swap on SSD (onto both partitions and file systems) -- the trick is to not swap a lot!

I still do not have any sense if your system is going to swap a lot. If it is, get more memory. If it is not, the what you swap onto does not really matter (but probably best to avoid a swap file on a ZFS file system).

If all you really want is a crash dump, then any USB stick would do the job of providing a "disk partition" to swap on.
Click to expand...
I want to enable ClamAV but when I do it starts to use swap with the SSD I am afraid running Squid and ClamAV and Squidguard, with my pcie compex card, and ACLs syslog from the external ap, and Snort running it would cause way to much. However it runs fine until I enable ClamAV at that point it starts to SWAP, I have ClamAV disabled as I just want my crash files when the system goes into panic mode so it is working now as needed. I wish they made a SWAP high use 2242 NVMe SSD but I emailed the vendor and they do not make something like that and also caution against using it as a ram expander. So it just is needed for my crash files during testing now. ClamAV is off again. I can't increase the RAM its fixed
 
Noob question: can you not create a swap on a RAM drive?
This avoids the endless write chatter that degrades SSD, and is also the fastest access.
 
SoBe said:
No its a SG-2100MAX you have no options for that
Click to expand...
OK, your hardware has significant limitations, including 4GB memory, SATA 2242 M.2, and USB2 only.

The easiest option to try is to get the fastest USB2 thumb drive you can find. 30 MBps read and write might be achievable. 16G capacity should be plenty, and would not be expensive. If it woks OK when your system goes into swap, you win. If it does not, you have not lost much.
 
I don't have any RAM limitations, so curious about using RAM for a swap.
MLC type USB have a finite number of writes before they fail.
Swap by definition is a chatty situation with many writes.
Seems to me that swap on USB is a failure waiting to happen.

If USB is the only solution, look for the more expensive SLC types.
They do not have the write limitations.

My only FBSD app is XigmaNAS, which boots from USB, but runs a RAMDRIVE for all its chatty stuff.
Works great.
 
bgavin said:
I don't have any RAM limitations, so curious about using RAM for a swap.
Click to expand...
Without RAM limitations why would you need a swap device? Anyway you can use mdconfig(8) to create a memory device. If you are using a swap device to store a kernel crash dump, a memory device won't do but you can use dumpon(8) to use a persistent storage device.
 
Screenshot 2024-05-10 at 17.10.04.jpg



Thank you all.

I have found a way to use the 2042 NVMe and or a USB based microHDD/or Flashdrive over USB2.0.

Both solutions resolved my issues.
A) SSD solution got me my crash dumps I needed for development quickly. However the vendor said to not use the SSD for swap space, as it was not designed for heavy SWAP usage.
B) The USB solution provides me the SWAP space I need to run ClamAV and get crash-dumps. I am limited with USB 2.0 speeds however with the use of a ZIF 1.8 inch HDD to USB adapter this provides me the longevity I needed. It is "basically an older 100GB iPod HDD." I had an iPod last many years with a mechanical HDD at the GYM 2-3 times a week for over a decade with running 5ks also, so I trust it for the high use, they can take a beating. Keep in mind speed is not a concern at all for me as the FreeBSD system only uses SWAP when the ClamAV antivirus updates and or Snort updates, this is in the early morning that is when the SWAP starts to be utilized. Again, it completes and does not crash any processes. Before activating swap I could not enable ClamAV and Snort at the same time with use of Open AppID full rule sets (monster custom rules)

The community helped me get a solution to get the dump files I needed, and also I discovered that I can run ClamAV now without any issues as the updates always crashed processes and that no longer occurs with the USB drive.



Screenshot 2024-05-07 at 09.16.29.png

Image: An update occurring for ClamAV Snort and Squid all at the same time using Swap space on the 2042 NVMe SSD.

Screenshot 2024-05-10 at 20.22.46.png

Image: Showing Normal use of USB swap after updates completed in the early morning. It never is really needed
except for with the memory hungry updates. This required a repartition and also installing a FreeBSD swap on the drive after it was partitioned. This is a 100GB drive, I know I really do not need that much swap space however you can see it works.

Thank you all so much this is resolved. Not only my crash dump issue but I can run ClamAV again in real time.
Screenshot 2024-05-10 at 20.35.34.png


Thank you all that took the time to help me with this.
 
You must log in or register to reply here.
Back
Top