Buffer error after upgrading storage

SILO Node Operators
1

Hello !

I get this error, since i installed some new HDDs.
Aswell i had to set up a new docker container.

2026-02-02T11:21:40Z INFO failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See Home · quic-go/quic-go Wiki · GitHub for details. {“Process”: “storagenode”}

Aswell these errors keep persisting

2026-02-02T11:14:52Z ERROR piecestore download failed {“Process”: “storagenode”, “Piece ID”: “DZCBIGSQGG34VYVXBULPE37BYUZ3CSBSAIFDKJ3RJN5LXK7NSETQ”, “Orbital ID”: “1dkRxqhU46NfjV1xJZrxnt8RwWGK2uAas1jtncvZoj4s8HVVK4”, “Action”: “GET_AUDIT”, “Offset”: 643072, “Size”: 256, “Remote Address”: “172.17.0.1:59734”, “error”: “hashstore: unable to fallocate hashtbl to 8392704: hashstore: operation not supported”, “errorVerbose”: “hashstore: unable to fallocate hashtbl to 8392704: hashstore: operation not supported\n\tsilos3.com/silo/storagenode/hashstore.CreateHashtbl:70\n\tsilos3.com/silo/storagenode/hashstore.NewStore.func3:195\n\tsilos3.com/silo/storagenode/hashstore.NewStore:202\n\tsilos3.com/silo/storagenode/hashstore.New:79\n\tsilos3.com/silo/storagenode/piecestore.(*HashStoreBackend).getDB:230\n\tsilos3.com/silo/storagenode/piecestore.(*HashStoreBackend).Reader:273\n\tsilos3.com/silo/storagenode/piecestore.(*MigratingBackend).Reader:182\n\tsilos3.com/silo/storagenode/piecestore.(*TestingBackend).Reader:105\n\tsilos3.com/silo/storagenode/piecestore.(*Endpoint).Download:667\n\tsilos3.com/common/pb.DRPCPiecestoreDescription.Method.func2:302\n\tsilos3.com/drpc/drpcmux.(*Mux).HandleRPC:33\n\tsilos3.com/common/rpc/rpctracing.(*Handler).HandleRPC:62\n\tsilos3.com/common/experiment.(*Handler).HandleRPC:43\n\tsilos3.com/drpc/drpcserver.(*Server).handleRPC:166\n\tsilos3.com/drpc/drpcserver.(*Server).ServeOne:108\n\tsilos3.com/drpc/drpcserver.(*Server).Serve.func2:156\n\tsilos3.com/drpc/drpcctx.(*Tracker).track:35”}

What to do ?

2

Hello :waving_hand:

Thanks for reaching out and for sharing the logs — this is helpful. I’ll break this down clearly and outline exactly what to do next.

1) Receive buffer warning (QUIC)

failed to sufficiently increase receive buffer size

What this means
This is a host-level networking warning, not a Silo node failure. Your OS is limiting UDP receive buffer sizes, so QUIC (used by Silo for transport) can’t increase it to the recommended value.

Impact

  • :warning: Low to moderate performance impact
  • :cross_mark: Does NOT cause audits to fail
  • :cross_mark: Does NOT disqualify a node

Recommended fix (host OS, not container)
Apply these sysctl values on the Docker host:

sudo sysctl -w net.core.rmem_max=2500000
sudo sysctl -w net.core.wmem_max=2500000

To persist across reboots, add to /etc/sysctl.conf:

net.core.rmem_max=2500000
net.core.wmem_max=2500000

You may restart the node afterward, but this warning alone is not critical.

2) Critical issue: Audit failures (hashstore: fallocate not supported)

ERROR piecestore download failed
hashstore: unable to fallocate hashtbl
operation not supported
Action: GET_AUDIT

What this means (root cause)
Your Silo node is running on a storage backend that does not support fallocate().
Silo requires fallocate() to pre-allocate files for the hashstore (used during audits).

This commonly happens when:

  • New HDDs are formatted as NTFS / exFAT
  • Storage is mounted via NAS / SMB / NFS
  • Docker is using overlay2 or named volumes
  • Storage path is backed by FUSE-based filesystems

Because audits rely on this, these errors must be fixed.

3) Required storage configuration for Silo (per official docs)

As documented in the Silo Docker installation guide, the node must use a bind mount to a real filesystem that supports preallocation.

:white_check_mark: Supported filesystems

  • ext4 (recommended)
  • xfs

:cross_mark: Not supported

  • NTFS (even via Linux)
  • exFAT / FAT32
  • NAS mounts
  • Docker named volumes
  • overlay2-backed paths

4) What you should do now (step-by-step)

Step 1: Verify filesystem type

On the Docker host, run:

df -T /path/to/your/silo/storage

If it is not ext4 or xfs, this is the cause.

Step 2: Fix storage layout (Docker best practice)

  1. Format the new HDD properly (example with ext4):
mkfs.ext4 /dev/sdX
  1. Mount it on the host:
mount /dev/sdX /mnt/silo-storage
  1. Ensure Docker uses a bind mount, not a volume:
docker run -d \
  --mount type=bind,source=/mnt/silo-storage,target=/app/config \
  --name silo-node \
  silos3/silo-node

:warning: Do not point /app/config to /var/lib/docker, overlay paths, or NAS shares.

Step 3: Restart and monitor

After restarting the node:

  • Audit errors should stop
  • Node will resume passing audits normally
  • Reputation will stabilize automatically

Summary

  • :white_check_mark: QUIC buffer warning → optional optimization
  • :cross_mark: Audit failures → filesystem incompatibility
  • :key: Fix = ext4/xfs + Docker bind mount to real disk

Once storage is corrected, no additional reconfiguration inside Silo is required.

If you’d like, feel free to share:

  • Output of df -T
  • How the new HDDs are mounted
  • Your current Docker run command

Happy to sanity-check it with you.

3

Hello Digital.dynamo.00

Thank you for the reply,

I use Windows 10, and i indeed formated all the hard disks to NFTS ( made multilpe harddisk as 1 )

So i would need to use linux ?

4

Under WSL2 in windows 11 there is a posability to format to ext4.

I am not that familair with linux, and might just try windows 11

5

So i got a plan!

Install windows 11, and WSL2 ( windows subsystem for linux 2 )
Install silo OS

I assume it will run in a Docker container, or just install Silo OS as a stand allone.

Will this work ?