Сильно ли изнашивается SSD, если на нём держать и компилить сорцы браузера?

Ты из 2011 пишешь? Берешь нормальный ssd и компилишь себе хоть каждый день

Если я ничего не путаю, Гугл официально рекомендует собирать Хромиум именно на SSD, и чтоб было 100 гигов свободного места.

В общем, «не мона, а нуна»! :)

Вот насчёт внешнего — не знаю, не знаю… Если это про USB — как бы скорости сборки не поплохело…

Хемингуэй. Но у того рассказ был всего в 6 слов…

Сильно ли такие процедуры будут изнашивать SSD?

Нет

Для компиляции нужно столько оперативы, что её должно хватить. Потом можно прикрутить ccache

Ну, жесткий диск тоже изнашивается. И, в отличии от SSD, он изнашивается как при чтении, так и при записи

Если USB пропускает 5 Гбит/с, на практике, со всеми издержками, это даст около 500 Мбайт/с

На практике это дает ~330 Мб/с линейных чтения/записи (да, одинаково и на чтение, и на запись, т.е «упирается» в USB/мост USB-SATA и их «со всеми издержками») и ~40000 IOPS (т.е. раза в два меньше, чем напрямую подключить в SATA). Диск LiteON LCS-256M6S (SATA, MLC NAND, контроллер Marvell 88SS9188), внешний бокс Gembird на контроллере ASMedia ASM1153, USB 3.0.

Если есть что дополнить и возразить, буду рад.

Всегда пожалуйста.

P.S. Насчет IOPS не уверен, давно мерил, года три назад. Может быть разбежка 33000-44000, чтение/запись по-разному. Как-то так.

У меня на RaspberryPi в корпусе DeskPi Pro с SATA SSD тоже 300 с чем-то линейных чтения/записи. Не знаю, на что грешить – то ли на плату-переходник из корпуса, то ли на реализацию USB в малинке, то ли на то и другое. Меня, впрочем, всё устраивает, и я примерно этого и ожидал. IOPS не мерил.

Заказал себе Ugreen CM400, который распиарен и, вроде как, должен быть быстрее. Во всяком случае, честный 1 Гбайт/с на номинальных 10 Гбит/с обещают. Посмотрим, как он себя на моем USB 3.0 в ноутбуке покажет.

ccache не поможет сэкономить оперативку. Но да, позволит частично сгладить неудобство компиляции в tmpfs

SSD при чтении тоже изнашивается, там просто ресурс на порядки выше и при н/у им можно принебречь

При чтении файлы в Linux попадают в page cache, и в дальнейшем их чтение ничем не отличается от чтения из tmpfs (пока для кэша хватает памяти)

Можно ссылку на ворох моих сомнительных тезисов?

Вот тут один просыпался. Сколько надо читать, чтобы износилось что именно?

А что изнашивается при записи, как происходит запись?
Почему?
Как происходит чтение?

Ну-ну. Берём покупаем внешний USB 3.0 ssd, измеряем скорости, разбираем, а там SATA через переходник. Втыкаем SATA напрямую в материку и скорости заметно повыше и SMART доступен.

но компактность

Было полно внешних SSD размером 2,5″ и сейчас хватает моделей заметно больше обычной флешки. Как вы ранее написали, компактность это M.2 2230.

И есть уже техника в рознице с этим USB4/Thunderbolt, и даже внешние кейсы с ним же.

У кого из ЛОРовцев эта техника есть в живую, пусть поднимут руки.

Также я не упомянул о влиянии USB на случайное чтение и случайную запись

Это проблема многих дешёвых USB SSD, основное на что их позиционируют — перенос больших объёмов данных, а при копировании больших файлов без разницы скорость случайных операций.

Я намеренно смешал в одну кучу

В лучше бы клещами из ТС вытащили описание его железа, а то всё про компиляцию в tmpfs пишут, а может у него всего 16 Гб ОЗУ...

Перезарядка ячейки; относительно высокое напряжение применяется к ячейке, прям течёт ток и в/из неё переносится заряд; честно сказать не помню, что именно там деградирует; гораздо «менее напряжно», ведь для чтения нужно просто считать потенциал.

Ещё какие-то жесты доброй воли от меня нужны? Или может сразу перейдешь к своей прямой дискуссионной обязанности обосновать, что ты там себе выдумал?

и чтоб было 100 гигов

Как-то много. В gentoo в ebuild для chromium от 12 до 25 Гбайт в зависимости от опций сборки.

а во-вторых перекомпиливать все с нуля после любой перезагрузки это жесть

Это gentoo реальность, там, конечно, можно продолжить сборку пакета, но emerge так не делает.

и SMART доступен

Через USB доступен SMART, если мост поддерживает UASP (USB Attached SCSI Protocol), вроде бы. Но могу ошибаться. Моя коробка умеет и SMART показать, и TRIM передать на воткнутый в нее SSD. Потому ее и брал.

При чем тут гента и компиляция проектов, которые ты разрабатываешь (правишь)

Гентушные пакеты я в основном в тмпфс компилирую, так как это один раз происходит и никаких правок в эти сорцы никто не вносит

ведь для чтения нужно просто считать потенциал.

Вы про это (Read disturb errors): https://ru.transcend-info.com/embedded/technology/read-disturbance

Нет, я про рядовое чтение и износ от него, в сравнении с рядовой записью и износом от нее. Read disturb не настолько част, чтобы им ssd ушатывать.

Есть которые поддерживать, есть которые нет, покупая готовый usb ssd не определить. А ещё ЕМНИП, есть чипы которые условно поддерживат, — в ядре стоит запрет, но можно разрешить и SMART будет читаться, но если не повезёт сотрётся прошивка ssd.

Все, что может сломаться, сломается обязательно. А что не может, сломается все равно.

Я написал про gentoo, так как, ИМХО, большинство посоветоваших tmpfs в этом треде являются гентушниками. Поэтому логично, что про пересборку они не подумали.

Плюс ТС не уточнил, как именно он собрался править исходники, может готовые патчи накладывать и один раз компилить одну версию.

Ну нужно дождаться flash с один байт на ячейку и умных прошивок, которые следят за качеством чтения блоков и перезаписывают их. Тогда и появятся SSD, ушатываемые чтением :)

Если готовые патчи, то гента идеальный вариант, патчить через /etc/portage/patches/ и собирать в tmpfs (если хватает рамы)

3 года в хвост и гриву юзаю corsair 1tb mp600, канпеляция, синк сорцов и тп.

стата

Temperature:                        37 Celsius
Available Spare:                    100%
Available Spare Threshold:          5%
Percentage Used:                    7%
Data Units Read:                    34 851 537 [17,8 TB]
Data Units Written:                 104 847 570 [53,6 TB]

заполнен постоянно на ~90%, ибо сорцов много.

это на уровне сопромата износ. даже провода на столбах и те срок жизни имеют

Короче, я тут почитал что люди десятилетиями используют и в хвост и в гриву свои ССД и у них всё ок, так что моя точка зрения полностью аннулирована.
(а к деградации приводит относительная высокость напряжения или это в принципе свойство сопряжённое с протеканием тока по ячейке и высокость лишь ускоряет процесс?)

Ещё какие-то жесты доброй воли от меня нужны?

Сделай дистр который будет популярнее всех других ОС.

(а к деградации приводит относительная высокость напряжения или это в принципе свойство сопряжённое с протеканием тока по ячейке и высокость лишь ускоряет процесс?)

Это в принципе свойство перезарядки чего угодно. Да и вообще гонять заряды в сравнении с не гонять.

Сделай дистр который будет популярнее всех других ОС.

Я верю только в NixOS, и в другие дистры вкладываю усилия через скрежет зубовный. А NixOS популярной не будет, как минимум еще лет 10.

Это в принципе свойство перезарядки чего угодно. Да и вообще гонять заряды в сравнении с не гонять.

Ну я склоняюсь к тому, что и чтением можно подубить, как и все современные чипы на тонких тех.процессах.

Память ssd разбивается на блоки. Когда на ssd записывается допустим 512 байт, то в начале блок, куда будет производиться запись, считывается в память ssd, потом в считанный блок вносятся изменения 512 байт и блок записывается на ssd.

Размер блока куда больше 512 байт.

Так что реальный размер записанных данных на ssd будет больше, чем суммарный размер файлов. Чем большее количество файлов записывается - тем больше данных перезаписывается.

Но в ssd применяются алгоритмы оптимизации записи.

Это в принципе свойство перезарядки чего угодно. Да и вообще гонять заряды в сравнении с не гонять.

Не совсем так. К примеру, RAM постоянно перезаряжается.

ну-ну, покажите 250-гиговый ссд с петабайтом tbw))) что, нет такого? только махровый энтерпрайз за много-много денег? отож, отож…

Во-первый, я написал «порядка». А во-вторых, а че не 16-гиговый?

На тебе «офигенно энтерпрайзную» серию WD Red. 1000 TBW начинается с заоблачных, недоступных простому консьюмеру $50 (--sarcasm). Потянешь?

Я переодически компилирую chromium, Firefox и libreoffice при обновлениях, которые приходят периодически в репы. За год использования ssd износа по данным smartctl не заметил. Правда я настроил ccache и компилирую в tmpfs, что снижает использование ssd и его износ.

Ты объяснил основную причину усиления записи. Спасибо, что напомнил.

Заглянул я в репозиторий Firefox. Действительно, там куча мелких файлов. Запишет ли их SSD подряд при распаковке тарбола? Думаю, да, если диск не забит под завязку. В общем, вангую, что усиление записи при распаковке будет незначительным. Но могу и ошибаться.

Бинарников после сборки со всеми инклудами должно получиться меньше. Тут я с большей уверенностью предполагаю, что усиление записи должно быть небольшим.

Вынужден признать, что усиление записи несколько ослабляет аргумент о гарантированных сотнях терабайт записи. Но ослабляет незначительно, даже не на порядок.

Ну-ну.

Я понимаю, о чем вы.

Сам не доверяю готовым внешним SSD. Внутрь запихнут явно не топовый накопитель. Переходник с USB тоже не всегда будет адекватный. Меня беспокоит возможное отсутствие trim. Вы упомянули, что SMART может быть недоступен.

Ценами на готовые внешники не интересовался, но что-то мне подсказывает, что маркетологи в них будут видеть NVMe с добавочной ценностью или флешку с добавочной ценностью.

В общем, мой выбор – диск отдельно, карман отдельно, чтобы самому контролировать ценность, цену, риски и компромиссы.

Как вы ранее написали, компактность это M.2 2230.

Ну, даже внешний 2280 чуть более удобен, чем SATA, в плане размещения на узких столах, таскания в карманах, подключения к планшетам, телевизорам и магнитолам.

В лучше бы клещами из ТС вытащили описание его железа, а то всё про компиляцию в tmpfs пишут, а может у него всего 16 Гб ОЗУ…

ТС решил мне нахамить и с тех пор не отвечает. Лучше мне подскажите. Заодно и ему поможете, если у него действительно 16 ГБ ОЗУ. В общем, моя основная машина – бюджетный Dell с i3 7th Gen. В нём два ядра, четыре потока. ОЗУ добита до максимальных 16 Гб. SSD не жалко. Начал читать, но еще не начал собирать LFS. Присматриваюсь к Gentoo. Ждать компилляции LO или браузера готов хоть все выходные. В общем, мне эти комбайны собирать на SSD в четыре потока, выделив под компилляцию 8–12 Гб рамы?

Смотря с какой интенсивностью компилять. Могу сказать за свой опыт - если собирать firefox, раз в неделю, то самого дешманского ssd хватит примерно на 1 год, если каждый день, то может пару месяцев прослужит. Если собирать, только «что нужно», и не частно то прослужит лет 5...

если собирать firefox, раз в неделю, то самого дешманского ssd хватит примерно на 1 год, если каждый день, то может пару месяцев прослужит

Учитывая огромный ресурс современных дисков что может вызывать такой быстрый их износ? Чтобы они так быстро выходили из строя там каждую компиляцию надо по терабайту наверное переписывать.

Не 1TB, но думаю GB 100-120 за один раз в режиме записи/чтения данных проходит... За год можно сосчитать. Но у меня тогда стоял самый дешевый ssd на 128GB, я его специально брал, чтобы не жалко был - чисто на китайской плате. У меня отношение к SSD сложилось, как к флешкам. Сдохнит и хрен с ним. Главное, вовремя делать бекапы грамотно организовать,и все проблема решена.

Если SSD хороший, то нифига. Это ж не флешка какая нибудь

LFS или gentoo выбирайте сами, можете и то и другое в chroot'ах собирать. Для всего, кроме браузеров 12 Гбайт нормально. Но для гуглохрома в 4 потока 12 Гбайт может не хватить. Про сборку хромого в tmpfs с 16 Гб ОЗУ можно и не мечтать, только на ssd. И в этих условиях вобще желательно смотреть, не начинается ли актвно использоваться swap, что сильно затормозит сборку. Проще остановить и начать заново, чем ждать когда со свопом закончится. Это проблема всех систем сборки, что на ходу нельзя уменьшить число потоков сборки.

Если запретить сборку тяжёлых пакетов Для отдельных пакетов запретить параллельную сборку? , то при 16 Гбайт с остальным можно экспериментировать со сборкой в tmpfs.

Раньше на потребление памяти при компиляции хромиума сильно влиял параметр jumbo_file_merge_limit, не знаю, остался ли он сейчас или jumbo сборку отменили.

И по времени сложно сказать, может выходных и хватит. Я собирал хромиум на 4-х ядреном феноме в три потока, чтобы можно было при компиляции как-то работь, тытрубу в 720p смотеть, ЕМНИП, где-то 30-36 часов.

Некоторые советуют ccache (под gentoo), тогда, если сборка упадёт и будет запущена с начала, то результаты компилции будут браться из кеша и до места падения будет быстрее, чем компилировать. Но объём ccache нужно гигов 10-15. Или можно перезапускать сборку, make и пр. достаточно умные и сначала смотрят, есть ли объекный файл и какая у него временная метка, и только при необходимости запускает компилятор.

Самый дешманский SSD может и вести себя как флешка — совсем низкая производительность на случайном чтении/записии, смысла в нём для компиляции мало.

У меня swap на SSD всегда был, работали больше 5 лет.

На днях собирал chromium, семь потоков (-j7), 32GB RAM, немногим дольше, чем за ночь собралось (FX-9590 4.0GHz).

PS: а swap лучше отключать, и включать только когда вот прям специфичные задачи, например, нужно долгое время работы программы, которая перманентно течет…

Другое интересует: как быстро умирает ssd, если на него ничего не писать и не читать с него, кроме как один раз записать информацию и два-три раза в 10 лет прочитать записанную информацию. Физически насколько живучий ssd накопитель. Сам по себе.

если на него ничего не писать и не читать с него, кроме как один раз записать информацию и два-три раза в 10 лет прочитать записанную информацию

Он так деградирует. Это же флеш память, заряд просто уйдет за это время и твой SSD превратится в кирпич.