Open stuberman opened 1 month ago
2024-05-28T01:34:19.376Z DEBUG stores paths/local.go:106 accounting existing files {"id": {"Miner":116748,"Number":1}, "fileType": "cache", "path": "/seal/cache/s-t0116748-1", "used": 309237682176, "overhead": 484472310988}
Those are just debug logs, fine to ignore; Do you have GOLOG_LOG_LEVEL=debug set in your environment
2024-05-28T02:00:54.037Z ERROR cu/ffi ffi/sdr_funcs.go:237 reflink treed -> sealed failed, falling back to slow copy, use single scratch btrfs or xfs filesystem {"error": "reflink is not supported on this OS or file", "sector": {"ID":{"Miner":116748,"Number":1},"ProofType":8}, "cache": "/seal/cache/s-t0116748-1", "sealed": "/seal/sealed/s-t0116748-1"}
This log is correct, and everything will still work, but will make TreeR compute slower.
In lotus the PC1/2 path wasn't really optimized, in curio we made it much smarter.
Lotus:
Note that there are multiple sub-optimal things here:
All that is fixed in Curio
sc-02-data-tree-d.dat
contains exactly the same data in the first 32G of the file as the "unsealed" sector file(Curio also constructs the finalized "Unsealed" sector in the finalize step by truncating the TreeD file)
Some action items here:
storage attach
when a --seal filesystem isn't XFS (or BTRFS, tho that one is likely not great for scratch space)
Sealing disk is NVMe using EXT4, OS is Ubuntu server 22.04.4 LTS (GNU/Linux 5.15.0-105-generic x86_64)
PC1 and PC2 succeeding:
ls -Alh /seal/cache/s-t0116748-1