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

Check the wrapped Redis error and address connectivity/stability, then re-dump.

get dirUsedInodesKey err: %w

Error message

get dirUsedInodesKey err: %w

What it means

Wrapped by dumpDirStat in redis_bak.go:440 when HGetAll on dirUsedInodesKey() (per-directory used-inode counts) fails during a dump. It follows the data-length step, so it typically indicates a transient Redis failure mid-dump rather than a key that is missing — the error is on the HGetAll call itself, not the hash contents.

Source

Thrown at pkg/meta/redis_bak.go:440

	if err != nil {
		return fmt.Errorf("get dirDataLengthKey err: %w", err)
	}
	for k, v := range vals {
		inode, err := strconv.ParseUint(k, 10, 64)
		if err != nil {
			logger.Warnf("parse length stat inode: %s: %v", k, err)
			continue
		}
		length, _ := strconv.ParseInt(v, 10, 64)
		stats[Ino(inode)] = &pb.Stat{
			Inode:      inode,
			DataLength: length,
		}
	}

	vals, err = m.rdb.HGetAll(ctx, m.dirUsedInodesKey()).Result()
	if err != nil {
		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)

View on GitHub (pinned to c9a67b23e8)

Solutions

Check the wrapped Redis error and address connectivity/stability, then re-dump.
Enable TCP keepalives / raise client timeouts so long dumps are not dropped.
Retry the dump and discard the partial output file.
If failovers are frequent, dump from a stable primary or take a Redis backup (SAVE/BGSAVE) and dump the snapshot.

Example fix

// keep connection alive during long dumps
juicefs dump "redis://primary:6379/1" out.json  # run over stable network, retry on failover

Defensive patterns

Strategy: retry

Validate before calling

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

Try / catch

if err := dumpDirStat(...); err != nil {
    if strings.Contains(err.Error(), "dirUsedInodesKey") {
        // transient failure between hashes: back off and retry the full dump
    }
    return err
}

Prevention

Avoid dumping through idle-timeout load balancers; keep connections alive.
Retry after any failover — this step follows earlier successful reads.
Raise client timeouts when dirstat datasets are large.
Discard partial output files between retries.

When it happens

Trigger: Running `juicefs dump` when the second HGetAll (dir used-inodes hash) returns an error after the data-length hash was read fine — failover, connection reset, timeout.

Common situations: Redis primary failover between commands; load balancer idly dropping the connection mid-dump; memory/timeout limits on very large dirstat datasets.

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/9ff2d1a36e56eed1. Report an issue: GitHub.