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

Fix the underlying Redis error reported after the colon (connectivity, auth, cluster config) and re-run the dump.

get dirDataLengthKey err

Error message

get dirDataLengthKey err: %w

What it means

Wrapped by dumpDirStat in redis_bak.go:423 when HGetAll on dirDataLengthKey() (the hash of per-directory aggregated data lengths) fails while dumping directory statistics. The dump's dirstat section is aborted and the Redis error is surfaced with the key name for diagnosis.

Solutions

Fix the underlying Redis error reported after the colon (connectivity, auth, cluster config) and re-run the dump.
Increase the Redis client timeout for large hashes or dump over a faster link.
If keys are being evicted (maxmemory-policy), use noeviction or raise maxmemory so the hash remains intact.
Retry the dump; if it repeatedly fails at the same key, verify the key exists and is healthy with redis-cli HLEN.

Example fix

// before: default timeouts drop long HGETALL
// after: raise timeouts in the metadata URL
juicefs dump "redis://primary:6379/1?read-timeout=120s" out.json

Defensive patterns

Strategy: retry

Validate before calling

redis-cli -h primary -p 6379 hlen <dirDataLengthKey>  # confirm hash readable before dump

Try / catch

if err := dumpDirStat(...); err != nil {
    if strings.Contains(err.Error(), "dirDataLengthKey") {
        // raise read-timeout or retry on a stable connection
    }
    return err
}

Prevention

Increase read-timeout in the metadata URL for very large dirstat hashes.
Use a noeviction maxmemory policy so hashes aren't evicted mid-scan.
Dump over a fast, stable link or co-locate with the Redis instance.
Verify the key with HLEN via redis-cli if failures repeat at the same step.

When it happens

Trigger: Running `juicefs dump --dirs` (or a dump that includes dir stats) when HGetAll on the dir-data-length hash errors — connection drop, cluster MOVED, auth failure, or timeout.

Common situations: Large dirstat hashes taking long enough to hit a network timeout; Redis under memory pressure evicting/failing commands; dumping through a proxy that drops long connections.

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

Appendix: source

Thrown at pkg/meta/redis_bak.go:423

	}
	if err := m.dumpQuotas(ctx, &userQuotas, UserQuotaType); err != nil {
		return err
	}
	if err := m.dumpQuotas(ctx, &groupQuotas, GroupQuotaType); err != nil {
		return err
	}
	return dumpResult(ctx, ch, &dumpedResult{msg: &pb.Batch{
		Quotas:      dirQuotas,
		UserQuotas:  userQuotas,
		GroupQuotas: groupQuotas,
	}})
}

func (m *redisMeta) dumpDirStat(ctx Context, opt *DumpOption, ch chan<- *dumpedResult) error {
	stats := make(map[Ino]*pb.Stat)
	vals, err := m.rdb.HGetAll(ctx, m.dirDataLengthKey()).Result()
	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)
	}

View on GitHub (pinned to c9a67b23e8)