On 1/14/26 11:16, Nikos Vassiliadis wrote: > On 1/14/26 18:42, Sulev-Madis Silber wrote: >> i have seen this on 13.* once. or similar thing. i attributed it to >> some kind of corruption > > This is on 14. I thought of corruption too. > >> >> there, i had swap device with size i didn't add, but size was as if >> size of some other partition on some other device >> >> this 3rd nonfunctional device was seemingly never used nor did i >> experience any visible data corruption anywhere. using zfs >> >> problem seemed to appear after some sata devices went off bus and >> quickly reappeared >> >> i don't know how to test this. seems like this needs fuzzing but don't >> know if vm would be enough >> >> back then, everybody said that kernel doesn't allow it. yet it somehow >> did >> >> i think i even have some swapinfo outputs saved. which i was told to >> be impossible. "never seen anything like this" >> >> maybe this time this could be fixed? > > I rebooted because I thought better safe than sorry. The system had no > available storage to swap on. And before this "device" there was another > partition showed by swapinfo. That partition was part of a zpool, not > really a device available to swap on. After exporting and importing > that pool, that weird named appeared.
FYI for another issue, I would never recommend swapping to a file in a file system (vnode), especially to a zfs file: QUOTE ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206048#c7 ) On 2017-Feb-13, at 7:20 PM, Konstantin Belousov <kostikbel at gmail.com> wrote on the freebsd-arm list: . . . swapfile write requires the write request to come through the filesystem write path, which might require the filesystem to allocate more memory and read some data. E.g. it is known that any ZFS write request allocates memory, and that write request on large UFS file might require allocating and reading an indirect block buffer to find the block number of the written block, if the indirect block was not yet read. As result, swapfile swapping is more prone to the trivial and unavoidable deadlocks where the pagedaemon thread, which produce free memory, needs more free memory to make a progress. Swap write on the raw partition over simple partitioning scheme directly over HBA are usually safe, while e.g. zfs over geli over umass is the worst construction. END QUOTE I have in the past suffered such consequences. > >> >> >> >> On January 14, 2026 12:47:29 PM GMT+02:00, Nikos Vassiliadis >> <[email protected]> wrote: >>> Hi, >>> >>> Just noticed that swapinfo reports this: >>> >>> root@aurora:~ # swapinfo >>> Device 1K-blocks Used Avail Capacity >>> /dev/#C:0x101 10485760 0 10485760 0% >>> root@aurora:~ # >>> >>> I am not sure what happened. I might have added some temporary >>> swap at some point. It cannot be removed. Any thoughts? >>> >>> >>> >> > > > -- === Mark Millard marklmi at yahoo.com
