What causes "set tier for inode %d failed: %w" in juicedata/juicefs?

Inspect the %w-wrapped cause for the metadata engine error.

set tier for inode %d failed: %w

Error message

set tier for inode %d failed: %w

What it means

visitEntry finishes by calling metaFunc(ino) to persist the tier/restore state in metadata. Failure there is wrapped as 'set tier for inode %d failed'. Unlike error 314 (which includes the target tier ID), this variant fires from the generic visitEntry path used by both setTier and objRestore (recursive walks and restore operations), so the wrapped cause may be a metadata update or a restore-flag write failure.

Source

Thrown at cmd/tier.go:333

}
func visitEntry(m meta.Meta, format *meta.Format, ino meta.Ino, attr meta.Attr, objectFunc func(key string) error, metaFunc func(ino meta.Ino) error, checkFunc func(ino meta.Ino, oriTier uint8) bool) error {
	if checkFunc != nil && checkFunc(ino, attr.Tier) {
		return nil
	}
	objs := getObjKeys(m, format, ino, attr.Length)
	if objectFunc != nil {
		for _, key := range objs {
			if key != "" {
				err := objectFunc(key)
				if err != nil {
					return fmt.Errorf("apply object action failed in inode:%d key:%v: err:%s", ino, key, err)
				}
			}
		}
	}
	if metaFunc != nil {
		if err := metaFunc(ino); err != nil {
			return fmt.Errorf("set tier for inode %d failed: %w", ino, err)
		}
	}
	return nil
}

View on GitHub (pinned to c9a67b23e8)

Solutions

Inspect the %w-wrapped cause for the metadata engine error.
Verify metadata engine health/connectivity and retry.
Re-run the command — it is safe to retry; already-processed entries will simply be re-set.
Check the specific inode still exists if the error persists.

Defensive patterns

Strategy: retry

Try / catch

if err := metaFunc(ino); err != nil {
    if isRetryable(err) { time.Sleep(backoff); return metaFunc(ino) }
    return err
}

Prevention

Keep the metadata engine healthy (monitor connections/locks) before bulk tier/restore runs
Re-run the idempotent tier command after transient metadata failures
Avoid heavy concurrent metadata writes during recursive tier walks

When it happens

Trigger: Recursive `juicefs tier`/`juicefs restore` where an entry's metadata update fails — metadata engine outage, concurrent deletion of the inode, or xattr write rejection.

Common situations: Bulk tiering across a large tree hits a metadata engine hiccup; files deleted while the walk is in progress; SQL metadata lock timeouts under concurrency.

Related errors

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