Blixt Documentation v2.9

Upgrading

Move a BlixtFS deployment to a new release.

Before you upgrade

  1. Check Release-specific steps below for every release between yours and the target.
  2. Back up the metadata database. See Backup and recovery.
  3. Choose a quiet time. Clients see a short interruption while servers restart.

Docker

docker pull blixtfs/standard:2.9.1
docker stop blixt && docker rm blixt
# Run your usual docker run command with the new tag.

On startup BlixtFS creates any database tables that don’t exist yet. It doesn’t change tables that already exist. When a release changes one, the step is listed below. Writes that were staged but not yet uploaded when the old container stopped are uploaded by the new one.

With Docker Compose, change the image tag in compose.yaml, then:

docker compose pull && docker compose up -d

Kubernetes

helm upgrade bfs ./blixtfs -n bfs --reuse-values --set image.tag=2.9.1

Kubernetes replaces pods one at a time, and clients reconnect as servers come back.

Release-specific steps

From 2.8.1 to 2.9

Check your bucket specs first. From 2.9, an attribute BlixtFS doesn’t recognise stops it from starting, where earlier releases logged a warning and carried on. A deployment running on a typo such as :readonl starts today and won’t after the upgrade. See Buckets.

Update two tables. BlixtFS creates tables that don’t exist yet, but never changes tables that do, and 2.9 adds columns to two of them. Run these once, just before or just after upgrading:

-- The consistency-check queue gained four columns. Dropping it is safe:
-- queued checks are requeued by the next periodic check, and only the
-- history of recent checks is lost. BlixtFS recreates the table on start.
DROP TABLE fsck_queue;

-- Open file handles now record the protocol that opened them.
ALTER TABLE filehandles
  ADD COLUMN client_protocol varchar(16) NOT NULL DEFAULT 'unspecified';

Against the single-node image’s embedded database:

docker exec -e PGPASSWORD=bfs blixt \
  psql -h localhost -p 4710 -U bfs bfs -c 'DROP TABLE fsck_queue;'

If you will serve CoreWeave buckets on an existing PostgreSQL database, add the new provider to the cloud type first:

ALTER TYPE cloud_type ADD VALUE IF NOT EXISTS 'coreweave';

Rolling back

Rolling back to the previous release works the same way, with the old tag. When a release changes the database in a way the previous release can’t read, its release notes say so. Restore the database backup you took before upgrading in that case.

Checking the result

  • The startup banner shows the new version: docker logs blixt | grep "Blixt File System"
  • Clients can list and read files.
  • No errors in the log, and uploads are draining (see Monitoring).