The sector builder FFI interface provides a high level of abstraction, offering little control over sector packing or scheduling policy. This makes it difficult for miner operators to exert any control over this. As a small example, it's not possible to stage and seal an empty sector. Operators instead have to work around this by adding a 1-byte piece, relying on the side-effect of a new sector being opened, and then triggering sealing. Any more complicated policy like sealing some empty sectors while also holding some other sectors open for user data is impossible. I'm aware that this abstract interface is probably by design.
I expect that this storage layer policy is something that miner operators will want tight control over. We should make it easy for operators to define and execute their own such policies. I expect this to result in less code and complexity in the sector builder over time, as the reference implementation need only do the simplest thing.
The path I propose in this issue is to expose more details through the FFI, which go-filecoin and other implementation can then pass through fairly directly to user APIs. We could possibly remove some scheduling logic from the sector builder, placing it instead in high-level business logic code near the "top" of go-filecoin.
Another path is to retain the abstract storage management API which embodies policy, but expose a lower-level API so that operators can write their own storage management. This lower level API could also be accessible by CLI tools, etc, enabling the manual execution of workflows like that described above. If the sector builder exposed a good CLI of its own, perhaps we could avoid plumbing staging and sealing operations through go-filecoin altogether, except where go-filecoin is using that API to service deals.
Acceptance criteria
Primitive piece and sector scheduling operations are available for miner operators to invoke manually, or by scripts/code.
Miners operators can easily have a high level of control over packing and sealing policies.
Risks + pitfalls
A wider FFI expands the contact area between the sector builder and implementation, which may increase integration efforts. OTOH the things required of the sector builder will be simpler and their opaqueness less of a barrier to node implementations
anorth
commented
5 years ago
Description
The sector builder FFI interface provides a high level of abstraction, offering little control over sector packing or scheduling policy. This makes it difficult for miner operators to exert any control over this. As a small example, it's not possible to stage and seal an empty sector. Operators instead have to work around this by adding a 1-byte piece, relying on the side-effect of a new sector being opened, and then triggering sealing. Any more complicated policy like sealing some empty sectors while also holding some other sectors open for user data is impossible. I'm aware that this abstract interface is probably by design.
I expect that this storage layer policy is something that miner operators will want tight control over. We should make it easy for operators to define and execute their own such policies. I expect this to result in less code and complexity in the sector builder over time, as the reference implementation need only do the simplest thing.
The path I propose in this issue is to expose more details through the FFI, which go-filecoin and other implementation can then pass through fairly directly to user APIs. We could possibly remove some scheduling logic from the sector builder, placing it instead in high-level business logic code near the "top" of go-filecoin.
Another path is to retain the abstract storage management API which embodies policy, but expose a lower-level API so that operators can write their own storage management. This lower level API could also be accessible by CLI tools, etc, enabling the manual execution of workflows like that described above. If the sector builder exposed a good CLI of its own, perhaps we could avoid plumbing staging and sealing operations through go-filecoin altogether, except where go-filecoin is using that API to service deals.
Acceptance criteria
Risks + pitfalls
FYI @icorderi @laser @acruikshank