What causes "get dirUsedSpaceKey err: %w" in juicedata/juicefs?

Read the wrapped Redis error, fix the underlying issue (network/auth/memory), and re-run the dump.

get dirUsedSpaceKey err: %w

Error message

get dirUsedSpaceKey err: %w

What it means

Wrapped by dumpDirStat in redis_bak.go:458 when HGetAll on dirUsedSpaceKey() (per-directory used-space totals) fails while dumping directory statistics. This is the third of three sequential HGetAll calls; the Redis error is wrapped with the key name and aborts the dump.

Source

Thrown at pkg/meta/redis_bak.go:458

		return fmt.Errorf("get dirUsedInodesKey err: %w", err)
	}
	for k, v := range vals {
		inode, err := strconv.ParseUint(k, 10, 64)
		if err != nil {
			logger.Warnf("parse inodes stat inode: %s: %v", k, err)
			continue
		}
		inodes, _ := strconv.ParseInt(v, 10, 64)
		if q, ok := stats[Ino(inode)]; !ok {
			logger.Warnf("stat for used inodes not found: %d", inode)
		} else {
			q.UsedInodes = inodes
		}
	}

	vals, err = m.rdb.HGetAll(ctx, m.dirUsedSpaceKey()).Result()
	if err != nil {
		return fmt.Errorf("get dirUsedSpaceKey err: %w", err)
	}
	for k, v := range vals {
		inode, err := strconv.ParseUint(k, 10, 64)
		if err != nil {
			logger.Warnf("parse space stat inode: %s: %v", k, err)
			continue
		}
		space, _ := strconv.ParseInt(v, 10, 64)
		if q, ok := stats[Ino(inode)]; !ok {
			logger.Warnf("stat for used space not found: %d", inode)
		} else {
			q.UsedSpace = space
		}
	}

	ss := make([]*pb.Stat, 0, min(len(stats), redisBatchSize))
	cnt := 0
	for _, s := range stats {

View on GitHub (pinned to c9a67b23e8)

Solutions

Read the wrapped Redis error, fix the underlying issue (network/auth/memory), and re-run the dump.
Retry during lower load or co-locate the dump command with the Redis instance.
Raise client timeouts (read-timeout in the metadata URL) for very large dirstat hashes.
On managed Redis, check service logs for restarts/failovers at the failure timestamp.

Example fix

// before
juicefs dump redis://managed:6379/1 out.json   // fails at large hash
// after
juicefs dump "redis://managed:6379/1?read-timeout=300s" out.json

Defensive patterns

Strategy: retry

Validate before calling

redis-cli -h primary -p 6379 ping && redis-cli -h primary -p 6379 hlen <dirUsedSpaceKey>

Try / catch

if err := dumpDirStat(...); err != nil {
    if strings.Contains(err.Error(), "dirUsedSpaceKey") {
        // final hash read failed mid-dump: fix stability, retry the dump
    }
    return err
}

Prevention

Raise read-timeout (e.g. ?read-timeout=300s) for large dir-stat datasets.
Check managed-Redis logs for restarts/expiring sessions at the failure time.
Schedule dumps in low-traffic windows on stable infrastructure.
Always re-dump from scratch; never resume from a partial output.

When it happens

Trigger: Running `juicefs dump` when the final HGetAll (dir used-space hash) errors after the previous two hashes succeeded — typically a mid-dump connection failure, timeout, or cluster routing error.

Common situations: Long-running dumps across unstable networks; Redis restarting under memory pressure; auth token/session expiring mid-dump on managed Redis services.

Understand the failure class

Background: Database query failed: Internal Server Error 500s wrapping SQL, Prisma, and connection failures — what to check first — this error's family across 16 libraries.

Related errors

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