# Updates on Test Data **URL:** \ **Category:** Announcements\ **Created:** [April 30, 2024, 3:36pm UTC](https://forum.storj.io/t/updates-on-test-data/26034 "2024-04-30T15:36:45Z")\ **Posts on this page:** 20\ **Page:** 78
**Author:** ![zip](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/zip/32/7813_2.png) [@zip](https://forum.storj.io/u/zip)\ **Post date:** [July 3, 2024, 12:26am UTC](https://forum.storj.io/t/updates-on-test-data/26034/1730 "2024-07-03T00:26:49Z")
16TB full node, version 1.105.? to 1.107.3 database migration took over 70 minutes. Running on Intel Xeon, databases are on some cheap 512GB SATA SSD, piece\_expiration.db was 17GB before the migration. This should be deployed with caution, as it will probably take much much longer on nodes having databases on HDDs. ```auto 2024-07-03T01:06:19+02:00 INFO db.migration.58 Remove unused trash column {"Process": "storagenode"} 2024-07-03T01:26:27+02:00 INFO db.migration.59 Remove unused deletion_failed_at column {"Process": "storagenode"} 2024-07-03T01:44:42+02:00 INFO db.migration.60 Overhaul piece_expirations {"Process": "storagenode"} 2024-07-03T02:18:45+02:00 INFO db.migration Database Version {"Process": "storagenode", "version": 60} ``` And also seeing significant amounts of `"pieces error: filestore error: file does not exist", "errorVerbose": "pieces error: filestore error: file does not exist"` messages as the trash-cleanup-filewalker is running on the node. ---
**Author:** ![Ambifacient](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/ambifacient/32/7815_2.png) [@Ambifacient](https://forum.storj.io/u/Ambifacient)\ **Post date:** [July 3, 2024, 12:33am UTC](https://forum.storj.io/t/updates-on-test-data/26034/1731 "2024-07-03T00:33:40Z")
70 minutes is quite long. My piece expiration DB was around 4GB and migration took around 5 minutes with a 12600k, also with an old SATA SSD. ---
**Author:** ![arrogantrabbit](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/arrogantrabbit/32/11200_2.png) [@arrogantrabbit](https://forum.storj.io/u/arrogantrabbit)\ **Post date:** [July 3, 2024, 1:23am UTC](https://forum.storj.io/t/updates-on-test-data/26034/1732 "2024-07-03T01:23:11Z")
Maybe, but it could have been regular downloads. Should not cause your node to faceplant. This can happen if OOM monitor nukes it due to slow storage. FWIW I also see massive amount of repair requests. Curious to know why ---
**Author:** ![snorkel](https://storj.bcdn.literatehosting.com/letter_avatar/snorkel/32/5_5575768a8748004e209b776fc1b2916d.png) [@snorkel](https://forum.storj.io/u/snorkel)\ **Post date:** [July 3, 2024, 4:25am UTC](https://forum.storj.io/t/updates-on-test-data/26034/1733 "2024-07-03T04:25:05Z")
I’m curious… what bandwidth does this possible customer has, that can’t be satisfied by 22K nodes? ---
**Author:** ![nerdatwork](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/nerdatwork/32/1135_2.png) [@nerdatwork](https://forum.storj.io/u/nerdatwork)\ **Post date:** [July 3, 2024, 4:43am UTC](https://forum.storj.io/t/updates-on-test-data/26034/1734 "2024-07-03T04:43:58Z")
They are a home security company so plenty of bandwidth, IMO. ---
**Author:** ![jammerdan](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/jammerdan/32/1121_2.png) [@jammerdan](https://forum.storj.io/u/jammerdan)\ **Post date:** [July 3, 2024, 6:38am UTC](https://forum.storj.io/t/updates-on-test-data/26034/1735 "2024-07-03T06:38:55Z")
> [@nerdatwork](#): > > They are a home security company And their name starts with V? ---
**Author:** ![unrealSpeedy](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/unrealspeedy/32/1122_2.png) [@unrealSpeedy](https://forum.storj.io/u/unrealSpeedy)\ **Post date:** [July 3, 2024, 7:53am UTC](https://forum.storj.io/t/updates-on-test-data/26034/1736 "2024-07-03T07:53:04Z")
And ends with „t“? 😉 ---
**Author:** ![jammerdan](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/jammerdan/32/1121_2.png) [@jammerdan](https://forum.storj.io/u/jammerdan)\ **Post date:** [July 3, 2024, 8:00am UTC](https://forum.storj.io/t/updates-on-test-data/26034/1737 "2024-07-03T08:00:34Z")
Hopefully it does… 😇 ---
**Author:** ![pasatmalo](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/pasatmalo/32/1127_2.png) [@pasatmalo](https://forum.storj.io/u/pasatmalo)\ **Post date:** [July 3, 2024, 9:15am UTC](https://forum.storj.io/t/updates-on-test-data/26034/1738 "2024-07-03T09:15:19Z")
Just a guess, but this seems related to the fact that some of the initial space reservation data was overwritten due to insufficent randomness. It would make sense that these pieces were deleted by the GC, as we experienced a couple of weeks ago, and now that the TTL is reached as defined in the db, its unable to find these previously deleted files. If this is the case, the warnings should not be cause for concern. On the other hand, if we start to experience elevated amounts of reservation data being deleted by GC instead of TTL, it could mean that there is an underlying issue with the TTL collector and its not correctly deleting the files (because it cant find them). ---
**Author:** ![pangolin](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/pangolin/32/15685_2.png) [@pangolin](https://forum.storj.io/u/pangolin)\ **Post date:** [July 3, 2024, 12:57pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1739 "2024-07-03T12:57:31Z")
Out of curiosity I started a saltlake only node today. This seems to be what the new node selection algo likes, it runs like crazy. Not a big surprice. 😉 ---
**Author:** ![BrightSilence](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/brightsilence/32/6048_2.png) [@BrightSilence](https://forum.storj.io/u/BrightSilence)\ **Post date:** [July 3, 2024, 1:33pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1740 "2024-07-03T13:33:31Z")
> [@nerdatwork](#): > > This makes me wonder if TTL data is really being deleted or not as we only see “count” line in the log not the original `deleted expired piece`. If you want to see those, turn on debug logging. I see them though I’m starting to think debug logging is a bad idea as those writes are now a significant part of the io load for GC and TTL deletes. ---
**Author:** ![littleskunk](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/littleskunk/32/63_2.png) [@littleskunk](https://forum.storj.io/u/littleskunk)\ **Post date:** [July 3, 2024, 1:50pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1741 "2024-07-03T13:50:35Z")
> [@pangolin](#): > > Out of curiosity I started a saltlake only node today. This seems to be what the new node selection algo likes, it runs like crazy. Not a big surprice. 😉 That is never a good idea. A test data only strategy sounds good short term but will backfire long term. The size of this node is limited (TTL) and fully dependent on storj itself. Sure it sounds like we will get additional testdata uploads for up to 3 months but one way or the other I would expect this income source to be lowered and ideally replaced if not outmatched by real customer uploads. At that point you would be looking at the wrong satellite. ---
**Author:** ![pangolin](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/pangolin/32/15685_2.png) [@pangolin](https://forum.storj.io/u/pangolin)\ **Post date:** [July 3, 2024, 2:03pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1742 "2024-07-03T14:03:39Z")
> [@littleskunk](#): > > At that point you would be looking at the wrong satellite. Once the deal is signed I will switch it to US1 only. 😉 BTW: Just noticed this: ```auto 2024-07-03T16:45:19+02:00 INFO collector collect {"Process": "storagenode", "count": 2} ``` I wonder if this is a bug or TTL of only hours? ---
**Author:** ![snorkel](https://storj.bcdn.literatehosting.com/letter_avatar/snorkel/32/5_5575768a8748004e209b776fc1b2916d.png) [@snorkel](https://forum.storj.io/u/snorkel)\ **Post date:** [July 3, 2024, 5:00pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1743 "2024-07-03T17:00:57Z")
And you will have to wait for vetting, in the same time when we get all the juicy customer data. Smart approach. 😅 Believe me, I thought about every strategy, including this one. This one is bad. You will only see your node shrinking, and we will have the same occupation. ---
**Author:** ![arrogantrabbit](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/arrogantrabbit/32/11200_2.png) [@arrogantrabbit](https://forum.storj.io/u/arrogantrabbit)\ **Post date:** [July 3, 2024, 5:05pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1744 "2024-07-03T17:05:13Z")
> [@pangolin](#): > > Once the deal is signed I will switch it to US1 only. But why are you actively trying to prevent node from making you more money? ---
**Author:** ![pangolin](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/pangolin/32/15685_2.png) [@pangolin](https://forum.storj.io/u/pangolin)\ **Post date:** [July 3, 2024, 5:28pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1745 "2024-07-03T17:28:47Z")
> [@snorkel](#): > > And you will have to wait for vetting Vetting is a day or two atm. So I don’t care about. > [@arrogantrabbit](#): > > But why are you actively trying to prevent node from making you more money? Actually I am making more money this way, ingress is significantly higher compared to my other nodes. ---
**Author:** ![arrogantrabbit](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/arrogantrabbit/32/11200_2.png) [@arrogantrabbit](https://forum.storj.io/u/arrogantrabbit)\ **Post date:** [July 3, 2024, 6:06pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1746 "2024-07-03T18:06:55Z")
Did you get to the bottom of it? Why would limiting sources of ingress increases it? ---
**Author:** ![Bryanm](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/bryanm/32/7825_2.png) [@Bryanm](https://forum.storj.io/u/Bryanm)\ **Post date:** [July 3, 2024, 6:45pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1747 "2024-07-03T18:45:20Z")
Just wanted to provide a quick update. For the upcoming holiday / long weekend we are going to pause the uploads for a few days. The repair queue has grown a bit and we don’t want to be paging engineers over the holiday. We will re-evaluate on Monday and determine next steps from there and will let you know ---
**Author:** ![pangolin](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/pangolin/32/15685_2.png) [@pangolin](https://forum.storj.io/u/pangolin)\ **Post date:** [July 3, 2024, 6:51pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1748 "2024-07-03T18:51:53Z")
> [@arrogantrabbit](#): > > Did you get to the bottom of it? Why would limiting sources of ingress increases it? I guess this is because of the new node selection algorithm. When serving only one satellite there is a better chance to be constantly selected and the benefit seems to be bigger than the penalty for not serving the other 3 satellites. Next test will be 4 nodes per HDD but only one satellite each. BTW: This should not be a problem for data security (TOS) because satellites are independent. ---
**Author:** ![Roxor](https://storj.bcdn.literatehosting.com/letter_avatar/roxor/32/5_5575768a8748004e209b776fc1b2916d.png) [@Roxor](https://forum.storj.io/u/Roxor)\ **Post date:** [July 3, 2024, 6:53pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1749 "2024-07-03T18:53:58Z")
Ah… a few days to experience natural free-range organic traffic again: I had forgotten what it was like! Artisanal ones and zeroes from a small selection of actual paying customers! A reminder that the “new normal” is not yet normal… 😉 [Previous page](https://forum.storj.io/t/updates-on-test-data/26034.md?page=77) [Next page](https://forum.storj.io/t/updates-on-test-data/26034.md?page=79)