Linux на SSD.

Для новичков как вообще в Linux, так и в конкретной теме, к которой относится вопрос.

Модератор: Bizdelnick

Аватара пользователя
RusWolf
Сообщения: 604
ОС: Arch Linux x64 на BTRFS

Re: Linux на SSD.

Сообщение RusWolf »

LMAoD писал(а):
13.06.2017 10:58
Какие преимущества получает обычный пользователь используя gpt?

Для меня как обычного пользователя, то что каждый раздел имеет свой уникальный UUID и при использование разных дистрибутивов на одном винте или нескольких, использую один раздел swap.
И не важно как после чистки компа, в какой последовательности я подключу винты, в конфиге grub и fstab монтирование прописано по UUID.
Так же плюсом что могу сделать 128 основных разделов, а не гемороится с раширенным разделом и логическими дисками.
Спасибо сказали:
Аватара пользователя
Bizdelnick
Модератор
Сообщения: 20752
Статус: nulla salus bello
ОС: Debian GNU/Linux

Re: Linux на SSD.

Сообщение Bizdelnick »

alv писал(а):
13.06.2017 15:24
Bizdelnick писал(а):
05.06.2017 16:41
прислушаться к совету в самом начале этой страницы.

Вообще-то весь тамошний совет сводится к добавлению опции discard при монтировании ext4...

Где это? Я писал об этом:
Начиная с Ubuntu 14.04 разработчики позаботились о поддержке SSD. Система сама периодически запускает функцию TRIM на SSD, никаких discard в fstab больше не требуется. И многие другие советы, которые можно найти в интернете уже не актуальны, не создавайте себе проблем, просто пользуйтесь.
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:
NickLion
Сообщения: 3408
Статус: аватар-невидимка
ОС: openSUSE Tumbleweed x86_64

Re: Linux на SSD.

Сообщение NickLion »

alv
Наверное оттуда, что на адресацию выделено 32 бита, и при размере сектора в 512 байт возможности адресовать раздел более 2ТиБ нет. Вроде как-то обошли по крайней мере на уровне ОС, а на уровне BIOS ограничение осталось и поэтому загрузиться нельзя. Правда я так и не понял, можно ли создать раздел за пределами 2ТиБ и более 2ТиБ.
Спасибо сказали:
NickLion
Сообщения: 3408
Статус: аватар-невидимка
ОС: openSUSE Tumbleweed x86_64

Re: Linux на SSD.

Сообщение NickLion »

alv писал(а):
13.06.2017 15:24
PS Много Вы знаете альтернативно чудаковатых, размечающих 10 ТБ HDD как единый системный раздел? Разве что ему действительно кроме 10ТБ панрухи, ничего не нужно...

Кстати, более чем ожидаемое событие. Например, мне нужна фалопомойка, зачем я буду её делить? Одним разделом все 10ТиБ.
Спасибо сказали:
Аватара пользователя
alv
Бывший модератор
Сообщения: 7274
Статус: Пенсионер в законе
ОС: Cintu
Контактная информация:

Re: Linux на SSD.

Сообщение alv »

RusWolf писал(а):
13.06.2017 15:33
каждый раздел имеет свой уникальный UUID и при использование разных дистрибутивов на одном винте или нескольких

Уникальный UUID генерится для любого диска (raw-устройства) и любого его раздела, при любой схеме разметке - хоть dos, хоть gpt, хоть bsd-label.
RusWolf писал(а):
13.06.2017 15:33
использую один раздел swap.

Одни swap (в те далёкие времена, когда он был нужен) можно было использовать хоть в любом Linux'е, хоть в любой BSD, и даже в одном-единственном Solaris'е.
О Gpt-разметке в те времена и слыхом не слыхивали (не говоря уж о видом видывать).
RusWolf писал(а):
13.06.2017 15:33
после чистки компа, в какой последовательности я подключу винты, в конфиге grub и fstab монтирование прописано по UUID.

Если для Вас это так важно... А я допускаю, что важно: чистка компа неизбежно сопряжена с протиркой контактов, а если их протирать как следует - можно действительно забыть порядок подключения винтов.
Так вот, в этом случае лучше всего монтировать носители by-id - это действительно однозначная их идентификация. Ну или почти однозначная: вероятность того, что идентификаторы двух дисков совпадут, не равна нулю. За время, сопоставимое с возрастом Метагалактики.
pS смайлики по количеству дисков.
Спасибо сказали:
Аватара пользователя
alv
Бывший модератор
Сообщения: 7274
Статус: Пенсионер в законе
ОС: Cintu
Контактная информация:

Re: Linux на SSD.

Сообщение alv »

Bizdelnick писал(а):
13.06.2017 15:36
Я писал об этом:

Да, прошу пардону, запамятовал: вспомнил те времена, когда как величайшее достижение Ubuntu преподносилось автоматическое дописывание discard'а.
И кстати, все современные контроллеры, насколько я знаю, операцию TRIM'ирования выполняют сами. Кроме тех немногих, которые этого не делают. И у них это специально оговорено в ТТД, и преподносится, как очень полезная (в некоторых условиях) опция, за которую берут дополнительные дэнгы. Правда, в каких условиях - даже не смотрел: подозреваю, в тех, которых у меня до конца жизни не сложится.
Спасибо сказали:
Аватара пользователя
Bizdelnick
Модератор
Сообщения: 20752
Статус: nulla salus bello
ОС: Debian GNU/Linux

Re: Linux на SSD.

Сообщение Bizdelnick »

RusWolf писал(а):
13.06.2017 15:33
LMAoD писал(а):
13.06.2017 10:58
Какие преимущества получает обычный пользователь используя gpt?

Для меня как обычного пользователя, то что каждый раздел имеет свой уникальный UUID и при использование разных дистрибутивов на одном винте или нескольких, использую один раздел swap.
И не важно как после чистки компа, в какой последовательности я подключу винты, в конфиге grub и fstab монтирование прописано по UUID.
Так же плюсом что могу сделать 128 основных разделов, а не гемороится с раширенным разделом и логическими дисками.

UUID относится не к разделу, а к файловой системе на нём, так что монтирование по UUID отлично работает и с msdos-разметкой.

alv писал(а):
13.06.2017 15:24
Много Вы знаете альтернативно чудаковатых, размечающих 10 ТБ HDD как единый системный раздел?

Если, например, использовать его как LVM PV, это более чем логично.
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:
Аватара пользователя
alv
Бывший модератор
Сообщения: 7274
Статус: Пенсионер в законе
ОС: Cintu
Контактная информация:

Re: Linux на SSD.

Сообщение alv »

NickLion писал(а):
13.06.2017 15:54
на адресацию выделено 32 бита, и при размере сектора в 512 байт возможности адресовать раздел более 2ТиБ нет

А Вы помните время, когда ядро Linux'а нельзя было загрузить в сектора дальше 1023?
Это - ограничение из той же оперы.
NickLion писал(а):
13.06.2017 16:01
мне нужна фалопомойка, зачем я буду её делить? Одним разделом все 10ТиБ.

А я про что? Свою первую парнушицу я купил на 3 ТБ - в те времена, когда вопрос 2 ТБ обсуждался очень активно. Разбил одним разделом в ext4.
Но грузить же автоматом парнуху через BIOS я не собирался. Как, полагаю, и Вы...
Спасибо сказали:
Аватара пользователя
alv
Бывший модератор
Сообщения: 7274
Статус: Пенсионер в законе
ОС: Cintu
Контактная информация:

Re: Linux на SSD.

Сообщение alv »

Bizdelnick писал(а):
13.06.2017 16:17
UUID относится не к разделу, а к файловой системе на нём

Разумеется.
Bizdelnick писал(а):
13.06.2017 16:17
монтирование по UUID отлично работает и с msdos-разметкой.

Более того, работало с первых версий Ubuntu.
Ну уж Вы-то должны помнить: монтирование по UUID возникло именно в них, когда использовался Debian Installer, который в убунтовской версии некооректно определял имена дисков 1-го уровня
Багу превратили в фичу, фича стала легендой. Ну а потом и анекдотов напридумывали.
Bizdelnick писал(а):
13.06.2017 16:17
например, использовать его как LVM PV, это более чем логично.

Поскольку LVM, вопреки своему названию, к логике никакого отношения не имеет - нет.
Если лихие галисийские герильясы забьют на все совместимости лицензий и явочным порядком учредят ZFS-хунту - LVM должен будет умереть.
Я, конечно, уже не доживу до того светлого времени, но очень надеюсь, что оно наступит:
No pasaran!
Спасибо сказали:
NickLion
Сообщения: 3408
Статус: аватар-невидимка
ОС: openSUSE Tumbleweed x86_64

Re: Linux на SSD.

Сообщение NickLion »

alv писал(а):
13.06.2017 16:30
Поскольку LVM, вопреки своему названию, к логике никакого отношения не имеет - нет.
Если лихие галисийские герильясы забьют на все совместимости лицензий и явочным порядком учредят ZFS-хунту - LVM должен будет умереть.

Там ещё и btrfs со своими sub-volume пытается LVM убить. Правда я как-то динамику такую не люблю, ни LVM, ни btrfs.
Спасибо сказали:
Аватара пользователя
Bizdelnick
Модератор
Сообщения: 20752
Статус: nulla salus bello
ОС: Debian GNU/Linux

Re: Linux на SSD.

Сообщение Bizdelnick »

alv писал(а):
13.06.2017 16:30
Ну уж Вы-то должны помнить: монтирование по UUID возникло именно в них, когда использовался Debian Installer, который в убунтовской версии некооректно определял имена дисков 1-го уровня

Вы немного переоцениваете мой стаж.

NickLion писал(а):
13.06.2017 16:37
я как-то динамику такую не люблю, ни LVM, ни btrfs.

Оно имеет смысл на машинах с до фига дисков. Причём не только на серверах: на десктопе тоже удобно бывает расширить забитый хомяк за счёт нового диска. Хотя риск потери данных из-за сбоя диска растёт пропорционально числу дисков...
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:
NickLion
Сообщения: 3408
Статус: аватар-невидимка
ОС: openSUSE Tumbleweed x86_64

Re: Linux на SSD.

Сообщение NickLion »

Bizdelnick писал(а):
13.06.2017 16:42
NickLion писал(а):
13.06.2017 16:37
я как-то динамику такую не люблю, ни LVM, ни btrfs.

Оно имеет смысл на машинах с до фига дисков. Причём не только на серверах: на десктопе тоже удобно бывает расширить забитый хомяк за счёт нового диска. Хотя риск потери данных из-за сбоя диска растёт пропорционально числу дисков...

Да, я понимаю, что имеет смысл, но вся возникающая неопределённость меня пугает :) мне проще сделать home на SSD и отдельно примаунтить HDD и расставить симлинки "где надо". Костыль, но по крайней мере работает предсказуемо. Плюс насколько я помню у LVM есть проблема уменьшения размеров томов и добавляется фрагментация томов.
Спасибо сказали:
Аватара пользователя
Bizdelnick
Модератор
Сообщения: 20752
Статус: nulla salus bello
ОС: Debian GNU/Linux

Re: Linux на SSD.

Сообщение Bizdelnick »

NickLion писал(а):
13.06.2017 16:59
насколько я помню у LVM есть проблема уменьшения размеров томов

У LVM такой проблемы нет, она может быть у файловых систем, работающих поверх LVM.

NickLion писал(а):
13.06.2017 16:59
добавляется фрагментация томов

При размере экстента несколько МиБ (вроде бы 4 по умолчанию) на производительности это не сказывается. И чтобы добиться высокой фрагментации надо часто менять размеры разделов в обе стороны, что бывает крайне редко.
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:
Аватара пользователя
LMAoD
Сообщения: 182
ОС: Gentoo ~amd64

Re: Linux на SSD.

Сообщение LMAoD »

alv писал(а):
13.06.2017 15:24
NickLion писал(а):
13.06.2017 11:44
для обычного пользователя самое заметное отличие — поддержка дисков более 2ТБ

Ну откуда эта легенда? dos label не позволяет загрузить ядро с раздела, лежащего за пределами 2 ТБ. А вот работать с 3 ТБ диском, размеченным как единый dos-раздел, можно прекрасно. Да, при размере сектора в 512. Проверено неоднократно.
PS Много Вы знаете альтернативно чудаковатых, размечающих 10 ТБ HDD как единый системный раздел? Разве что ему действительно кроме 10ТБ панрухи, ничего не нужно...
Когда-то давно необходимо было написать свой обработчик mbr, и если я ни чего не путаю, при описании раздела используется структура с полями

Код: Выделить всё

08h     4     Смещение первого сектора раздела
0Ch     4     Количество секторов раздела
Каждый по 4 байта. И если смещение еще может быть относительно начала расширенного раздела у вложенных записей mbr(если не ошибаюсь), то количество секторов раздела ограничено 2^32, другими словами при размере сектора 512байт при использовании mbr создать раздел более 2Tb не получится. С другой стороны я уже давно не видел больших hdd с размером сектора 512байт, и как сказал NickLion, с размером сектора 4Kb ограничение на раздел становится в 16Tb. Поэтому не понимаю о каком мифе идет речь и как возможно обойти эти ограничения?
PS: не отрицаю, упереться в 16Tb на раздел в домашних условиях выглядит странно.
Спасибо сказали:
NickLion
Сообщения: 3408
Статус: аватар-невидимка
ОС: openSUSE Tumbleweed x86_64

Re: Linux на SSD.

Сообщение NickLion »

LMAoD
Вроде, если гугл-скилл меня не подводит, расширили то поле старыми уже по факту не использованными 2 байтами из CHS области, расширив таким образом до 48 бит. Нестандартно, костыльно, но вроде как-то так работает.
Спасибо сказали:
Аватара пользователя
LMAoD
Сообщения: 182
ОС: Gentoo ~amd64

Re: Linux на SSD.

Сообщение LMAoD »

NickLion писал(а):
13.06.2017 17:50
LMAoD
Вроде, если гугл-скилл меня не подводит, расширили то поле старыми уже по факту не использованными 2 байтами из CHS области, расширив таким образом до 48 бит. Нестандартно, костыльно, но вроде как-то так работает.
Странно все это... Хотелось бы взглянуть(мой гугл-скилл меня подводит), а так же узнать начиная с каких версий Windows и ядро Linux поддерживают данный метод
Спасибо сказали:
Аватара пользователя
alv
Бывший модератор
Сообщения: 7274
Статус: Пенсионер в законе
ОС: Cintu
Контактная информация:

Re: Linux на SSD.

Сообщение alv »

NickLion писал(а):
13.06.2017 16:37
я как-то динамику такую не люблю, ни LVM, ни btrfs.

Это совершенно разные вещи. LVM, как следует из названия - система управления томами. Btrfs - система управления томами вместе с файловой системой.
Как ZFS. С той разницей, что ZFS сделано нормально, а btrfs - через то самое устройство, которое пониже спины.
Попробуйте поэкспериментировать с ZFS хотя бы на флешках, для примера - после этого Вам на всё прочее рукоблудие и смотреть не захочется.

NickLion писал(а):
13.06.2017 17:50
Нестандартно, костыльно, но вроде как-то так работает.

Впервые нестандартно и костыльно это расширили 20 лет назад - убрав ограничение на загрузку ядра с сектора дальше 1023-го. Работает - вот уже 20 лет. И не как-то, а бессбойно.
Спасибо сказали:
Аватара пользователя
alv
Бывший модератор
Сообщения: 7274
Статус: Пенсионер в законе
ОС: Cintu
Контактная информация:

Re: Linux на SSD.

Сообщение alv »

LMAoD писал(а):
13.06.2017 18:01
а так же узнать начиная с каких версий Windows и ядро Linux поддерживают данный метод

А разве тут про Windows я говорил хоть слово? Ко времени первого из этих методов я уже и название такое забыл. Мож он, выньдя ваша, и не грузится при этом...
И кстати, если на самом деле интересно - почитайте FreeBSD Handbook 20-летней давности. Тогда это было лучшее руководство по ОС Linux, такие вещи тогда были актуальны, и описывались очень подробно - именно в милых вам (не Вам лично) терминах блоков, секторов etc. Я с тех пор всё это забыл как страшный сон.
Спасибо сказали:
Аватара пользователя
RusWolf
Сообщения: 604
ОС: Arch Linux x64 на BTRFS

Re: Linux на SSD.

Сообщение RusWolf »

Bizdelnick писал(а):
13.06.2017 16:17
UUID относится не к разделу, а к файловой системе на нём, так что монтирование по UUID отлично работает и с msdos-разметкой.

Я говорил именно про UUID разделов, по научному PARTUUID.
Насколько я помню при работе с UUID файловой системы, при разметке dos, у многих наблюдались глюки, на компьютерах c BIOS без намека на UEFI.
alv писал(а):
13.06.2017 16:06
(в те далёкие времена, когда он был нужен)

Если он вам не нужен - это ваше личное дело.
Мне он нужен, для спящего режима.
alv писал(а):
13.06.2017 16:06
Одни swap (в те далёкие времена, когда он был нужен) можно было использовать хоть в любом Linux'е, хоть в любой BSD, и даже в одном-единственном Solaris'е.

Спасибо за увлекательный рассказ прописных истин, которые мне давно известны.
Пример был приведен, не о возможности использования одного раздела swap, а как пример, что раздел монтируется по PARTUUID и тогда не важно каким номером был подключён hdd, если их несколько.
Вы, со своим котом мануалом, немного увлеклись протиркой контактов.
Смайлики поставите на свой выбор.
Спасибо сказали:
Аватара пользователя
Bizdelnick
Модератор
Сообщения: 20752
Статус: nulla salus bello
ОС: Debian GNU/Linux

Re: Linux на SSD.

Сообщение Bizdelnick »

RusWolf писал(а):
13.06.2017 20:25
Насколько я помню при работе с UUID файловой системы, при разметке dos, у многих наблюдались глюки, на компьютерах c BIOS без намека на UEFI.

Вот сейчас пишу с компьютера с BIOS без намёка на UEFI, на котором уже 9 лет не наблюдаю глюков из-за монтирования по UUID. ЧЯДНТ?
Да собственно, поставьте любой дистрибутив из числа вышедших за последние 10 лет в любую виртуалку на выбор, только без LVM, и убедитесь, что по умолчанию будет создана msdos-разметка, а в fstab будут записи с UUID, и всё это будет прекрасно работать.
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:
Аватара пользователя
Bizdelnick
Модератор
Сообщения: 20752
Статус: nulla salus bello
ОС: Debian GNU/Linux

Re: Linux на SSD.

Сообщение Bizdelnick »

alv писал(а):
13.06.2017 18:08
Впервые нестандартно и костыльно это расширили 20 лет назад - убрав ограничение на загрузку ядра с сектора дальше 1023-го.

Ограничение было не в ядре, а из-за способа адресации блоков диска BIOS. Потом придумали LBA, но само собой, работала она только в новых BIOS'ах (да ещё и частенько по умолчанию была отключена).
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:
Аватара пользователя
alv
Бывший модератор
Сообщения: 7274
Статус: Пенсионер в законе
ОС: Cintu
Контактная информация:

Re: Linux на SSD.

Сообщение alv »

RusWolf
Повторяю, если Вам действительно нужно однозначное монтирование - монтируйте by-id.
Спасибо сказали:
Аватара пользователя
alv
Бывший модератор
Сообщения: 7274
Статус: Пенсионер в законе
ОС: Cintu
Контактная информация:

Re: Linux на SSD.

Сообщение alv »

Bizdelnick писал(а):
13.06.2017 22:18
9 лет не наблюдаю глюков из-за монтирования по UUID. ЧЯДНТ?

Наверняка что-то не так. Не старались...
Bizdelnick писал(а):
13.06.2017 22:18
поставьте любой дистрибутив из числа вышедших за последние 10 лет

А Вы не помните время, когда Fedora и openSUSE по умолчанию предлагали GPT?
Возникает вопрос, почему перестали?
Bizdelnick писал(а):
13.06.2017 22:29
Потом придумали LBA

Да, и этим новым биосам - лет уже тоже 20...
Спасибо сказали:
Аватара пользователя
RusWolf
Сообщения: 604
ОС: Arch Linux x64 на BTRFS

Re: Linux на SSD.

Сообщение RusWolf »

alv писал(а):
14.06.2017 00:53
Повторяю, если Вам действительно нужно однозначное монтирование - монтируйте by-id.

Спасибо за совет, но у меня прекрасно всё работает, однозначно монтируется по PARTUUID.

Спасибо сказали:
NickLion
Сообщения: 3408
Статус: аватар-невидимка
ОС: openSUSE Tumbleweed x86_64

Re: Linux на SSD.

Сообщение NickLion »

Я добавлю, что GPT добавляет не только PARTUUID, но PARTLABEL — метку, которая не зависит от ФС, а значит система может и не понимать некоторую ФС, но знать метку. Как по мне, что PARTUUID, что PARTLABEL — вещи хорошие. Да, и без них можно было такое делать, используя UUID или метки ФС, или by-id (что кстати не спасает в случае изменения разделов, номера поменяются, поэтому ИМХО, лучше всё же by-uuid или by-partuuid).
Спасибо сказали:
Аватара пользователя
Bizdelnick
Модератор
Сообщения: 20752
Статус: nulla salus bello
ОС: Debian GNU/Linux

Re: Linux на SSD.

Сообщение Bizdelnick »

alv писал(а):
14.06.2017 01:00
А Вы не помните время, когда Fedora и openSUSE по умолчанию предлагали GPT?

Нет, не помню. Сильно сомневаюсь, что это было так для машин без UEFI (а я не зря говорил о виртуалках — там как правило UEFI нет, если только не совершить определённые телодвижения).
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:
NickLion
Сообщения: 3408
Статус: аватар-невидимка
ОС: openSUSE Tumbleweed x86_64

Re: Linux на SSD.

Сообщение NickLion »

alv писал(а):
14.06.2017 01:00
А Вы не помните время, когда Fedora и openSUSE по умолчанию предлагали GPT?
Возникает вопрос, почему перестали?

Почему перестали? Всё также, GPT по умолчанию, если UEFI комп.
Спасибо сказали:
NickLion
Сообщения: 3408
Статус: аватар-невидимка
ОС: openSUSE Tumbleweed x86_64

Re: Linux на SSD.

Сообщение NickLion »

LMAoD писал(а):
13.06.2017 18:01
NickLion писал(а):
13.06.2017 17:50
LMAoD
Вроде, если гугл-скилл меня не подводит, расширили то поле старыми уже по факту не использованными 2 байтами из CHS области, расширив таким образом до 48 бит. Нестандартно, костыльно, но вроде как-то так работает.
Странно все это... Хотелось бы взглянуть(мой гугл-скилл меня подводит), а так же узнать начиная с каких версий Windows и ядро Linux поддерживают данный метод

Я ещё не уверен, нормальной инфо не нашёл, так обрывки, а код смотреть времени немного надо потратить. Насколько понял, Windows такое не поддреживает, в MSDN говорят или 2TiB (2.2TB) максимум или GPT. А поддержку в Linux надо в коде глянуть для достоверности.
Спасибо сказали:
Аватара пользователя
Novichok2016
Сообщения: 211
ОС: Xubuntu Core 16.04.3 x64

Re: Linux на SSD.

Сообщение Novichok2016 »

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

Переезжаю: Xubuntu ---> Debian = Переезд не удался
Спасибо сказали:
Аватара пользователя
alv
Бывший модератор
Сообщения: 7274
Статус: Пенсионер в законе
ОС: Cintu
Контактная информация:

Re: Linux на SSD.

Сообщение alv »

NickLion писал(а):
14.06.2017 12:11
что кстати не спасает в случае изменения разделов, номера поменяются, поэтому ИМХО, лучше всё же by-uuid или by-partuuid

В случае изменения разделов перегенерятся и uuid, и, насколько я помню, partuuid. Но в случае by-id для raw-устройства он останется неизменным, потому как прошит в железе. А номера разделов изменятся по понятной человечей логике.

RusWolf писал(а):
14.06.2017 07:38
Спасибо за совет

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