Re: Resolved: devel/llvm13 build: "ninja: build stopped: subcommand failed"

Ok, I will avoid a swap file.

My actual config shows:
`swapinfo`:
---
Device          1K-blocks     Used    Avail Capacity
/dev/nvd0p2       4194304     6036  4188268     0%
---
and `cat /etc/fstab`:
---
# Device                Mountpoint      FStype  Options         Dump
 Pass#
/dev/nvd0p1             /boot/efi       msdosfs rw              2       2
/dev/nvd0p2             none    swap    sw              0       0
---

Any clues how do I do this?

Mark Millard <marklmi@yahoo.com> escreveu no dia domingo, 14/08/2022 à(s)
18:21:

> On 2022-Aug-14, at 10:15, Nuno Teixeira <eduardo@freebsd.org> wrote:
>
> > I use ZFS.
> >
> > I will follow your recomendations and use a swap of 64GB and then test
> it again.
> >
> > In the meanwhile I will take a look at freebsd docs to see how do I
> increase swap, by adding a new swap file or resize actual one if possible.
>
> I recommend never using a swap file, only swap partition(s), in order
> to avoid deadlocks and such:
>
> 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 produces 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.
>
>
>
> ===
> Mark Millard
> marklmi at yahoo.com
>
>

-- 
Nuno Teixeira
FreeBSD Committer (ports)