LinuxMint.com.ru

darkfenix писал(а): ↑

09 янв 2018, 18:13

Это уже не актуально.

А когда это было актуально? Почему стало не актуальным? Мне кажется, что еще как актуально

vir0id писал(а): ↑

09 янв 2018, 18:40

А когда это было актуально?

Я не особо в теме, но хорошо помню что об этом подробно тут на форуме рассказывал slant

darkfenix писал(а): ↑

09 янв 2018, 18:55

тут на форуме рассказывал slant

Ну может быть. Я поищу. Я думаю, если своп тестно связан со сном и т.п, то не удивляюсь почему многие кричат "Почему же комп не просыпается после спячки", когда своп в конце. Но я ничего не буду утверждать, есть вероятность, что я могу быть и не прав
Ну возможно тогда речь шла о ssd дисках?

slant писал(а): ↑

08 янв 2018, 21:45

сть такая штука как subvolumes

Блин, а я разделы набомбил...

vir0id писал(а): ↑

09 янв 2018, 19:07

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

А я удивлюсь, если ты найдешь обьяснение подобной закономерности

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

ну просто речь о разном расположении секторов была про некокотурую разницу в скорости, и то не при каждом условии.
Как перенести mint xfce 18.2 на другой раздел жесткого диска (Пост slant #31049)
На отказ же он никак не должен работать, где б не находился)

При обычных условиях эксплуатации - порядок разделов совершенно не важен (есть мелкие нюансы, но практически не влияют). Если разбивка диска в GPT - порядок разделов не важен тем более. Единственные реально доказанные факторы по выбору места для раздела:
1. В начале диска скорость линейного чтения и записи выше чем в конце.
2. Средняя скорость поиска нужного блока (random access seek time) выше для блоков в середине диска. (т.к. расстояние которое нужно пройти головкам меньше, т.к. не будет движения из начала в конец или обратно ни при каких условиях) На современных дисках отличие настолько мало, что уже можно пренебречь. А раньше разница небольшая но заметная была.
3. В случае SSD - первые два пункта теряют силу.

vir0id писал(а): ↑

09 янв 2018, 08:00

За-то в надёжности проигрывают ext4. Да что уж там... даже ext3. У них могут возникать проблемы с бэкапами. Мол dd тебе уже не поможет

dd - и для zfs, например, не поможет. И что с того? Эти FS совсем по разному данные хранят. Для btrfs есть своя процедура переноса данных в случае тяжелого повреждения (btrfs restore - работает на отмонтированном разделе, не вмешивается в структуру, только читает).
Вот только надо иметь в виду, что все служебные структуры в btrfs дублируются. В случае повреждения одной копии - это еще не конец. А вот с ext3/4 - в таком случае можно потом поиметь множество фрагментарных файлов с потерянными именами. Это не говоря о том, что btrfs и пишет и читает данные с проверкой контрольных сумм. Т.е. если что-то идет не так - она это сразу понимает. Обратите внимание - она не умеет восстанавливать данные по контрольным суммам. Не нужно от нее этого требовать. Но она точно предупредит о повреждениях. Например - если на диске случайно изказилась пара байт в файле - картинке, звуке, видео (дефект магнитного слоя, скажем - потеря намагниченности) - на ext3/4 это может пройти незамеченным. На btrfs - нет.

Основные функции btrfs - уже довольно давно стабильны (еще до ядра 4.4, а у нас уже 4.10 в Сильвии). Не надо пока только с raid 5 и 6 на базе btrfs экспериментировать. В прочем - IMHO - с RAID 5 уже нигде не стоит. Была хорошая статья на эту тему. В кратце - статистически слишком большой шанс отказа еще одного изношенного диска за время пересборки массива.

di_mok писал(а): ↑

09 янв 2018, 19:23

Блин, а я разделы набомбил...

btrfs позволяет легко менять размер раздела прямо на лету (без отмонтирования). Т.е. все можно исправить, было бы желание.

slant писал(а): ↑

09 янв 2018, 20:09

было бы желание

И время Я пока пас, займусь позже.

slant, а нет ли у тебя путёвого рецептика по переезду на subvolumes. Что-то ни чего адекватного не нашёл А уже свербит

Готового детально нету. Но есть наметки:
1. У btrfs понятия subvolume и snapshot - по сути одно и тоже. Разница лишь в том, что при создании subvolume - он пуст, а snapshot - полная копия другого subvolume. Все снапшоты и подразделы абсолютно равноправны.
2. Даже если subvolume не создавались - один все равно будет. Это т.н. top level subvolume, он имеет ID 5 (и он же - defаult, если это не менялось явно). Все файлы тоже там. И т.к. все подразделы равноправны - с него тоже можно снять снапшот. Подраздел который default, принципиально отличается лишь тем, что именно он будет смонтирован (через mount) если явно не указать какой подраздел нужно монтировать. Так же, можно монтировать top level и подразделы на нем одновременно. Причем как / - один из подразделов, а top level например в /mnt/top.
3. gparted вполне справляется с манипуляциями на разделах btrfs. Менять размеры с его помощью вполне можно. К сожалению, с подтомами он не работает.

Отсюда вытекает стратегия по переезду корня на отдельный подраздел и объединению разделов в один:
1. Делаем снапшот top level subvolume, убеждаемся что снапшот получился. (На нем будет точное зеркало, кроме наличия собственного имени в файловой структуре. Т.е. рекурсии не будет.)
2. Меняем конфиг fstab в снапшоте, так чтобы в качестве "/" монтировался именно свежий снапшот. Так же меняем конфиг grub - добавляем еще одну запись, через которую ядро будет грузится тоже с нового снапшота и как "/" будет монтировать тоже его. Апдейт конфига grub'a и пересоздание initramfs. (Лучше всего именно добавлять еще одну запись - тогда нет риска потерять возможность загрузки.)
3. Проверяем загрузку. Если все заработало - трем на top level subvolume все, кроме снапшота.
4. Меняем размер раздела home - уменьшаем его настолько, чтобы можно было расширить / и содержимое /home туда влезло. Соответственно расширяем /.
5. Создаем subvolume под будущий /home, и через rsynk переливаем туда содержимое старого. Правим fstab. Убеждаемся что все монтируется.
6. Сносим второй раздел со старым хомяком, и расширяем на это место главный раздел.

Самый "затычный" момент - это сообразить, как сделать снапшот с top level subvolume, т.к. у него вроде как нету своего имени в дереве каталогов. На самом деле - имя есть. Это имя точки монтирования. А именно - "/" Т.е. если система стоит как бы без подразделов, снапшот нужно сделать так (@ - имя нового подраздела, такое имя дает инсталятор минта для подраздела будущего / ):
sudo btrfs subvolume snapshot / /@

slant писал(а): ↑

09 янв 2018, 20:09

Обратите внимание - она не умеет восстанавливать данные по контрольным суммам. Не нужно от нее этого требовать.

Понятно что те копии будут с одинаковым идентификатором. Просто для обычных пользоваталей это может оказаться проблемой. Т.к на просторах того-же самого гугла, куда не плюнь, а информацтю о копиях, бэкапах, чистилках найдёшь в момент. А тут придётся бегать по форумам и искать спеца по этим файловым системам. Достаточно спросить первого встречного, который перепрыгнул из окна, о том, какие ФС Linux он знает. Я уверен что будет первым в списке. И кстати, не с проста

vir0id писал(а): ↑

10 янв 2018, 08:12

Понятно что те копии будут с одинаковым идентификатором.

Простите, но вы совершенно не понимаете о чем речь. Какой идентификатор, копии и бекапы с "чистилками"? Речь здесь идет о базовом методе записи и чтения которым FS пользуются. btrfs проверяет с помощью CRC каждый блок который пишет или читает. Что позволяет убедится в том, что прочитано будет всегда именно то, что было записано. У ext3/4 такого механизма нет. Они полагаются только на то, что железо полностью исправно и не допускает искажений данных. Что увы - не всегда оправдывается на практике (один такой случай я описал как раз).
А что до известности - btrfs очень молода по сравнению даже с ext4 статус стабильной получила примерно год назад. До того был длительный период открытого теста, за время которого всякое случалось, что популярности не способствовало.
Вообще, пассажи вроде "а если спросить первого встречного..." - софистика.

Yuriy73n
Ты сам понял, что сказал. На / -15-20Гб(можно меньше), остальное под хомяка (home), можешь урвать, если есть место, под файлопомойку (файл систем не важно). Swap если 2 или 4 ГБ можно удвоить (или чуть больше, хуже не будет). Да если больше можешь не ставить.
Удачи.

slant
Ты тему читал или умничать.

svtv1 писал(а): ↑

11 янв 2018, 01:41

Yuriy73n
Ты сам понял, что сказал. На / -15-20Гб(можно меньше), остальное под хомяка (home), можешь урвать, если есть место, под файлопомойку (файл систем не важно). Swap если 2 или 4 ГБ можно удвоить (или чуть больше, хуже не будет). Да если больше можешь не ставить.
Удачи.

Под корень 15-20 гб? Ты реально в этом уверен? На окнах ты тоже 10 гигов под систему давал? Я был бы счастлив посмотреть на те ругательства, которые тебя ожидают в будущем в таком случае.

slant писал(а): ↑

11 янв 2018, 01:12

vir0id писал(а): ↑

10 янв 2018, 08:12

Понятно что те копии будут с одинаковым идентификатором.

Простите, но вы совершенно не понимаете о чем речь. Какой идентификатор, копии и бекапы с "чистилками"? Речь здесь идет о базовом методе записи и чтения которым FS пользуются. btrfs проверяет с помощью CRC каждый блок который пишет или читает. Что позволяет убедится в том, что прочитано будет всегда именно то, что было записано. У ext3/4 такого механизма нет. Они полагаются только на то, что железо полностью исправно и не допускает искажений данных. Что увы - не всегда оправдывается на практике (один такой случай я описал как раз).
А что до известности - btrfs очень молода по сравнению даже с ext4 статус стабильной получила примерно год назад. До того был длительный период открытого теста, за время которого всякое случалось, что популярности не способствовало.
Вообще, пассажи вроде "а если спросить первого встречного..." - софистика.

Речь не идет о копиях и бэкапах в принцепе. Вы упорно пытаетесь показать нам минусы, старых и проверенных годами ФС. За это вам спасибо. Но я говорю о том, что новечкам лучше не связываться с ней, до тех пор, пока она(ФС) им не изучена. И не доработана. Ну поставить скажем на заброшенный диск и кавырять пока не посинеешь. Но ставить на основную тачку... не вариант.

vir0id писал(а): ↑

11 янв 2018, 08:20

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

Вот кому хочется посмотреть как и что с btrfs организовано более менее с умом и работает из коробки и при установке ОС видно подтома - заюзайте опенсусю. Она для корня по умолчанию. Космонавт просто пиарит эту ФС вот и всё. Если сложить + и - , то в + останется только снапшот, который давно умеет xfs. Поэтому btrfs и находится в вялотекущем разрабатываемом состоянии. И она вообще не для десктопов придумывалась.
Кто убунту тестирует, вот они её из-за снапшотов и юзают.

Страсти наколились. Товарищи давайте вернемся к теме топика

При восьми гигах озу своп вообще можно исключить, тем более раздел для него, то есть, новые убунты уже отказались от раздела отдельного для своп....
Я делю так: 15 гиг рут и на этом всё...
Всё мне нужной храню в файлопомойке в формате нтфс размером в 500 гиг и мне этого всего достаточно.
П.С. При переустановки ос сношу и хомяк и мне так по кайфу....