What causes "writechunk %s: %s" in juicedata/juicefs?

Check the metadata backend health and connectivity at the moment of failure (ping Redis, check MySQL/etcd/TiKV logs)

writechunk %s: %s

Error message

writechunk %s: %s

What it means

Reported when m.NewSlice() — the metadata call that allocates a new chunk/slice ID before writing file data — returns a non-zero errno. NewSlice increments the `nextChunk` counter in the metadata engine (pkg/meta/base.go:2150); the error is the errno from that counter increment (backend unavailable, write failure, serialization error). It appears as `writechunk <file>: <errno>` and only occurs when mdtest runs with -write > 0.

Source

Thrown at cmd/mdtest.go:77

			}
		}
	}
	return nil
}

func createFile(jfs *fs.FileSystem, bar *utils.Bar, np int, root string, d int, width, files, bytes int) error {
	m := jfs.Meta()
	for i := 0; i < files; i++ {
		fn := path.Join(root, fmt.Sprintf("file.mdtest.%d.%d", np, i))
		f, err := jfs.Create(ctx, fn, 0666, umask)
		if err != 0 {
			return fmt.Errorf("create %s: %s", fn, err)
		}
		if bytes > 0 {
			for indx := 0; indx*meta.ChunkSize < bytes; indx++ {
				var id uint64
				if st := m.NewSlice(ctx, &id); st != 0 {
					return fmt.Errorf("writechunk %s: %s", fn, st)
				}
				size := meta.ChunkSize
				if bytes < (indx+1)*meta.ChunkSize {
					size = bytes - indx*meta.ChunkSize
				}
				if st := m.Write(ctx, f.Inode(), uint32(indx), 0, meta.Slice{Id: id, Size: uint32(size), Len: uint32(size)}, time.Now()); st != 0 {
					return fmt.Errorf("writeend %s: %s", fn, st)
				}
			}
		}
		f.Close(ctx)
		bar.Increment()
	}
	if d > 0 {
		dirs := make([]int, width)
		for i := 0; i < width; i++ {
			dirs[i] = i
		}

View on GitHub (pinned to c9a67b23e8)

Solutions

Check the metadata backend health and connectivity at the moment of failure (ping Redis, check MySQL/etcd/TiKV logs)
Reduce --threads to lower concurrent pressure on the nextChunk counter
If Redis: raise maxmemory or clear eviction pressure; if SQLite: ensure no other process holds the db and the disk isn't full
Retry the run; slice-ID allocation is transiently retriable once the backend recovers
Verify the counter key wasn't manually deleted/corrupted (`juicefs fsck` can help validate metadata)

Example fix

// before
$ juicefs mdtest --threads 64 -write 1048576 redis://localhost /t  # backend overloaded
// after
$ juicefs mdtest --threads 8 -write 1048576 redis://localhost /t

Defensive patterns

Strategy: retry

Validate before calling

// verify meta backend is responsive before a write benchmark
if err := m.Ping(meta.Background()); err != 0 {
    logger.Fatalf("meta engine unreachable: %v", err)
}

Try / catch

// retry transient slice-id allocation failures
for i := 0; i < 3; i++ {
    if st := m.NewSlice(ctx, &id); st == 0 {
        break
    } else if i == 2 {
        return fmt.Errorf("writechunk %s: %s", fn, st)
    }
    time.Sleep(100 * time.Millisecond)
}

Prevention

Right-size --threads so the metadata backend isn't saturated
Monitor Redis maxmemory / MySQL disk space during benchmarks
Watch meta engine latency metrics; back off when counters increment slowly
Avoid manual edits to meta counter keys (nextChunk)

When it happens

Trigger: `juicefs mdtest -write N` where the metadata backend fails on the INCR/counter update for nextChunk: Redis connection dropped, MySQL/SQLite write error, TiKV/etcd increment failure, or backend timeout under heavy multi-thread load.

Common situations: Large parallel mdtest (-threads high) saturating the metadata engine; Redis maxmemory reached so INCR fails; transient network partition between client and Redis/SQL backend mid-run; SQLite database locked by another process.

Related errors

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