juicedata/juicefs · error

statistic: %v

Error message

statistic: %v

What it means

When `juicefs status --trash` (or the trash section) runs, it walks trash slices/files and pending-deleted objects to compute statistics via m.CleanupTrash-like callbacks (here, the pending deleted files scan). If the underlying scan (e.g. ListPendingDeletedFiles through fs layer) errors, Status wraps it as 'statistic'. This is the trash-statistics walk failing, not the core status.

Source

Thrown at pkg/meta/status.go:99

					trashSlicesSpinner.IncrInt64(int64(s.Size))
				}
				return false, nil
			},
			func(_ uint64, size uint32) (bool, error) {
				pendingDeletedSlicesSpinner.IncrInt64(int64(size))
				return false, nil
			},
			func(_ Ino, size uint64, _ time.Time, count int64) (bool, error) {
				trashFileSpinner.Add(count, int64(size))
				return false, nil
			},
			func(_ Ino, size uint64, _ int64) (bool, error) {
				pendingDeletedFileSpinner.IncrInt64(int64(size))
				return false, nil
			},
		)
		if err != nil {
			return fmt.Errorf("statistic: %v", err)
		}

		trashSlicesSpinner.Done()
		pendingDeletedSlicesSpinner.Done()
		trashFileSpinner.Done()
		pendingDeletedFileSpinner.Done()
		stat.TrashSliceCount, stat.TrashSliceSize = trashSlicesSpinner.Current()
		stat.PendingDeletedSliceCount, stat.PendingDeletedSliceSize = pendingDeletedSlicesSpinner.Current()
		stat.TrashFileCount, stat.TrashFileSize = trashFileSpinner.Current()
		stat.PendingDeletedFileCount, stat.PendingDeletedFileSize = pendingDeletedFileSpinner.Current()
	}

	if sections != nil {
		sections.Setting = format
		sections.Sessions = sessions
		sections.Stat = stat
	}
	return nil

View on GitHub (pinned to c9a67b23e8)

Solutions

1. Run `juicefs status META-URL` without --trash to confirm the core status works, isolating the issue to the trash/object-storage scan.
2. Verify object storage access with the same credentials/bucket from the volume format (try mc ls / aws s3 ls on the bucket).
3. Retry during a quieter period; large pending-deleted queues make the scan long — allow `juicefs gc` to finish first to shrink the backlog.
4. If the inner error indicates metadata corruption of trash records, restore metadata from a `juicefs dump` backup.

Example fix

// before (fails only with trash scan)
juicefs status "redis://127.0.0.1:6379/1" --trash
// after — validate object storage first, then retry
aws s3 ls s3://mybucket
juicefs status "redis://127.0.0.1:6379/1" --trash

# verify object storage access with the same credentials as the volume format
mc ls myminio/mybucket >/dev/null && echo "object storage OK" || echo "check credentials/bucket"

if err := execStatusWithTrash(metaURL); err != nil && strings.Contains(err.Error(), "statistic") {
    log.Printf("trash stats unavailable, core status still valid: %v", err)
    return execStatus(metaURL) // fall back to plain status
}

When it happens

Trigger: Running `juicefs status META-URL --trash` when the pending-deleted-files enumeration callback returns an error — object storage listing failures, metadata records for trash unreadable, or the scan being aborted by an internal error mid-walk.

Common situations: Object storage credentials revoked or bucket removed while trash stats are gathered; network flakiness during a long trash scan on volumes with many pending deletes; metadata engine errors while iterating trash records.

Understand the failure class

Background: 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty — this error's family across 20 libraries.

Related errors

• changelog is not enabled, use `juicefs config %s --changelog
• clone failed: %v
• compact [%d:%s] error: %s
• Invalid trash days: %d
• mtime of key should be within 30 seconds, but got %s

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