Skip to content

Features

leBLOB runs on one server today, with one disk or several. This page lists what it does now and what it doesn't do yet. The S3 compatibility reference lists the operations one by one.

S3 API

Buckets

  • CreateBucket, HeadBucket, ListBuckets, GetBucketLocation, and DeleteBucket on an empty bucket.
  • Versioning: enabled or suspended per bucket, with delete markers and a listing of all versions. See Versioning, lifecycle rules and tags.
  • Lifecycle rules: expiring objects, erasing older versions, removing lone delete markers and aborting stale multipart uploads, filtered by prefix, size or tags.
  • CORS rules, for pages in a browser.
  • Canned ACLs, private and public-read, for anonymous reads. See Public access, CORS and forms.

Objects

  • PutObject, GetObject, HeadObject, DeleteObject, bulk DeleteObjects and CopyObject.
  • ListObjectsV2 and ListObjects v1, with prefix, delimiter and pagination, and ListObjectVersions.
  • Single-range GET, with 206 answers.
  • Conditional reads (If-Match, If-None-Match, If-Modified-Since, If-Unmodified-Since), conditional writes (If-Match, If-None-Match) and conditional deletes (If-Match).
  • Stored headers: Content-Type, Content-Encoding, Content-Disposition, Content-Language, Cache-Control, Expires and x-amz-meta-*.
  • Object tags, by request or with the x-amz-tagging header on a PUT, a copy or a multipart upload.
  • Browser form uploads (POST policy), signed with SigV4.
  • Keys kept byte for byte: foo/, a//b, a/../b, Unicode, + and % all round-trip and list correctly.

Multipart uploads

  • CreateMultipartUpload, UploadPart, CompleteMultipartUpload, AbortMultipartUpload, ListParts and ListMultipartUploads.
  • UploadPartCopy, with ranges, versions and conditions on the source.
  • AWS-style multipart ETags, ending in -N.
  • Retrying CompleteMultipartUpload after a lost reply succeeds, for a day.
  • Object-level checksums for multipart objects, composite and full-object, worked out from the parts and checked against what the client claims.

Signing and integrity

  • SigV4 in the Authorization header and in presigned URLs.
  • Signed and unsigned payloads, aws-chunked streaming, and trailing checksums.
  • Content-MD5, x-amz-content-sha256 and x-amz-checksum-* for CRC32, CRC32C, CRC64NVME, SHA-1 and SHA-256 are verified, stored and returned.

Addressing

  • Path-style (/bucket/key) and, with a base domain, virtual-hosted (bucket.s3.example.org) addressing.
  • S3 XML errors, with x-amz-request-id on every answer.
  • TLS in the server itself, or behind a reverse proxy.

Durability and storage

  • A write is on disk, flushed, before the client is told it succeeded. A failure before that point leaves nothing visible: no object is ever seen half written.
  • Reads and listings see all acknowledged writes.
  • Several disks on one server, with a chosen number of copies of each object. A read moves to another copy when one fails, even in the middle of a response. See Disks and copies.
  • Scrub checks every copy against its MD5 in the background, and repair replaces bad or missing copies.
  • A disk can be drained and removed.
  • Deleted bytes are removed after a grace period, so reads in progress can finish.

These are tested on real block devices: power cuts on ext4, XFS and btrfs, and disks that die, fill up or return wrong data under a running server. See Testing.

Operations

  • One command, leblob serve, with no other service to run.
  • Access keys from the command line, with full access or scoped to buckets at three levels. See Access keys.
  • leblob fsck compares the metadata with what is on disk.
  • leblob backup and leblob restore for the metadata, while the server runs. See Backup and restore.
  • A health endpoint at /-/health and Prometheus metrics at /-/metrics. See Monitoring.
  • Structured logs with the request ID in each line, and a graceful shutdown.
  • A store written by an earlier release opens in a later one. Samples from each release test this.

Security

  • The server listens on 127.0.0.1 unless told otherwise.
  • Every x-amz-* header has to be covered by the signature, presigned URLs included.
  • A scoped key is checked before any bucket is looked up, so an access error says nothing about what exists.
  • Making a bucket or an object public takes the admin level on a scoped key, so a stolen write key can't expose data.
  • Server-side encryption with a key the client sends (SSE-C), over HTTPS. The server keeps no key. See Encryption with your own key.
  • A request leBLOB can't honour gets 501 NotImplemented. A client asking for SSE-S3 encryption, for example, isn't told its data is encrypted when it isn't.

Not built yet

  • Clusters. Several servers, replication between them and several locations are the next phase. Roadmap has the plan.
  • Bucket policies and IAM. Access is by key, per bucket, at three levels. A store relying on MinIO's policies isn't served yet.
  • Object Lock and retention.
  • SSE-S3 and SSE-KMS, encryption with keys the server manages.
  • Bucket tagging, lifecycle transitions and the x-amz-expiration header.
  • GetObjectAttributes, and GetObject or HeadObject by partNumber.
  • Quotas, event notifications and a web console.

These are left out unless a real need appears: SigV2 and SigV4A, ACL grants beyond the two canned ACLs, storage classes other than STANDARD, S3 Select, Inventory, Analytics and website hosting.