juicedata/juicefs · error

dump trash nodes

Error message

dump trash nodes

What it means

In dbMeta.dumpNodes (pkg/meta/sql_bak.go:141), the trash-node batch produced from `inode >= TrashInode` rows is pushed to the dump channel via dumpResult; any failure there (consumer gone, context canceled, marshal/write error) is wrapped as "dump trash nodes". It surfaces while running `juicefs dump` against a SQL metadata engine.

Source

Thrown at pkg/meta/sql_bak.go:141

	}

	var rows []node
	if err := m.execTxn(ctx, func(s *xorm.Session) error {
		return s.Where("inode >= ?", TrashInode).Find(&rows)
	}); err != nil {
		return err
	}
	nodes := make([]*pb.Node, 0, len(rows))
	var attr Attr
	for _, n := range rows {
		pn := pool.Get().(*pb.Node)
		pn.Inode = uint64(n.Inode)
		m.parseAttr(&n, &attr)
		pn.Data = m.marshal(&attr)
		nodes = append(nodes, pn)
	}
	if err := dumpResult(ctx, ch, &dumpedResult{&pb.Batch{Nodes: nodes}, release}); err != nil {
		return errors.Wrap(err, "dump trash nodes")
	}

	var maxInode uint64
	err := m.execTxn(ctx, func(s *xorm.Session) error {
		var row node
		ok, err := s.Select("max(inode) as inode").Where("inode < ?", TrashInode).Get(&row)
		if ok {
			maxInode = uint64(row.Inode)
		}
		return err
	})
	if err != nil {
		return errors.Wrap(err, "max inode")
	}

	return sqlQueryBatch(ctx, opt, maxInode, func(ctx context.Context, start, end uint64) (int, error) {
		var rows []node
		if err := m.execTxn(ctx, func(s *xorm.Session) error {

View on GitHub (pinned to c9a67b23e8)

Solutions

  1. Check the underlying wrapped error and the dump destination: free disk space, verify the output file/stream is writable, and keep any pipe consumers alive.
  2. Re-run `juicefs dump` with `--threads` lowered and without interruption; use `--skip-trash` if trash content is not needed.
  3. Verify SQL engine connectivity/stability (connection limits, timeouts) if the wrap hides a DB error.
Defensive patterns

Strategy: try-catch

Validate before calling

null

Try / catch

if err := runDump(); err != nil {
    if strings.Contains(err.Error(), "dump trash nodes") {
        logger.Errorf("dump failed while writing trash segment: %v", err)
        // check disk space / output stream, then retry with --skip-trash
    }
}

Prevention

When it happens

Trigger: Running `juicefs dump <meta-url> out.json` (DumpMeta) on a MySQL/PostgreSQL/SQLite volume; the dumpResult send fails because the output writer errored, the destination filled up, or the dump context was canceled/timed out while emitting the trash segment.

Common situations: Disk full on the node writing the dump file; operator Ctrl-C or pipeline (e.g. `| gzip`) closing early; SQL connection dropped mid-dump; very large trash producing long-running dumps that hit timeouts.

Understand the failure class

Background: "failed to write file", "Could not save figure", "Error saving remote file" — file write failed: causes and fixes across languages and libraries — this error's family across 38 libraries.

Related errors


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