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
- 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.
- Re-run `juicefs dump` with `--threads` lowered and without interruption; use `--skip-trash` if trash content is not needed.
- 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
- Ensure ample free disk space for the dump file before starting `juicefs dump`.
- Avoid piping the dump into consumers that may exit early; write to a file first.
- Use `--skip-trash` when trash content is not needed to shorten the dump.
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
- max inode
- The entry of the root inode was not found
- failed to marshal segment %s: %v
- DumpMeta error: %v
- get counter %s
AI-assisted analysis of juicedata/juicefs@c9a67b23e8 (2026-09-06).
Data as JSON: /api/errors/36ae4a0a9af854d5.
Report an issue: GitHub.