What causes "read wrong data: expected %x, got %x" in juicedata/juicefs?

Bypass any proxy/CDN and format directly against the storage endpoint

read wrong data: expected %x, got %x

Error message

read wrong data: expected %x, got %x

What it means

The data read back from the object store does not match the data written. JuiceFS compares the test object byte-for-byte; a mismatch means the backend is corrupting, truncating, or returning different content — possibly a broken proxy or an incompatible S3 implementation.

Source

Thrown at cmd/format.go:366

		if err := store.Put(ctx, key, bytes.NewReader(data)); err != nil {
			return fmt.Errorf("Failed to put: %s", err)
		}
	}
	// GLACIER storage class doesn't allow read after write
	if _, ok := ctx.Value(object.TierKey{}).(uint8); ok {
		return nil
	}
	p, err := store.Get(ctx, key, 0, -1)
	if err != nil {
		return fmt.Errorf("Failed to get: %s", err)
	}
	data2, err := io.ReadAll(p)
	_ = p.Close()
	if err != nil {
		return err
	}
	if !bytes.Equal(data, data2) {
		return fmt.Errorf("read wrong data: expected %x, got %x", data, data2)
	}
	err = store.Delete(ctx, key)
	if err != nil {
		// it's OK to don't have delete permission, but we should warn user explicitly
		logger.Warnf("Failed to delete, err: %s", err)
	}
	return nil
}

func test(ctx context.Context, store object.ObjectStorage) error {
	key := "testing/" + randSeq(10)
	data := make([]byte, 100)
	utils.RandRead(data)
	nRetry := 3
	var err error
	for i := 0; i < nRetry; i++ {
		err = doTesting(ctx, store, key, data)
		if err == nil {

View on GitHub (pinned to c9a67b23e8)

Solutions

Bypass any proxy/CDN and format directly against the storage endpoint
Verify backend integrity by round-tripping a file manually with the provider CLI (put then get, then checksum)
Upgrade or check the S3-compatible server for known data-corruption issues
Re-run format — a concurrent collision on the test key resolves itself on retry

Example fix

// before
endpoint via caching proxy: https://cdn.example.com
// after
endpoint direct: https://s3.us-east-1.amazonaws.com (or disable cache for PUT/GET)

Defensive patterns

Strategy: validation

Validate before calling

// manual round-trip check
// aws s3 cp testfile s3://bucket/t && aws s3 cp s3://bucket/t back && sha256sum testfile back

Try / catch

err := doTesting(ctx, store, key, data)
if err != nil && strings.Contains(err.Error(), "read wrong data") {
    // backend corruption or proxy interference; compare checksums manually
}

Prevention

Use the storage endpoint directly, not through caching proxies/CDNs
Round-trip a test file with checksums before formatting
Keep S3-compatible servers up to date; avoid known-buggy gateways
Avoid concurrent formats sharing the same test key path

When it happens

Trigger: `juicefs format` connectivity test where Get succeeds but the returned bytes differ from the written pattern — middleboxes/caches rewriting content, a misbehaving S3-compatible server returning another object, or key collisions from a shared/prefixed bucket used concurrently.

Common situations: CDN or caching proxy in front of the store serving stale content; non-conformant S3 clones (some NAS gateways) mangling binary data; two concurrent formats to the same test key racing.

Understand the failure class

Background: Checksum mismatch errors: "checksum verification failed", "digest mismatch", "expected vs actual checksum" — what they mean and how to fix them — this error's family across 41 libraries.

Related errors

AI-assisted analysis of juicedata/juicefs@c9a67b23e8 (2026-09-06). Data as JSON: /api/errors/a814de9cb4448427. Report an issue: GitHub.