Best Database Software for FreeBSD in 2026

FreeBSD and databases have a long shared history. PostgreSQL development has used FreeBSD as a reference platform for decades. Netflix runs its Open Connect CDN infrastructure on FreeBSD with custom data stores. The combination of ZFS, jails, and a stable ABI makes FreeBSD a serious choice for database workloads that need predictable behavior under pressure.

This guide compares the most practical database options for FreeBSD -- PostgreSQL, MySQL, MariaDB, Redis, SQLite, and MongoDB -- with the kind of FreeBSD-specific tuning detail that generic comparisons skip entirely. If you run databases on FreeBSD or plan to, this is the reference.

Quick Recommendation

If you want a short answer before the deep dive:

PostgreSQL is the best general-purpose database for FreeBSD. It has the deepest FreeBSD integration, the best ZFS compatibility story, and the richest SQL feature set. If you are choosing one relational database for a new FreeBSD server, choose PostgreSQL.
Redis is the best choice for caching, session storage, and real-time pub/sub. It runs exceptionally well on FreeBSD and complements any relational database.
SQLite is the right pick for embedded applications, local data storage, single-process tools, and situations where running a database server is unnecessary overhead.
MariaDB is the pragmatic choice when you need MySQL wire compatibility with better defaults and Galera-based multi-master clustering out of the box.
MySQL remains viable when third-party software explicitly requires it or when Oracle support contracts matter to your organization.

The rest of this article explains each option in detail, including installation, ZFS tuning, and the tradeoffs that matter in production.

PostgreSQL on FreeBSD

PostgreSQL is the default recommendation for FreeBSD database workloads, and that is not arbitrary. The PostgreSQL project has historically used FreeBSD as a primary development and testing platform. Several core PostgreSQL committers run FreeBSD. The FreeBSD port is well-maintained, frequently updated, and receives attention that other Unix-like platforms do not.

Why PostgreSQL Fits FreeBSD

PostgreSQL's process-per-connection model maps cleanly to FreeBSD's process management. Each backend is a real OS process, which means FreeBSD's top, procstat, truss, and dtrace work directly against individual connections without the abstraction layers that thread-pool architectures impose.

The shared buffer implementation uses System V shared memory or POSIX shared memory, both of which FreeBSD handles correctly. Huge pages (called "superpages" on FreeBSD) work with PostgreSQL's huge_pages setting when the kernel is configured appropriately.

PostgreSQL also integrates well with FreeBSD's capsicum capabilities framework for sandboxing, and its write-ahead log (WAL) behavior aligns with ZFS's transactional semantics in ways that matter for data safety.

Installation

sh
pkg install postgresql17-server postgresql17-contrib
sysrc postgresql_enable=YES
/usr/local/etc/rc.d/postgresql initdb
service postgresql start

The contrib package includes essential extensions: pg_stat_statements for query performance analysis, pgcrypto for encryption functions, hstore for key-value storage, and pg_trgm for fuzzy text search.

Key Features

Full SQL:2023 compliance with window functions, CTEs, lateral joins, and recursive queries.
JSONB for document-style storage with GIN indexing -- fast enough that many teams skip MongoDB entirely.
Native full-text search with ranking, stemming, and language-aware dictionaries.
Logical replication for selective table-level replication between clusters.
Partitioning (declarative since v10) for managing large tables.
Extensions ecosystem: PostGIS for geospatial, TimescaleDB for time-series, pgvector for AI/ML embeddings.

ZFS Tuning for PostgreSQL

PostgreSQL uses an 8 KB page size by default. Set the ZFS dataset recordsize to match:

sh
zfs set recordsize=8K tank/postgres/data
zfs set primarycache=metadata tank/postgres/data
zfs set logbias=throughput tank/postgres/data

Setting primarycache=metadata avoids double caching -- PostgreSQL manages its own buffer pool via shared_buffers, so letting ZFS also cache data blocks wastes RAM. Set logbias=throughput because PostgreSQL already handles its own write-ahead logging; you do not need ZFS intent log optimizations for the data directory.

For the WAL directory, the tuning is different:

sh
zfs create -o recordsize=64K -o logbias=latency tank/postgres/wal

WAL writes are sequential and benefit from larger records and latency-optimized log bias. Placing WAL on a separate dataset (ideally a separate vdev or SLOG device) is one of the highest-impact performance changes you can make.

See our ZFS guide for complete dataset layout strategies and our PostgreSQL setup guide for a full production deployment walkthrough.

Pros

Deepest FreeBSD integration of any database.
Richest SQL feature set available in open source.
JSONB eliminates the need for a separate document store in many architectures.
Mature replication, PITR backup, and high-availability tooling (Patroni, repmgr).
Extensions ecosystem is unmatched.

Cons

Process-per-connection model means you need a connection pooler (PgBouncer or Pgpool-II) at scale.
Configuration requires more knowledge than MySQL's defaults-that-just-work approach.
Memory tuning (shared_buffers, work_mem, effective_cache_size) requires understanding your workload.
Vacuuming (MVCC cleanup) needs monitoring -- autovacuum handles most cases but can lag on write-heavy tables.

MySQL on FreeBSD

MySQL is the most widely deployed open-source relational database by installation count. On FreeBSD, MySQL runs well and is straightforward to install, though it no longer receives the same level of FreeBSD-specific attention that PostgreSQL does.

Installation

sh
pkg install mysql84-server mysql84-client
sysrc mysql_enable=YES
service mysql-server start
mysql_secure_installation

Always run mysql_secure_installation after first start. It removes test databases, disables remote root login, and sets a root password.

Key Features

InnoDB storage engine with ACID transactions, row-level locking, and crash recovery.
Group Replication for multi-primary and single-primary high-availability clusters.
MySQL Shell for administration, scripting, and cluster management.
MySQL Router for transparent connection routing and load balancing.
JSON data type with functional indexes.
Performance Schema for internal instrumentation.

ZFS Tuning for MySQL

MySQL/InnoDB uses a 16 KB page size by default:

sh
zfs set recordsize=16K tank/mysql/data
zfs set primarycache=metadata tank/mysql/data
zfs set logbias=throughput tank/mysql/data

The same double-caching concern applies here -- InnoDB has its own buffer pool (innodb_buffer_pool_size), so let it manage data caching and keep ZFS focused on metadata.

For InnoDB redo logs:

sh
zfs create -o recordsize=128K -o logbias=latency tank/mysql/logs

If you are running on ZFS, consider setting innodb_doublewrite=OFF in your MySQL configuration. ZFS is transactional and copy-on-write, so it already protects against torn pages. The InnoDB doublewrite buffer becomes redundant overhead.

Pros

Extremely wide ecosystem and third-party application support.
Strong documentation and a large community.
Group Replication provides native HA without third-party tools.
Performance Schema offers deep internal observability.
Many managed hosting providers offer MySQL, simplifying migration paths.

Cons

Oracle stewardship creates uncertainty around open-source licensing long-term.
FreeBSD-specific testing and optimization receives less attention than Linux.
Feature development has slowed relative to PostgreSQL in recent years.
No built-in logical replication at the table level (binlog replication is statement or row-based, but applies globally).
Partitioning and window function support, while present, is less mature than PostgreSQL's.

MariaDB on FreeBSD

MariaDB forked from MySQL in 2009 when Oracle acquired Sun Microsystems. It maintains wire compatibility with MySQL, meaning most MySQL client libraries and applications work without changes. MariaDB has since diverged with its own storage engines, optimizer improvements, and clustering solution.

Installation

sh
pkg install mariadb1011-server mariadb1011-client
sysrc mysql_enable=YES
service mysql-server start
mariadb-secure-installation

Note that MariaDB uses the mysql service name and rc variable on FreeBSD for compatibility.

Key Features

Galera Cluster for synchronous multi-master replication -- every node is writable, with automatic conflict resolution. This is MariaDB's strongest differentiator.
Aria storage engine as a crash-safe replacement for MyISAM.
ColumnStore for analytical (OLAP) workloads.
Temporal tables with system-versioned rows (SQL:2011 compliance).
Improved query optimizer with histogram statistics, subquery materialization, and better join ordering.
Thread pool for handling high connection counts without the process-per-connection overhead.

ZFS Tuning for MariaDB

MariaDB/InnoDB shares the same page size as MySQL:

sh
zfs set recordsize=16K tank/mariadb/data
zfs set primarycache=metadata tank/mariadb/data
zfs set logbias=throughput tank/mariadb/data

The same innodb_doublewrite=OFF recommendation applies when running on ZFS.

Pros

Galera Cluster gives you multi-master replication with no single point of failure.
Better default configuration than MySQL out of the box.
Thread pool handles connection spikes more gracefully than MySQL's thread-per-connection default.
More active open-source development cadence.
Drop-in replacement for MySQL in most applications.

Cons

Divergence from MySQL means some newer MySQL-specific features (like MySQL's native Group Replication internals) are not available.
Some commercial tools and managed services support MySQL but not MariaDB explicitly.
Galera Cluster adds operational complexity -- you need to understand certification-based replication, flow control, and SST/IST recovery.
ColumnStore is useful but not competitive with dedicated analytical databases for large-scale OLAP.

Redis on FreeBSD

Redis is an in-memory data structure store used primarily for caching, session management, real-time leaderboards, rate limiting, and pub/sub messaging. It is not a replacement for a relational database -- it is a complement to one.

Redis runs well on FreeBSD. Its event loop uses kqueue natively, and its single-threaded architecture (with I/O threading available since Redis 6) maps cleanly to FreeBSD's process model.

Installation

sh
pkg install redis
sysrc redis_enable=YES
service redis start

Redis listens on 127.0.0.1:6379 by default. If you need remote access, configure bind and requirepass in /usr/local/etc/redis.conf and consider TLS.

Key Features

Sub-millisecond latency for GET/SET operations on typical hardware.
Rich data structures: strings, hashes, lists, sets, sorted sets, streams, bitmaps, and HyperLogLog.
Pub/Sub for real-time messaging between application components.
Redis Streams for durable, consumer-group-based message processing (similar to Kafka for smaller workloads).
Lua scripting for atomic multi-step operations.
Redis Sentinel for automatic failover and monitoring.
Redis Cluster for horizontal sharding across multiple nodes.

ZFS Tuning for Redis

Redis persistence uses either RDB snapshots (periodic full dumps) or AOF (append-only file). For the AOF directory:

sh
zfs set recordsize=128K tank/redis/data
zfs set compression=lz4 tank/redis/data
zfs set sync=disabled tank/redis/data

Setting sync=disabled is acceptable for Redis when you are using it as a cache layer and can tolerate losing a few seconds of data on power loss. If Redis is your primary data store (not recommended for most workloads), keep sync=standard and ensure appendfsync is set to everysec or always in the Redis configuration.

Pros

Extremely fast -- sub-millisecond reads and writes from memory.
Data structures go far beyond simple key-value; sorted sets and streams solve real architectural problems.
Pub/Sub and Streams reduce the need for a separate message broker in many applications.
Sentinel and Cluster provide production-grade HA and sharding.
Low operational overhead once configured.

Cons

Data set must fit in RAM (plus some overhead). Costs scale with data size.
Single-threaded command processing means one slow command blocks everything (I/O threading helps with network but not command execution).
Persistence mechanisms (RDB/AOF) have tradeoffs -- RDB can lose recent data, AOF can grow large.
Not a relational database. No SQL, no joins, no transactions in the RDBMS sense (though multi/exec provides atomicity).
Redis Ltd. relicensed under SSPL/RSALv2 in 2024. Valkey is the community fork if licensing matters to your organization. On FreeBSD: pkg install valkey.

SQLite on FreeBSD

SQLite is not a client-server database. It is a library linked directly into your application that reads and writes a single file on disk. There is no separate server process, no configuration, no network protocol, and no user management.

This makes SQLite the right choice for a surprisingly large number of use cases: application-local storage, configuration databases, test environments, embedded systems, single-user tools, and read-heavy web applications with modest write concurrency.

Installation

sh
pkg install sqlite3

SQLite is also available as a library (pkg install sqlite3) for linking into C/C++ applications, and most language runtimes (Python, PHP, Ruby, Node.js) ship with SQLite bindings by default.

Key Features

Zero configuration. No server process, no user management, no network exposure.
Single-file database. Easy to back up (copy the file), easy to deploy, easy to version-control.
WAL (Write-Ahead Logging) mode for concurrent readers with a single writer.
Full-text search via FTS5.
JSON functions for document-style queries.
R-Tree indexes for geospatial range queries.
In-process performance -- no network round-trip for queries.

WAL Mode on ZFS

Enable WAL mode for any production use of SQLite:

sql
PRAGMA journal_mode=WAL;

WAL mode allows concurrent readers while a write is in progress, which is critical for web applications. The default rollback journal mode blocks all readers during writes.

For ZFS, the main consideration is that SQLite databases are single files. The ZFS recordsize should match SQLite's page size:

sh
zfs set recordsize=4K tank/data/sqlite

SQLite defaults to 4 KB pages. If you change the page size with PRAGMA page_size, match the ZFS recordsize accordingly.

Pros

No moving parts. No server to crash, no port to firewall, no auth to configure.
Extremely fast for read-heavy workloads -- no network overhead, no serialization.
Ideal for jails and containers where running a database server adds unnecessary complexity.
Battle-tested reliability. SQLite is the most widely deployed database engine in the world (billions of installations across phones, browsers, and embedded devices).
Perfect for development and testing, even if production uses PostgreSQL.

Cons

Single-writer concurrency. Only one process can write at a time (readers are concurrent in WAL mode).
No built-in replication or clustering.
No user authentication or access control -- file permissions are the only protection.
Not suitable for high-write-concurrency workloads or multi-server architectures.
No network protocol means no remote access (by design).

MongoDB on FreeBSD

MongoDB is a document-oriented database that stores data as BSON (binary JSON). It was historically popular for rapid prototyping and applications with flexible schemas.

FreeBSD Support Status

MongoDB's FreeBSD support has been inconsistent. MongoDB Inc. does not provide official FreeBSD builds, and the FreeBSD port relies on community effort to track upstream releases. As of 2026, the FreeBSD ports tree includes MongoDB, but it may lag behind the latest upstream version by several weeks or months.

Installation

sh
pkg install mongodb70
sysrc mongod_enable=YES
service mongod start

Check the FreeBSD ports tree for the latest available version. The package name includes the major version number.

Key Features

Flexible schema. Documents in the same collection can have different fields.
Aggregation pipeline for data transformation and analytics.
Sharding for horizontal scaling across multiple nodes.
Replica sets for automatic failover.
Atlas Search (cloud only) for full-text search integration.
Change Streams for real-time event-driven architectures.

ZFS Tuning for MongoDB

MongoDB's WiredTiger storage engine compresses data by default and writes in its own block format:

sh
zfs set recordsize=64K tank/mongodb/data
zfs set compression=off tank/mongodb/data
zfs set primarycache=metadata tank/mongodb/data

Disable ZFS compression because WiredTiger already compresses data with Snappy or zstd. Double compression wastes CPU for negligible space savings.

Pros

Flexible schema accelerates early development when data models are evolving.
Good horizontal scaling story with sharding.
Aggregation pipeline is powerful for analytics on document data.
Large ecosystem and widespread familiarity among developers.

Cons

FreeBSD is not a first-class platform. Builds lag upstream, and testing coverage is lower.
SSPL license (since 2018) is not considered open source by many organizations and distributions.
PostgreSQL's JSONB covers most document-store use cases with full SQL, transactions, and relational joins. For many teams, adding MongoDB to the stack introduces operational complexity without sufficient benefit.
Higher memory consumption than relational databases for equivalent workloads.
Operational complexity increases significantly with sharded clusters.

Honorable Mentions

InfluxDB

InfluxDB is a time-series database designed for metrics, monitoring, IoT sensor data, and real-time analytics. If you are building an observability stack on FreeBSD (see our FreeBSD monitoring guide), InfluxDB is the natural storage backend.

sh
pkg install influxdb

InfluxDB 1.x is available in the FreeBSD ports tree. InfluxDB 2.x and 3.x have moved to a different architecture; check port availability before planning around newer versions.

Elasticsearch

Elasticsearch is a distributed search and analytics engine built on Apache Lucene. It excels at full-text search, log analysis, and application performance monitoring. On FreeBSD, it runs inside a Linux compatibility layer or via a Java runtime.

sh
pkg install elasticsearch8

Note that Elasticsearch requires a Java runtime and significant memory. Allocate at least 2 GB of heap for anything beyond trivial workloads. Elasticsearch is also SSPL-licensed since 2021; OpenSearch is the community fork.

Memcached

Memcached is a simpler, lighter alternative to Redis when all you need is a distributed key-value cache. It has no persistence, no data structures beyond strings, and no pub/sub -- but it scales horizontally with near-zero configuration.

sh
pkg install memcached
sysrc memcached_enable=YES
service memcached start

If you are caching rendered HTML fragments or query results behind NGINX, Memcached gets the job done with minimal resource consumption.

ZFS Integration Tips for Databases

ZFS is one of FreeBSD's most compelling features for database workloads. Its copy-on-write semantics, checksumming, snapshots, and compression provide capabilities that traditional filesystems cannot match. But incorrect ZFS configuration under a database can hurt performance badly.

General Principles

Match recordsize to the database page size. This is the single most important tuning parameter. Mismatched sizes cause read and write amplification.

| Database | Page Size | ZFS recordsize |

|------------|-----------|----------------|

| PostgreSQL | 8 KB | 8K |

| MySQL | 16 KB | 16K |

| MariaDB | 16 KB | 16K |

| SQLite | 4 KB | 4K |

| MongoDB | 64 KB | 64K |

| Redis AOF | varies | 128K |

Disable doublewrite where ZFS provides equivalent protection. InnoDB's doublewrite buffer protects against torn pages on filesystems that can write partial blocks. ZFS writes are atomic at the record level -- a record is either fully written or not written at all. On ZFS, innodb_doublewrite=OFF is safe and eliminates a significant write overhead. PostgreSQL's full_page_writes can also be set to off on ZFS, though this is more debated -- test in your environment.

Separate data and log datasets. Place transaction logs (WAL, redo logs) on a separate ZFS dataset with different tuning. Logs are sequential and benefit from larger recordsizes and latency-optimized log bias. Data is random-access and benefits from smaller, page-aligned recordsizes.

Set primarycache=metadata for databases that manage their own buffer pool. PostgreSQL, MySQL, and MariaDB all have sophisticated internal caches. Letting ZFS also cache data blocks wastes RAM. Keep primarycache=metadata for the data dataset to let ZFS handle directory lookups efficiently while the database manages data caching.

Use compression=lz4 on data datasets. LZ4 compression is fast enough that the CPU cost is lower than the I/O cost of reading uncompressed blocks. Exception: disable compression for datasets holding data that is already compressed by the database engine (MongoDB with WiredTiger compression, for example).

Consider SLOG devices for synchronous writes. If your database requires sync=always (or the database forces fsync on commits, which most do), a dedicated SLOG (ZFS Intent Log) device -- ideally a low-latency NVMe or Optane drive -- dramatically reduces commit latency.

For a complete ZFS setup reference, see our ZFS guide.

Performance Comparison Notes

Direct performance comparisons between databases are misleading without context. A benchmark showing PostgreSQL beating MySQL on analytical queries while MySQL wins on simple key lookups tells you about the workload, not the database.

That said, some general observations for FreeBSD specifically:

PostgreSQL excels at complex queries, joins, CTEs, and mixed read/write transactional workloads. Its query planner is the most sophisticated of any open-source database.
MySQL/MariaDB tends to be faster for simple primary-key lookups and insert-heavy workloads where InnoDB's clustered index design shines.
Redis operates in a different performance class entirely -- microsecond latency for in-memory operations. Comparing it to disk-based databases is apples-to-oranges.
SQLite is faster than any client-server database for single-connection, read-heavy workloads because it eliminates network and serialization overhead entirely.
MongoDB performance depends heavily on document size, index design, and working set fit in RAM. When the working set exceeds memory, performance degrades sharply.

For all databases on FreeBSD, the kqueue event notification system provides efficient I/O multiplexing. PostgreSQL, Redis, and NGINX (as a database proxy or frontend) all use kqueue natively.

Comparison Table

|-----------------------|----------------|----------------|----------------|----------------|----------------|----------------|

Decision Guide

Choose your database based on your actual workload, not hype:

Choose PostgreSQL if:

You need a general-purpose relational database with strong SQL compliance.
Your application uses complex queries, joins, or analytical workloads.
You want JSONB document storage alongside relational data.
You need geospatial queries (PostGIS).
You value long-term FreeBSD compatibility and community support.

Choose MySQL if:

Third-party software explicitly requires MySQL (WordPress, many legacy PHP apps).
Your team has deep MySQL operational expertise.
You need Oracle commercial support.
Your workload is primarily simple key-value lookups and inserts.

Choose MariaDB if:

You need MySQL wire compatibility with better default settings.
Multi-master clustering (Galera) is a requirement.
You prefer community-driven development over Oracle's roadmap.
Thread pool connection handling matters for your concurrency pattern.

Choose Redis if:

You need a caching layer in front of your primary database.
Session storage, rate limiting, or real-time leaderboards are core requirements.
You need pub/sub messaging without deploying a full message broker.
Sub-millisecond latency is a hard requirement.

Choose SQLite if:

Your application is single-user or single-server with modest write concurrency.
You are building CLI tools, desktop applications, or embedded systems.
You want zero operational overhead -- no server process, no configuration.
You are running inside a FreeBSD jail where a database server is overkill.

Choose MongoDB if:

Your data is genuinely document-oriented with deeply nested structures that resist normalization.
You need horizontal sharding across many nodes for a very large dataset.
Your team has strong MongoDB expertise and existing tooling.
You accept the FreeBSD support limitations and SSPL licensing constraints.

Frequently Asked Questions

What is the best database for a FreeBSD web server?

PostgreSQL. It handles the mixed read/write transactional workloads typical of web applications better than any alternative. Pair it with Redis for session caching and you cover the vast majority of web application database needs. See our NGINX setup guide for the web server side of the stack.

Can I run PostgreSQL and MySQL on the same FreeBSD server?

Yes. They use different ports (5432 and 3306 by default) and have no conflicts. Running both on the same server is common during migration periods. For clean isolation, run each in a separate FreeBSD jail with its own ZFS dataset.

Should I use ZFS or UFS for database workloads on FreeBSD?

ZFS. The copy-on-write semantics, checksumming, snapshots, and tunable recordsize provide capabilities that UFS cannot match. ZFS snapshots alone justify the choice -- you can take consistent, instantaneous backups of a database dataset without stopping the server. The performance overhead of ZFS versus UFS is negligible when tuning parameters are set correctly.

Is Redis still open source?

Redis Ltd. changed the license to SSPL/RSALv2 in March 2024, which is not considered open source by the OSI. The community responded with Valkey, a fork maintained by the Linux Foundation. On FreeBSD, both redis and valkey are available via pkg install. For most users, the practical differences are negligible in 2026, but if licensing matters to your organization, Valkey is the safe choice.

How do I back up a PostgreSQL database on ZFS?

The fastest method is a ZFS snapshot. Stop or checkpoint the database, take a snapshot with zfs snapshot tank/postgres/data@backup-$(date +%Y%m%d), and resume. For online backups without stopping the server, use pg_basebackup for physical backups or pg_dump for logical backups. ZFS snapshots are nearly instantaneous and consume no additional space until the data changes. See our PostgreSQL setup guide for detailed backup procedures.

Which database uses the least memory on FreeBSD?

SQLite uses no memory beyond what your application allocates -- there is no server process. Among client-server databases, Redis is lightweight at idle but scales with your data size since everything is in memory. PostgreSQL and MySQL/MariaDB can be configured to run with modest memory (256 MB of shared buffers for PostgreSQL, equivalent buffer pool for InnoDB), but perform better with more. For jails or VMs with 512 MB or less of RAM, SQLite avoids the overhead question entirely.

Can MongoDB replace PostgreSQL on FreeBSD?

For most workloads, no. PostgreSQL's JSONB type provides document-style storage with the full power of SQL, ACID transactions, and relational joins. MongoDB makes sense when your data is natively document-shaped, you need horizontal sharding at very large scale, and you are willing to accept the FreeBSD support limitations. For a typical web application or API backend, PostgreSQL covers both relational and document use cases without the operational complexity of running two database systems.

Conclusion

FreeBSD is an excellent platform for database workloads. ZFS gives you tuning knobs that no other filesystem offers, jails provide clean isolation for multi-tenant or multi-service architectures, and the operating system's stability under load has been proven at scale by organizations like Netflix and Juniper Networks.

For most FreeBSD deployments, the stack is straightforward: PostgreSQL as your primary data store, Redis for caching and real-time features, and SQLite where a server-based database is overkill. This combination covers an enormous range of applications without unnecessary complexity.

Whatever you choose, take the time to tune your ZFS datasets correctly. A five-minute recordsize adjustment delivers more performance than hours of database configuration tweaking on a mismatched filesystem.