naves

А вы чего сделать-то хотите-то? А то столько букв, а чего конкретно вы хотите получить непонятно.

На китайских noname SSD можно прописать любой серийник и модель через smi mptool или аналогичную утилиту. Можно попробовать в эту сторону пойти. Наклепать 10 дисков, залить туда один и тот же образ, и менять их каждые полгода, ну или сколько они проживут.

Второй раз задаю вопрос, кто вам сказал, что там вообще что-либо должно быть на 8888 порту? вот трейс из Амстердама, 8.8.8.8 точно так же не работает traceroute -T -p 8888 global.quickconnect.to traceroute to global.quickconnect.to (18.196.51.166), 30 hops max, 60 byte packets 1 blablablabla 0.185 ms 0.203 ms 0.183 ms 2 nsx-t.am4.ams.gblnet.net (109.239.132.90) 1.610 ms 1.702 ms 1.769 ms 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * *^C traceroute -T -p 8888 global.quickconnect.to traceroute to global.quickconnect.to (63.188.89.222), 30 hops max, 60 byte packets 1 blablabla 0.191 ms 0.177 ms 0.159 ms 2 nsx-t.am4.ams.gblnet.net (109.239.132.90) 1.046 ms 1.094 ms 1.147 ms 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * *^C traceroute -T -p 443 global.quickconnect.to traceroute to global.quickconnect.to (63.188.89.222), 30 hops max, 60 byte packets 1 blablablabla 0.192 ms 0.183 ms 0.167 ms 2 nsx-t.am4.ams.gblnet.net (109.239.132.90) 0.908 ms 1.019 ms 0.988 ms 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 ec2-63-188-89-222.eu-central-1.compute.amazonaws.com (63.188.89.222) 13.946 ms 13.899 ms *

Ну не драматизируйте так) До подрыва пока далеко. Там хотят еще чутка налоги поднять, но даже это всего лишь небольшое отгибание усиков, до самопроизвольного отпадения чеки еще гнуть и гнуть. А потом выяснится, что и пружина проржавела, без внешнего воздействия не стронуть. Они разве не в доле?

virustotal заблокировали https://habr.com/en/news/1078930/ Прекрасный выстрел. Всех наградить. (с)

Мы переливаем из пустого в порожнее. Выше вы, как будто имели в виду обратное, или сами запутались где TRIM, а где свободное место. Еще раз. Нормальный диск с ячейками с большим ресурсом может работать долго и без trim. Диск со средним ресурсом ячеек, но имеющий большой запас недоступных пользователю ячеек, тоже может долго и успешно работать без TRIM. Ну и крайняя степерь деградации, диск без запаса, с малым ресурсом, занятый данными под 90%. Тут хоть с трим хоть без трим, ресурс свободных ячеек быстро кончится. В теории агонию такого диска можно было бы продлить, если бы прошивка умела блоки данных из ячеек, которые долго не перезаписывали, переносить в изношенные ячейки. Но умеют ли так делать прошивки большой вопрос. И вот именно в этом месте trim влияет на продолжительность работы всего диска. Если FTL таблица знает, что 80% диска свободна, то она размазывает запись по всему объему ячеек. Если почти весь диск занят, то задрачиваются именно свободные ячейки. В случае, если все-таки есть дырки в свободных секторах в больших блоках данных, то прошивка может начать дефрагментацию этих дырок, и балансировку ячеек. А если trim не было, то откуда прошивка узнает, что там есть дырки, которые можно дефрагментировать? Неправильно поняли) Тоже неверно. Так можно и про любой linux написать. А если еще вспомнить, что ячейки могут вообще в разных режимах работать TLC или QLC. Мы можем записать первый терабайт офигительно быстро, а потом хоба, и запись пошла в режиме QLC, и усе умерло.

https://en.wikipedia.org/wiki/Layer_four_traceroute трейс на определенный порт TCP sudo traceroute -T -p 8888 global.quickconnect.to

Из Европы порт 8888 тоже закрыт. Откуда он вообще взялся? nslookup global.quickconnect.to Non-authoritative answer: Name: global.quickconnect.to Address: 63.188.89.222 Name: global.quickconnect.to Address: 18.196.51.166 curl -v --connect-timeout 10 63.188.89.222:8888 * Trying 63.188.89.222:8888... * Connection timed out after 10001 milliseconds * Closing connection 0 curl: (28) Connection timed out after 10001 milliseconds curl -v --connect-timeout 10 18.196.51.166:8888 * Trying 18.196.51.166:8888... * Connection timed out after 10001 milliseconds * Closing connection 0 curl: (28) Connection timed out after 10001 milliseconds

Окей, postgres НЕ высокопроизводительная НЕсовременная СУБД, ну и mysql тоже туда запишем, говно мамонта. К слову, тут буквально полчаса назад умер диск CT4000MX500SSD1 [4,00 TB] Power_On_Hours 20274 и даже божественная убунта его не смогла спасти своим еженедельным тримом Mon 2026-09-14 00:18:40 MSK 6 days left Mon 2026-09-07 00:03:58 MSK 1h 29min ago fstrim.timer fstrim.service ставьте crucial говорили они, денег нет, говорили они...

лол Расскажите это postgres или любым другим СУБД, они бедненькие рассчитывают, что если скинули журнал на диск, значит он записался ФС. Даже специальный флаг, блин, используют fsync (не путать с fdatasync), и ждут, чтобы ФС отрапортовала, что записала и данные и журнал. А ФС в свою очередь ждет, что накопитель не нае, а честно запишет данные на поверхность HDD или на чип ПЗУ, а не случайно протеряет данные при потере питания. >Для стабильной работы как много требований должен Кому, простите должен? китайский производитель лаоваю ничего не должен) Жаль Сааба нет в теме, он там все время делал расчеты, как 100 камер по 25 кадров в секунду генерят стопицот IOPS записи на диски, поэтому нужно отказаться от ФС и сразу писать на диск напрямую.

так это не у меня хотелки, а у людей выше, у которых в винде trim волшебным образом работает, а в debian его включение это хотелка юзера. ага, это проблема дебиана, который по умолчанию настроен работать на любом говне. Даже железный болван гугла пишет: Откуда он это придумал? https://openzfs.github.io/openzfs-docs/man/v2.4/7/zpoolprops.7.html#autotrim Be aware For lower-end devices бадабумс. ext4 убила десктопную ссд в сервере. так речь о баге, внутри прошивки, который не может заремапить внутренний сектор, если долбят в один и тот же внешний LBA. Что характерно, баг закрыли со словами, типа ну не делайте так, и болеть не будет.