filecoin-watchdog
commented
18 hours ago @Filedrive-ops Allocator Application Compliance Report
The allocator did not ask many additional questions about how the data was prepared. It would be worth streamlining the process with these actions. It might be good to refer to this proposal
| 4.95 PiB granted to clients: | Client Name | DC |
|---|---|---|
| AsiaTelevision Limited | 3.95PiB | |
| WuhanNalai Film and Television Culture Media Co., Ltd. | 1PiB |
Example 1 - AsiaTelevision Limited #5 This client initially requested 2 PiB of data. According to the allocator's rules, he should have stored 3 replicas. During the talks with the client, the allocator agreed and granted another 2 PiB of data (totalling 4 PiB); however, according to the report, there are still only two replicas. I am unsure about the duplicates created - the allocator and the client encountered some problems with DDO and retrieval rate, but please provide details about where the duplicates in the report came from. Overall, the allocator took a thorough approach, asked many questions, checked reports, and declared clear rules that he adhered to. The client had problems with SPs, but the allocator tried to help him. KYC/KYB was performed outside the system. Information about this can be found in the comments. The allocator performs SP checks, and the client himself remembers to send the evidence to the allocator. Discussions were kept in a thread so they could be reviewed easily. Retrieval for 5 of 7 SPs is unavailable.
Example 2 - WuhanNalai Film and Television Culture Media Co., Ltd. #3 This client declared 4 replicas; however, according to the report, there are still only two replicas, whereas all the DC was granted. The first replica has almost 900TiB of data. How come?
Overall, the allocator took a thorough approach, asked many questions, checked reports, and declared clear rules that he adhered to.
KYC/KYB was performed outside the system. Information about this can be found in the comments. The allocator performs SP checks, and the client himself remembers to send the evidence to the allocator. Discussions were kept in a thread so they could be reviewed easily. All 5 SPs have retrieval at 0% or unavailable.
This dataset was stored multiple times already: https://github.com/ipfsforcezuofu/ipfsforce-allocator/issues/8 https://github.com/ipfsforcezuofu/ipfsforce-allocator/issues/2 https://github.com/VenusOfficial/Pathway-VFDA/issues/40 https://github.com/VenusOfficial/Pathway-VFDA/issues/22 https://github.com/search?q=repo%3Afilecoin-project%2Ffilecoin-plus-large-datasets+wuhan+nalai&type=issues
I realise this is a private dataset, however, it would be good to clarify with the client why so many copies were essential to store.
https://github.com/filecoin-project/notary-governance/issues/1030 https://github.com/filedrive-team/Filecoin-Plus-Pathway/issues
After finding that the DDO model isn't the primary reason for the low retrieval rate, we have started encouraging and supporting our clients to rollback from the DDO to a non-DDO ordering model.
The potential demand from clients exceeds 20 PiB.
Our company's major business is data services. One of our free tools, go-graphsplit, which splits large datasets into graph slices suitable for making deals on the Filecoin Network, is very popular in the market. Based on feedback from our clients, we plan to change the storing of piece information in separate files to database. This will help our FIL+ clients manage pieces more easily and efficiently.