Is there any observed behavior for a fluent-bit.conf that is using

storage.type

filesystem

without setting an explicit

storage.total_limit_size

on the output plugin when disk space has been exhausted? Does fluent-bit attempt to allocate the record and fail to create the file or attempt to drop the oldest record to make room?

If it was me, I'd probably just test it: should be easy enough to spin up a container or pod with a fixed size mounted volume for storage and then just something like a dummy input with an always failing output to fill up the storage. Auto-removing old records would not be something I'd expect, typically this should be a choice exposed to the user - some folks would not want silent removal of data but instead would want an error raised to make it clear.

yeah that's about where i am at 😆

Ultimately you will have to test it even if just to confirm a random internet strangers ideas 😄

so far I am at SIGSEGV and need to limit my output plugins 🙃

Are you on latest version as well?

yeah, mine was a setup issue no a fluent-bit. Had a logging app generating logs and with no disk space well 🤷 When i resolved that I could get the app to 0% free but needed to re-run with debug logs to understand what fluent-bit is doing

Dummy input can generate for you but yeah

[/tmp/fluent-bit/lib/chunkio/src/cio_file_unix.c:563 errno=28] No space left on device
[/tmp/fluent-bit/lib/chunkio/src/cio_file.c:1240 errno=28] No space left on device
[2025/12/09 21:37:19.519100060] [error] [storage] [cio file] cannot map chunk: forward.3/6-1765316239.519028320.flb
[2025/12/09 21:37:19.519917421] [error] [input chunk] no available chunk
[2025/12/09 21:37:19.520129661] [error] [storage] [cio file] cannot map chunk: forward.3/6-1765316239.520056691.flb

and now my experiment ends