juicedata/juicefs · error

delete delayed slice %d affected %d rows

Error message

delete delayed slice %d affected %d rows

What it means

Returned inside the delayed-slice cleanup transaction when deleting the delslices row affects an unexpected number of rows (not 0 or 1). A non-unit affected count means concurrent cleanup raced in an unexpected way, so the txn aborts to keep refcounts consistent.

Source

Thrown at pkg/meta/sql.go:4087

			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
		}
		if claimed {
			for _, s := range ss {
				var ref = sliceRef{Id: s.Id}
				err := m.simpleTxn(ctx, func(tx *xorm.Session) error {
					ok, err := tx.Get(&ref)

View on GitHub (pinned to c9a67b23e8)

Solutions

1. Retry; the competing cleanup usually completes and the row disappears
2. Recurring occurrences: check for multiple GC instances running against the same volume

When it happens

Trigger: Thrown at pkg/meta/sql.go:4087 when the library encounters an invalid state.

Common situations: See trigger scenarios.

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