Linux на SSD.

При перезаписи есть смысл перетасовать, чтобы лучше все было.

скорость просядет

есть ячейки, а какая и когда принадлежит первому - решать контроллеру

Еще раз. Вот твое:

какойто файл занимает не изношенные ячейки, при наличии изношенный, то он его переместит он старается износить равномерно

Теперь задача (с решением по твоей логике): пишем первый блок. Теперь пишем ВТОРОЙ. Первый изношен больше - переписываем его.

А теперь повторим операцию 100000 раз.

Вопрос: Что станет с первым блоком?

Писать только в ячейку с износом 1, пока она не станет 100, потом писать по очереди в обе.

Писать только в ячейку с износом 1, пока она не станет 100, потом писать по очереди в обе.

только вот в ячейке 1 данные лежат - их нужно переместить

Тебе нужно покупать SLC SSD, да дороже но количество перезаписи в 10 раз больше.

Теперь задача (с решением по твоей логике):

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

Так уже лучше.

Если у нас всего 2 ячейки и обе заняты? -_-
Ну окей, допустим, 1 занята, а 100 не занята, и нужно записать в одну ячейку. Что ты делаешь:
1. Читаем из 1 и пишем в 100
2. Пишем в 1
В итоге имеем 2 и 101.
Что я делаю:
1. Пишу в 100.
В итоге имеем 1 и 101. Кто из нас выиграл?

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

В итоге мы испортив в два раза больше ячеек. Здорово.

Или вот на примере трех ячеек:
1 100 12
1 занята. Ты хочешь:
1 -> 12
x -> 1
В итоге 2 100 13.
Я хочу:
x -> 12.
В итоге 1 100 13.

В итоге 2 100 13.
В итоге 1 100 13.

я понял, но и с другой стороны - пол диска 1,1,1..1,1,1, а вторая половина 100,100,100, ... 100
не трогать первую половину - значит всё больше изнашивать вторую

Ну да, смысл есть, если там 1-ки, то вероятно данные трогаются редко и есть смысл их перенести на изношенные.

Как бороться с «no space left on device», когда там полно места?

cat /dev/null > /btrfs/very/big/file

Btrfs не умеет корректно указывать, сколько свободного места у него осталось, без btrfs filesystem df.

Привет всем. У меня следующий вопрос: а долго ли Linux проживет на SSD?

Четвёртый год живёт на нетбуке.

я считаю что сама модель кэширования обращений к диску у Linux-а очень хороша, поэтому SSD вообще не имеет смысла, причем именно в Linux

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

ЗЫ в самом деле, что такая тема делает в development?

Сказал же, промахнулся.

Рамы у меня и так «8 гигов и более».

Монтируй часто изменяемые каталоги в tmpfs.

grep tmpfs /etc/fstab
tmpfs      /tmp           tmpfs           defaults,size=500M,mode=1777          0 0
tmpfs      /var/log      tmpfs           defaults,size=500M,mode=1777          0 0
tmpfs      /var/lock     tmpfs           defaults,size=500M,mode=1777          0 0
tmpfs      /var/tmp     tmpfs           defaults,size=6G,mode=1777               0 0
tmpfs      /var/run     tmpfs           defaults,size=500M,mode=1777           0 0

...поэтому SSD вообще не имеет смысла...

Имеет.

• Современные HDD - какашка по исполнению (посмотри темы про сдохшие диски).
• Время доступа = время поиска, а не +время позиционирования головки и считывания дороги для декодирования.

Лучше купить за те-же деньги SSD от приличного производителя.

и какого объема? если бы не объем и циклы записи, то HDD бы уже давно вылетели бы с рынка

Как бороться с «no space left on device», когда там полно места?

Никак. В Btrfs неподконтрольна внутренняя фрагментация из-за неудачного дизайна файловой системы, т.е. происходит лавинообразное порождение «мертвого» пространства. Её философия «не осталось места - купите еще один хард диск».

SSD вообще не имеет смысла, причем именно в Linux

Утешай себя.

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

Опыт использования Btrfs на разделе в 40 Гб показывает, что ты лгун.

Дак в том-то и дело, что место еще осталось, но оно его не видит.
И решение с /dev/null > file (может /dev/zero?) не катит, то есть сработает, если мне нужно перенести файлы, но что будет делать какой-нибудь хромиум, когда ему понадобиться записать?

krakatau

Опыт использования Btrfs на разделе в 40 Гб показывает, что ты лгун.

Изучение сорцов Btrfs и структуры его дерева показывает, что тебя оболванили.

Дак в том-то и дело, что место еще осталось

А как ты определяешь, что место ещё осталось? По утилитам Btrfs? :)

Меня оболванил мой собственный опыт? Ещё что фееричного ляпнешь?

Изучение сорцов Btrfs и структуры его дерева

Ты лично изучал сорсы и структуру дерева? Что именно тебя в них смутило?

Ты лично изучал сорсы и структуру дерева?

Представь себе, да.

Что именно тебя в них смутило?

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

Попросту, «дыры» в нодах неограниченного размера

Что за дыры?

А как ты определяешь, что место ещё осталось? По утилитам Btrfs? :)

Нет, по здравому смыслу. Я копирую файлы на пустой раздел, скажем в 2 гигабайта, и оно уже через 100-200 мегабайт, говорит, что места нет. Даже если журнал или что там за метаданные отъели дофига, не могли же они захавать 70% всего места.

ну когда разродятся SSDхами, которые не дохнут от перезаписи дольше чем даже HDD, то думаю многие сразу переползут на SSD, несмотря на цену может быть

Что за дыры?

Дыра - это свободное место в ноде B-дерева. Оно не должно быть больше половины ёмкости нода (кроме корневого).

Кстати, а нафига нужны ssd-диски с их ограниченным циклом? чтобы сидеть и трястить, ой я много записал? Это бред.

Поэтому на нетбуке я не отключал журнал, ничего не тюнил и не пихал портаж в tmpfs.

Если не работать с ними как с обычными hdd (дрочить на циклы) то они нафиг не нужны, имхо.

Даже если журнал или что там за метаданные отъели дофига, не могли же они захавать 70% всего места.

Я помню, где-то наглядно показывали, как пропадает место в Btrfs. Чтобы поправить тот баг, нужно полностью переписывать файловую систему.

Попробую предположить, что если размер блока ФС будет в точности совпадать с размером сектора SSD (512КБ), то никаких проблем не будет. Не будет лишних перезаписываний страниц и ускоренной деградации ячеек flash от этого эффекта.