Как таковых нет, у каждого свое, лучше ориентироваться на Load_Cycle_Count. Приблизительно на «среднестатистическом» считается 300к к смерти.

wd red - ресурс 600 000 https://www.ixbt.com/infopages/wd-red.shtml

Вот, только это не start/stop а Load_Cycle_Count. В любом случае start/stop не будет меньше LCC

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

Тьфу, поправка «В любом случае start/stop не будет больше LCC»

чем меньше - тем лучше:) наибольшее количество выходов эл.техники из стоя происходит в момент включения.

еще засивит от конструкции hdd. если он паркуется на диск (старый хдд), а не на рампу, то ресурс вкл/выкл у него будет меньше. но как правило у старых hdd запас прочности больше(меньше экономили на компонентах, не было цветовой дифференциации [s]штанов[/s] и тд)

Кстати...

да, забыл добавить тег «спуфно» :-)

В остальном, всем спасибо!

Порядок цифр ясен.

Spoofing, а как твои успехи на ниве экономии ресурсов?

ресурс экономлю )) живу в tmpfs припеваючи, т.е. вот прям совсем в tmpfs. жёсткие/твердые диски лежат на полочке. думаю пора от них избавиться, совсем. есть одна единственная флешка (в будущем возьму вторую для резерва), с которой я загружаюсь и куда я сохраняю все свои данные и перезаписываю образ обновлённой ОС. сидя в ней же. ещё есть VDS, куда так же заливаются бэкапы (VDS тоже работает в tmpfs, а диск там используется чисто под данные). таким образом 3 места: работающий компьютер, флешка и удалённая вдс. все три разом не откажут. на другие компьютеры в доме линуксы загружаются через PXE, просто включаю их в розетку.

ты наверное мог заметить как в последнее время я проявляю активность на тему [CRUX в редакции MATE] и [Как GRUB2 подружить с цветными конями], сейчас я практикуюсь с созданием конечных ISO образов. скоро выложу все свои скрипты и наработки, только в «чистовик» их перепишу :) но прямо сейчас уже есть например такой вариант [Загрузка любого дистрибутива в RAM], т.е. ты хоть прям сейчас тоже можешь перейти в tmpfs, завернув весь свой / (корень) в initrd. и командами kexec -l /vmlinuz --initrd=/initrd && kexec -e начать использовать свою ОСь в tmpfs.

для комфортной работы 16гб за глаза, выше 10гб съело только однажды, когда mozjs в чруте собирал (когда делал сборку CRUX MATE).

# mount | head -1
overlay on / type overlay (rw,relatime,lowerdir=/overlay/persistent:/lower,upperdir=/overlay/upper,workdir=/overlay/work

# df -h
Filesystem      Size  Used Avail Use% Mounted on
overlay         7.9G  1.9G  6.1G  24% /
dev             7.5G     0  7.5G   0% /dev
tmpfs           7.9G  668K  7.9G   1% /run
shm             7.9G  116M  7.8G   2% /dev/shm

# fdisk -l
Disk /dev/loop0: 548.44 MiB, 575066112 bytes, 1123176 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop1: 51.47 MiB, 53960704 bytes, 105392 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

такая картина. 548.44мб это сколько занимает squashfs образ системы в памяти. 51.47 MiB это оверлей в tmpfs, т.е. столько данных я «нагадил» поверх него, и если захочу, их надо будет сохранить, или нет. а после перезагрузки получить снова чистую ОС, какая была до использования. это просто офигенно. «никакие вирусы не страшны» :)

такой же подход я использую абсолютно на всех устройствах, даже на VDS. тут правда один нюанс. если VDS сломается, то она больше не загрузится т.к. на её диске нету ОС, поэтому мне придётся установить какую-нибудь условную убунту на VDS, затем залить по scp туда образ для вдски и kexec'нуться в него прямо из убунты. и всё. немного потраченого времени, за то всё просто. и в случае точно такого же «взлома» вдски, я просто перезаливаю туда образ по новой.

все образы у меня уже настроены под каждую железку, я просто запускаю скриптом их перегенерацию «с нуля». например.

# find firstvds/overlays/
firstvds/overlays/
firstvds/overlays/20-persistent
firstvds/overlays/20-persistent/usr
firstvds/overlays/20-persistent/usr/lib
firstvds/overlays/20-persistent/usr/lib/locale
firstvds/overlays/20-persistent/usr/lib/locale/locale-archive
firstvds/overlays/20-persistent/usr/share
firstvds/overlays/20-persistent/usr/share/terminfo
firstvds/overlays/20-persistent/usr/share/terminfo/r
firstvds/overlays/20-persistent/usr/share/terminfo/r/rxvt-unicode-256color
firstvds/overlays/20-persistent/usr/share/terminfo/r/rxvt-unicode
firstvds/overlays/20-persistent/root
firstvds/overlays/20-persistent/root/.ssh
firstvds/overlays/20-persistent/root/.ssh/authorized_keys
firstvds/overlays/20-persistent/etc
firstvds/overlays/20-persistent/etc/profile
firstvds/overlays/20-persistent/etc/rc.conf
firstvds/overlays/20-persistent/etc/rc.d
firstvds/overlays/20-persistent/etc/rc.d/net.ipv4.eth0

образ для вдски. всё уже настроено, просто скирптом, ссылку на который я дал ссылку выше, формирую initrd образ, заливаю на вдс и kexec'аюсь туда.

ощщем, настоятельно рекомендую изменить подход и переходить на tmpfs. :) по крайней мере если используешь линуксы.

Впечатляюще.

Канонично.

Джедайский подход в стиле Tails, достойно уважения ;). Сам поглядываю в эту сторону, но приходится круто менять привычки

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

Но зачем? Лучше превратить их в usb-диски и зашифровать с ног до головы. Пока сеть есть не везде, потому приходится таскать один внешний диск, на котором хранятся документы и прочие важные вещи. Один запасной в погребе валяется, аккуратно среди банок с огурцами, да ещё один, умело замаскированный под мёртвый — внутри старого, пыльного и неиспользуемого настольника в сотнях километрах от первого.

[Как GRUB2 подружить с цветными конями], сейчас я практикуюсь с созданием конечных ISO образов.

Ты часом не знаешь, есть ли способ подружить GRUB2 с нормальным шифрованием? В него недавно наконец поддержку LUKS2 добавили, но он всё ещё не умеет работать с голым dm-crypt и не имеет адекватной поддержки ключевых файлов в виде неразмеченных областей диска, не умеет в offset и прочее.

Я нашёл сборник патчей как раз для вышеперечисленных штук и попробовал собрать с ними. Беглый осмотр следов после нескольких попыток сборки показал, что заплатки придётся круто дорабатывать. Рано или поздно у меня дойдут до этого руки, но вдруг это велосипедостроительство?

А если получится вот это всё добавить, то жить станет много лучше — можно будет шифровать образы на флешках, шифровать сами флешки, etc.

приходится круто менять привычки

это да. одно дело загрузиться в лайв, полистать сайты, но даже тут если представить, что ты загружаешься каждый день и каждый день приходится заново вводить пароль на сайтах — надоедает. (p.s.: я так не делаю, профиль тоже скидываю «куда-нибудь», а потом подгружаю, но просто для примера привёл)

и совсем другое дело, когда оказывается, что ты в таком режиме обязан работать, и лишний раз в голове держать мысль, как электричество может пропасть в любой момент, или что какая-нибудь железка вызовет kernel panic просто так. но спустя неделю отпускает. просто когда ты сделал что-то важное, это надо аки «git commit» сохранить на флешку. если уж разработчикам это не доставляет дискомфорта, то должно быть нормально.

скорее всего придётся этот момент тоже доработать, добавить ещё один overlay отдельным файлом, который будет сохраняться в полу-автоматическом режиме куда-нибудь. или что-нибудь в этом роде. подумаю.

подружить GRUB2 с нормальным шифрованием

нет, не знаю, и скажу классическое «не нужно». )) ну вот зачем тебе какой-то огрызок команд, если из того же граба можно загрузиться в маленький initrd? разве есть какая-то принципиальная разница, что тебе комп выдал grub, а grub выдал миниатюрные vmlinuz/initrd со всем необходимым, но при этом полноценно работающим.

более того скажу, ты когда создаёшь FAT32-раздел с грабом для загрузки с UEFI, можно же прямо в него этот vmlinuz/initrd и впихнуть. и будет тебя не один /EFI/BOOT/BOOTX64.EFI, а ещё два рядом лежать. так ли это страшно? а ещё как ты знаешь, в таком случае можно вообще отказаться от GRUB2, т.к. Linux с EFI_STUB (включённым по-умолчанию) может грузиться как самостоятельный /EFI/BOOT/BOOTX64.EFI, только в CMDLINE ему прописать root=UUID=раздел-FAT32-UEFI чтобы он нашёл где лежит его initrd. и вот тебе вместо GRUB тупо ядро с набором всех утилит.

так ли нужен этот GRUB? ну знаешь, я его для чистоты картины использую, чтобы поней показывать. ))