Crystal Pony
04/02/2024 (Tue) 00:17
No.10116
del
>>10113
>I even got HTTP 429 with a 290-second wait between save-to-wbm requests: hoping this is an April Fools joke.
So far haven't seen any 429s with a 400 second sleep between requests. That's about one order of magnitude longer than what worked fine in the past.
>>10113
>ponibooru_60k: QmS4...RzFF.car
which is:
>76415 blocks (750096454 bytes) [~60K files, default settings, imported in about 1 hour from 2024-04-01T21:12:52.440924702Z -> 2024-04-01T22:09:34.860576019Z into a HDD]
254327 - 76415 = 177,912, so I have enough free inodes for the other part which is larger. Thing I noticed when backing up: if you copy the files in /a/.ipfs/datastore/ to /b/.ipfs/datastore/ without overwriting any files in /b, then everything that was pinned in /a won't show up as pinned in /b. However, after doing that copy, you can do the hours-long pinning process in /b to pin all that was pinned in /b, assuming you already rsynced all of the blocks in ./blocks/ from src to dest. "Hours-long" if you have tens or hundreds of gigabytes, and it can be done completely offline; gotta do a similar thing when rechecking hundreds of gigabytes of torrents after moving from one HDD to another. (If you rsync /a/.ipfs/ to /b/.ipfs/ and /b was totally empty before, then it will instantly have all of /a's pins due to the 1:1 copy of ./datastore/ plus the blocks and maybe a couple other files; datastore is an essential part because if that folder is empty then it shows up with zero pins).
>I even got HTTP 429 with a 290-second wait between save-to-wbm requests: hoping this is an April Fools joke.
So far haven't seen any 429s with a 400 second sleep between requests. That's about one order of magnitude longer than what worked fine in the past.
>>10113
>ponibooru_60k: QmS4...RzFF.car
which is:
>76415 blocks (750096454 bytes) [~60K files, default settings, imported in about 1 hour from 2024-04-01T21:12:52.440924702Z -> 2024-04-01T22:09:34.860576019Z into a HDD]
254327 - 76415 = 177,912, so I have enough free inodes for the other part which is larger. Thing I noticed when backing up: if you copy the files in /a/.ipfs/datastore/ to /b/.ipfs/datastore/ without overwriting any files in /b, then everything that was pinned in /a won't show up as pinned in /b. However, after doing that copy, you can do the hours-long pinning process in /b to pin all that was pinned in /b, assuming you already rsynced all of the blocks in ./blocks/ from src to dest. "Hours-long" if you have tens or hundreds of gigabytes, and it can be done completely offline; gotta do a similar thing when rechecking hundreds of gigabytes of torrents after moving from one HDD to another. (If you rsync /a/.ipfs/ to /b/.ipfs/ and /b was totally empty before, then it will instantly have all of /a's pins due to the 1:1 copy of ./datastore/ plus the blocks and maybe a couple other files; datastore is an essential part because if that folder is empty then it shows up with zero pins).