juicedata/juicefs · error

claim delayed slice %d

Error message

claim delayed slice %d

What it means

After the scan callback says a delayed slice is fully cleaned, the code deletes the delslices row to atomically "claim" the cleanup (rollback restores it if the transaction fails). If the DELETE statement itself errors, the failure is wrapped as "claim delayed slice %d" and gc aborts.

Source

Thrown at pkg/meta/sql.go:4081

			if err != nil {
				return errors.Wrapf(err, "get delslices %d", ds.Id)
			}
			if !found {
				return nil
			}
			m.decodeDelayedSlices(del.Slices, &ss)
			clean, err := scan(ss, del.Deleted)
			if err != nil {
				return err
			}
			if !clean {
				return nil
			}

			// Deleting the delayed row claims cleanup; rollback restores it on failure.
			affected, err := tx.Delete(&delslices{Id: del.Id})
			if err != nil {
				return errors.Wrapf(err, "claim delayed slice %d", del.Id)
			}
			if affected == 0 {
				return nil
			}
			if affected != 1 {
				return fmt.Errorf("delete delayed slice %d affected %d rows", del.Id, affected)
			}
			for _, s := range ss {
				if _, e := tx.Exec(m.sqlConv("update chunk_ref set refs=refs-1 where chunkid=? AND size=?"), s.Id, s.Size); e != nil {
					return e
				}
			}
			m.genLog(ctx, tx, time.Now().UnixNano(), "CLEANUP_TRASH_SLICES(%d,%d)", del.Id, del.Deleted)
			claimed = true
			return nil
		})
		if err != nil {
			return err

View on GitHub (pinned to c9a67b23e8)

Solutions

1. Re-run `juicefs gc` — the claim is transactional so it is safe to retry
2. Avoid running multiple `juicefs gc` instances concurrently against the same volume
3. Check the wrapped cause for deadlock details; run gc serially or in low-traffic windows
4. Check DB connectivity/stability if failures recur

if err != nil && strings.Contains(err.Error(), "claim delayed slice") {
    // transactional claim failed; safe to re-run `juicefs gc`
}

When it happens

Trigger: `juicefs gc` trash-slice cleanup on SQL metadata where the transactional DELETE FROM delslices fails due to a database error, deadlock, or lost connection while holding the row lock.

Common situations: Concurrent gc processes from multiple clients contending for the same delslices row; DB deadlock detection killing the transaction; network interruption during the gc transaction.

Related errors

• get delslices %d
• scan slice refs
• create table delegationToken: %s
• create table changeLog: %s
• format is not inserted

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