LINUX.ORG.RU

Частое сохранение документа на SSD

 , срок службы


0

1

Есть у меня здоровенный документ .odt, я его потихоньку правлю, сохраняться желательно как можно чаще, во избежание потерь. Так вот вопрос: на SSD нажатие на кнопку «Сохранить» перезапишет файл поверх существующего и так каждый из 100500 раз или таки новая версия физически запишется куда-то в иное место, а старая версия будет просто помечена, как «к удалению при следующем проходе ТРИМ»? Как это работает?

В фс данные перезапишутся, а вот как там в микрухах будет знает только производитель.
Скорее всего в иное место.

Goury ★★★★★
()

Конечно в другое, хотя может не каждый раз. Иначе 10000 перезаписей файла — и блок убит.

crowbar
()

Нормально всё будет. Если меньше терабайтов в день пишешь на диск, беспокоиться не о чем.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

понимаешь...мозг мой интерпретирует «1Тб данных в день», как «Набор файлов РАЗНЫХ, которые запишутся равномерным слоем по моим 128Гб, перезаписав 8 раз старые данные». А тут у меня ступор, файл-то ОДИН и он ПЕРЕСОХРАНЯЕТСЯ, а не сохраняется под иным именем!

Kompilainenn ★★★★★
() автор топика
Ответ на: комментарий от Kompilainenn

Он сохраняется по одному логическому адресу, но отображение этого адреса на физический ssd может менять. Чтобы он знал где свободно — нужен trim.

crowbar
()

Что за DE? Впрочем не важно. Заведи плагин, который будет показывать использование оперативной памяти. Обязательно с индикацией дискового кэша.

Ну и да: вырубать питание с пинка не стоит. SSD у тебя или не SSD... В любом случае разбей документ на части и в конце собирай скриптом. Удобнее, если этот документ будет latex'овским

ziemin ★★
()
Ответ на: комментарий от ziemin

Что за DE? Впрочем не важно

да.

Заведи плагин, который будет показывать использование оперативной памяти. Обязательно с индикацией дискового кэша.

Зачем?! О_о

Ну и да: вырубать питание с пинка не стоит.

оно само бывает, что вырубается, а если ты считаешь, что все вокруг вырубают комп методом рывка общедомового рубильника во ВРУ, то я тебя разочарую, это не так

В любом случае разбей документ на части и в конце собирай скриптом

но от убиения части документа, уже набранной, но еще не сохраненной, это никак не спасает же!

Удобнее, если этот документ будет latex'овским

тебе удобнее, а мне нет, потому что исходник УЖЕ в .odt и в нем овер 400 страниц. я не собираюсь его в ЛаТеХ перегонять, искать там баги портирования, править, а потом опять в .odt перегонять и опять искать баги.

Kompilainenn ★★★★★
() автор топика

Для дебилов: срок службы SSD обратно пропорционален объёму свободного места.

Для автора: в идеале, да, каждый раз в ФС новый файл, старый удаляется и запускается TRIM на освободившееся место.

// b.

anonymous
()
Ответ на: комментарий от Kompilainenn

Зачем?! О_о

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

но от убиения части документа, уже набранной, но еще не сохраненной, это никак не спасает же!

Да ты, я вижу, перфекционист! Перезагружайся в венду и редактируй свой многогиппопотамовый документ в ворде (прости госпаде). Что может пойти не так?

ziemin ★★
()

Внутри SSD есть задроалгоритмы отображения «логических» секторов (которые видит ОС) на физические. Это называется wear leveling, и оно сделано как раз с этой целью. Так что не беспокойся по этому поводу (главное, TRIM настрой).

intelfx ★★★★★
()
Ответ на: комментарий от ziemin

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

Kompilainenn ★★★★★
() автор топика
Ответ на: комментарий от Kompilainenn

Как это работает?

Что тебе не понятно в работе дискового кеша и почему ты считаешь, что лучше потерять всё, чем часть?

ziemin ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.