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?
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?
i have seen this on 13.* once. or similar thing. i attributed it to some kind of corruptionThis 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 deviceI 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
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?
On January 14, 2026 12:47:29 PM GMT+02:00, Nikos Vassiliadis <nvass@gmx.com> 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?
FYI for another issue,That's good to say because everybody is saying that it is not
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 1/14/26 21:45, Mark Millard wrote:
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.
That's good to say because everybody is saying that it is not
recommended but most of the time people have no first hand experience of
a failure.
While this system have a few GBs of swap I removed it temporarily and I
used a zvol for swap. When I am done it will have the traditional swap partition...
On Fri, 16 Jan 2026 13:48:04 +0200)
Nikos Vassiliadis <nvass@gmx.com> wrote:
On 1/14/26 21:45, Mark Millard wrote:
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=3D206048#c7=
ygmail.com>On 2017-Feb-13, at 7:20 PM, Konstantin Belousov <kostikbel at
wrote on the freebsd-arm list:
. . .
filesystemswapfile write requires the write request to come through the
write path, which might require the filesystem to allocate more memor=
frequireand read some data. E.g. it is known that any ZFS write request
allocates memory, and that write request on large UFS file might
numberallocating and reading an indirect block buffer to find the block
of the written block, if the indirect block was not yet read.
construction.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
END QUOTE
I have in the past suffered such consequences.
That's good to say because everybody is saying that it is not
recommended but most of the time people have no first hand experience o=
a failure.
While this system have a few GBs of swap I removed it temporarily and I used a zvol for swap. When I am done it will have the traditional swap partition...
Well, IIUC, using zvol for swap still has some risk.
zvol gives functionalities of underlying pool like checksumming,
if configured as such, also compression and crypt.
Of course this functionalities consumes memories.
So, not sure how OpenZFS is impmemented, it should mis-behave
(including panics / crashes) under heavy thrushing situations
unless memories needed for the features are statically allocated
and strictly pinned to physical memory.
Swap partitions are the safest.
On Fri, Jan 16, 2026 at 7:30rC>AM Tomoaki AOKI <junchoon@dec.sakura.ne.jp> >wrote:So, a stupid question then comes to mind:
On Fri, 16 Jan 2026 13:48:04 +0200
Nikos Vassiliadis <nvass@gmx.com> wrote:
On 1/14/26 21:45, Mark Millard wrote:gmail.com>
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
filesystemwrote on the freebsd-arm list:
. . .
swapfile write requires the write request to come through the
requirewrite 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
numberallocating and reading an indirect block buffer to find the block
construction.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
END QUOTE
I have in the past suffered such consequences.
That's good to say because everybody is saying that it is not
recommended but most of the time people have no first hand experience of >> > a failure.
While this system have a few GBs of swap I removed it temporarily and I
used a zvol for swap. When I am done it will have the traditional swap
partition...
Well, IIUC, using zvol for swap still has some risk.
zvol gives functionalities of underlying pool like checksumming,
if configured as such, also compression and crypt.
Of course this functionalities consumes memories.
So, not sure how OpenZFS is impmemented, it should mis-behave
(including panics / crashes) under heavy thrushing situations
unless memories needed for the features are statically allocated
and strictly pinned to physical memory.
Swap partitions are the safest.
This is absolutely true. You can swap to raw partitions without allocating >additional memory (and when the write is complete, free up the memory
for other things). With zvol, there's many memory allocations needed to
do the I/O, which can deadlock in low memory situations (eg, you need
memory to free memory and can't until memory is freed...).
zvols are great for a large variety of things. swap partitions aren't one
of them, except in very limited circumstances where you have a little
memory pressure to force things out, but are never running anywhere
close to the edge. Not 'rarely' but 'never'.
Warner
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 59 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 05:36:13 |
| Calls: | 810 |
| Files: | 1,287 |
| D/L today: |
6 files (10,211K bytes) |
| Messages: | 204,948 |