LINUX.ORG.RU

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

 , , , ,


1

3

Короче. Я до сих пор не установил ОС себе на десктоп, потому что не знаю как поступить, хочу сделать максимально хорошо, чтобы потом не хотеть всё переделать и созданной конфигурации хватило надолго. Итак, к делу: есть HDD на 1 ТБ и SSD на 120 ГБ. SSD тот самый, который у меня «полетел» ещё в конце февраля. Его я относил в сервисный центр по гарантии, там его проверили и проблем не обнаружили. SMART показывает большой износ, но его же длинный тест не выявляет наличия поломанных секторов. Возможно, «полетел» из-за того, что не был настроен TRIM. Так как сейчас видимых проблем нет, а гарантия действует ещё 4 года, решил ещё раз попробовать установить на него ОС, но на этот раз быть осторожнее, вот что я хочу: / на SSD, включая хомяк, на HDD есть раздел /mnt/data. Хочу чтобы не сильно тяжёлые данные (т. е. могущие уместиться на ~половине объёма SSD) хранились на SSD, но только в ro. Если их нужно изменить, то изменения записываются на HHD в виде diff или чего-то подобного. Внешне чтобы были обычные каталоги, но просто не изменённая часть читается с SSD, а изменённая — с HDD. Раз в неделю по cron старое содержимое всего того, что на SSD бекапится (куда-нибудь в tar.gz архив), удаляется прошлый бекап, и на SSD записываются новые версии всех файлов. Т.е. если c SSD что-то опять случится, я просто возьму бекап, применю к нему диффы, хранящиеся на HHD, запишу в корень и дальше продолжу пользоваться ПК, только не будет скорости, которую даёт SSD. А потом, если понадобится подключить другой SSD, я просто добавлю раздел на нём в список синхронинизированных разделов.
Внимание, знатокам: что из списка в тегах (или может не из него) больше подходит для такой «авантюры», как с помощью этого чего-то сделать то, что мне нужно, и как реализация, более приближенная к реальности, будет отличаться от моей задумки?

ЗЫ. Планируемая для установки OS — Gentoo. Примерно год назад уже была неудачная попытка её собрать, но на этот раз, надеюсь, осилю.

★★★★★

Последнее исправление: sudopacman (всего исправлений: 3)

хранились на SSD, но только в ro

зачем откладывать таким методом запись, если что-то записать всё равно придётся? Не проще ли на ссд оставить только boot, lib и usr, например. А остальное разместить на хдд. Var как раз чаще всего меняется.

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

Ну так записываться оно будет реже. И записываться будут финальные изменения, а не все подряд. Т.е. если я 10 раз за неделю изменил файл, то на SSD он запишется только 1 раз, а не все 10.

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

В том то и фишка, что либы и бинари в lib и usr изменяются только при обновлении. И далеко не все. К тому же 10 кратная запись текстового файл на ссд — микроскопическая величина, даже не смотря на поломку.

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

Не только при обновлении, а ещё при пересборке и удалении. Я хочу поставить генту, но боюсь мне много придётся пересобирать, поэтому всё время дёргать SSD не хочу. Хочу чтобы записывалась только финальная версия каждую неделю.

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

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

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

У вас там какая-то очень странная схема. Если SSD умирает именно по ресурсу записи, то он как правило даёт возможность считывать данные.

Вообще, btrfs может делать как обычные, так и readonly тома. Если хотите перекрыть запись на ssd, то можно сделать ro том, остальное монтировать в tmpfs. Да и на запись будет идти меньше данных, там сжатие на лету.

Deleted
()
Ответ на: комментарий от ionanahin

Да наверное. Там-то ванильная zfs.

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

В tmpfs всё не влезет. Я хочу использовать SSD для чтения, чтобы на нём хранилось побольше данных, а то как-то нелогично, что только 8 гигов от всей ёмкости используется.

Хотя tmpfs и zram тоже планирую прикрутить. Но это уже другая история.

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

то он как правило даёт возможность считывать данные.

Прошлый раз я не смог полностью забекапить арч, потому что была ошибка чтения. И cp, и tar с live-cd и системы с диска не копировали данные.

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

Тогда регулярно делать btrfs send | btrfs receive на HDD.

Deleted
()
Ответ на: комментарий от sudopacman

Ну, я тогда бы btrfs накатил. Даже boot можно не делать. Там два тома - корень и хомяк, монтировать их в соответствующие точки.

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

Это, как я понял, бекап так делается. Будут ли у меня сразу читаться новейшие версии файлов, при этом не будучи записанными на SSD. Тем более мне не нужно полное дублирование раздела SSD на HDD. Желательно обойтись только диффами.

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

Будут ли у меня сразу читаться новейшие версии файлов, при этом не будучи записанными на SSD

Хз что имеется в виду.

Deleted
()

Если боишься Btrfs - ставь LVM
Если тебе не нужны ни виртуалки, ни контейнеры, ни всякая дребедень, а только браузер-почта-кинцо - XFS в рут, Ext4 - /home

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

Хотя не, flashcache записывает данные на SSD сразу, а мне этого не надо.

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

Там у тебя невероятная простыня, бесплатно читать не буду. BTRFS, snapper раз в час, репликация снапшотов на HDD, раз в день/неделю инкрементальный бэкап на что-нибудь удаленное, гальванически развязанное и без btrfs. Жалеть SSD ничуть не надо.

t184256 ★★★★★
()
Последнее исправление: t184256 (всего исправлений: 2)
Ответ на: комментарий от Deleted

Хз что имеется в виду.

Имеется в виду: на SSD смонтирован / в ro. На HDD смонтирован /mnt/data. Когда нужно записать что-то в /, изменения пишутся в какой-нибудь каталог в /mnt/data или в ещё куда-нибудь, на специальный раздел, например (зависит от того, как можно сделать в той или иной FS). При этом раздел/каталог на HDD и раздел на SSD системой воспринимаются как единое целое, и при чтении, если изменений в файле не было, он читается с SSD, а если были — читается его новая версия с HDD.

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

Какая-то жесть, если честно. Вы представьте - в процессе загрузки системы проверять каждый каталог на дату изменения. Проще тогда уже на HDD установить систему и не париться.

Deleted
()

Гента, кстати, много пишет в корень, и ещё запись такая злобная для ssd - кучи мелких файлов в дереве portage, в оверлеях, в /usr/src

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

в процессе загрузки системы проверять каждый каталог на дату изменения

Можно и без этого обойтись. Напимер, создавая какое-то устройство, в на котором будут симлинки (ну или что-то подобное) на версии файлов либо с SSD, либо с HDD.
Вообще, моя задача состоит в том, чтобы найти максимально похожее на то, что я хочу решение. Не обязательно прям точь-в-точь.

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

Ну, сделайте /usr, /var, всякие кэши симлинками на HDD, остальное пусть на SSD. Но и работа с системой тормозиться будет соответственно.

Лично моё мнение - слишком заумно. Нет надобности в такой схеме.

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

Я просто хочу чтобы на SSD использовалось не 8 гигов из 120, а побольше, но при этом чтобы его не убить за месяц. А кеши я планирую разместить в ОЗУ.

sudopacman ★★★★★
() автор топика
Ответ на: комментарий от ya-betmen

Шустрее ни шустрее, а это всё-таки не совсем то, что мне нужно, хоть и похоже.

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

Тогда ответь на остальные вопросы:

как с помощью этого чего-то сделать то, что мне нужно, и как реализация, более приближенная к реальности, будет отличаться от моей задумки?

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

При этом раздел/каталог на HDD и раздел на SSD системой воспринимаются как единое целое, и при чтении, если изменений в файле не было, он читается с SSD, а если были — читается его новая версия с HDD.

Звучит как давно реализованная классика для LiveCD: UnionFS, а затем AuFS (Knoppix). Нужно только проверить, можно ли сделать flush (тот, что раз в неделю) не на отдельный том (как обычно), а именно поверх того, что только-на-чтение.

gag ★★★★★
()

lvm на все девайсы. Все партиции разместить на hdd.
ssd использовать как lvm cache в режиме writethrough.
Ошибки на ssd в теории не должны привести к потере данных. Только надо убедиться что dm cache работает именно в режиме writethrough через команду dmsetup status.

Nao ★★★★★
()

Фигнёй вы маетесь, батенька. Очевидно же, что сисему стоит поставить на SSD и не выёживаться. Хомяк можно туда-же, ибо система занимает обычно не более 50 Гб. Ну а терабайтник жестко примонтировать уже в /etc/fstab путём параметра «auto».

Насчёт ФС - это на твоё усмотрение. Я бы выбрал ext4, которая хоть и страдает избыточной записью, но после хоть данные восстановить можно. Никогда не понимал ребят, которые пытаются на чуть дышащих винтах сделать аналог Fat32, и никогда не делают резервные копии. А в случае пиздеца кричат, что всё нажитое непосильным трудом пропало.

У меня, можно сказать с детства, точнее со студенчества, резервные копии - наше всё. Каждую пятницу все данные с компов сбрасывались на кассету стриммера, кассета вынималась, подписывалась, и укладывалась в сейф, в комплект к десятку таких-же кассет. Так что потерять наработки было просто нереально.

Добавлю, что для терабайтника я бы выбрал ФС NTFS. Проще впоследствии будет, гарантирую.

cadaber ★★
()

zfs - серверное ПО

бтрфс - труп на все времена

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