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

~~~~

При установке первые созданные разделы

к центру

Быстрее(с маленькими файлами) будет работать раздел, что ближе к центру?

да

MBR, GPT - у них одно и тоже назначение. вторая современнее просто.

Обычный BIOS работает только с MBR?

не факт

GPT - только для UEFI?

не обязательно

LVM - это «программный» GPT?

нет, это линуксовое наколение

Если я его сейчас создам система будет работать? Может мне просто выделить для него место, но не создавать на нём раздел?

будет. можно.

Раздел boot

да, это простой раздел без всяких дополнительных атрибутов

~~~~

дальше лень отвечать

все эти вопросы решит-одтельный диск(фиический) для ОС

при обновлении до уефи просто обновишь разметку/бут раздел на диске с ОС(минутное дело) без риска для данных

а диск с данными одинаково будет работать на уефи и биосе

Гугл

там все ответы на твои вопросы есть.

там все ответы на твои вопросы есть.

Так я прямо из интернета, иначе откуда у меня столько вопросов? И вообще меня уже достали автобусы, ветрины, пешеходные переходы, знаки и светофоры.

Меня забанили

Гугл
там все ответы на твои вопросы есть.

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

Сходи на Wikipedia, там всё расписано.

Спроси там что такое MBR, GPT и LVM.

Раз уж тебе говорят про автоматические запросы.

Сходи на Wikipedia, там всё расписано.

Не понятно. Я на эти страницы ходил, там неболшое описание и какая-то техническая литература.

Сходи в Голубую Устрицу. Вас там ждут.

Сходи в Голубую Устрицу. Вас там ждут.

Я конечно люлю танцы, но я семейный человек.

Спалился красавчик. Но ничо и в семейниках примут.

красавчик.

Мама мне так же говорит.

rekcuFniarB: Чега, не думал в монастырь уйти?
chega93: думал, они очень привлекают. но я человек семейный.
rekcuFniarB: Шта? Ты женился и завёл детей?!
VoloS: наверное, имелось в виду, что живёт с мамой и бабушкой

Мой друг, писатель и актёр, отказался от смартфона в пользу кнопочной раскладушки. (комментарий)

Таблица разделов это и есть MBR или GPT?

Да. Ещё бывают другие.

Обычный BIOS работает только с MBR?

GPT - только для UEFI?

Это имеет значение только для загрузочного диска. В целом так, за исключением сетапа с hybrid MBR.

LVM - это «программный» GPT?

Нет.

С планами на обновление системы и появлением UEFI нужно будет создать раздел в 1GB для UEFI? Если я его сейчас создам система будет работать? Может мне просто выделить для него место, но не создавать на нём раздел?

Да, за исключением цифры в 1 GB (не понятно, откуда ты её взял).

Можно сделать что угодно. Однако, с появлением UEFI тебе в любом случае нужно будет преобразовать диск в GPT, для чего потребуется немного места с конца диска. Так что обе операции имеет смысл сделать за один раз.

Раздел boot никак не связан с этим, там хранятся загрузчик и ядра операционной системы?

Ну «как-то», конечно, связан. Но вообще зависит от твоего сетапа. С UEFI, например, нет смысла держать отдельный /boot, можно хранить ядро сразу на ESP вместе с загрузчиком.

Если я буду добавлять SSD в систему, то мне лучше объединить swap,/(root),/var,/tmp в LVM?

Это какая-то каша в твоей голове. Во-первых, SSD тут ни при чём. Во-вторых, /tmp рекомендуется держать в tmpfs, а не на диске. В-третьих, я не вижу смысла выделять /var в отдельный раздел. В-четвёртых, использовать LVM не «обязательно».

SWAP и tmp как разделы работают с такой же производительностью, как если бы они были файлами в том же /mnt/swap, /mnt/tmp или куда их ставят. Tmpfs - это только для tmp как файла?

Чем SWAP от tmp отличается?

Это тоже феерическая каша. swap — это раздел (или файл) подкачки, в который будут выгружаться неиспользуемые части оперативной памяти. tmpfs — это файловая система, которая хранит файлы в оперативной памяти (или потенциально в swap, если планировщик памяти решит их туда выгрузить). Всё.

Ставишь Ubuntu с автоматической разметкой и используешь компьютер по назначению. Всё.

https://www.gigabyte.com/Motherboard/B450M-DS3H-rev-10

Зачем такое говно, бери https://www.asus.com/Motherboards/ROG-STRIX-B450-I-GAMING/

Ты забыл спросить — нужно ли включать в BIOS AHCI?

Во-вторых, /tmp рекомендуется держать в tmpfs

Кем? В systemd по умолчанию юнит tmp.mount вроде не включён. Да и когда у тебя нищеведро с 16 Гб памяти можно попасть в неприятную ситуацию, «открыв» какой-нибудь большой tar-архив в файловом менеджере.

Это причина не использовать tar, а не не использовать tmpfs.

Кем?

Всеми.

В systemd по умолчанию юнит tmp.mount вроде не включён.

Это настолько рекомендуется, что захардкожено.

Да и когда у тебя нищеведро с 16 Гб памяти можно попасть в неприятную ситуацию, «открыв» какой-нибудь большой tar-архив в файловом менеджере.

А при чём здесь /tmp?

Пофиг ваще, это всё некритично.

Ну, кроме того, что на механических накопителях разделы находящиеся в начале работают быстрее.

Это настолько рекомендуется, что захардкожено.

Э-э-э, где? Допускаю, что у меня в дистрибутиве просто принято иначе. Потому что когда я отключил свой tmp.mount, /tmp перестал быть точкой монтирования.

А при чём здесь /tmp?

Когда «заходишь» в tar в MC или открываешь в file-roller, он полностью распаковывается в /tmp.

Я только за, предлагайте ваши альтернативы.

pixz, squashfs, 7z - как контейнеры для файловых архивов.

Я отдаю себе отчет, что это не всегда возможно, и даже неудобно, но отсутствие индекса в файловом архиве - это какой-то бред в 21 веке. Надо на это обращать всеобщее внимание. Может, когда-то у кого-то дойдут руки это исправить, сделав нормальный контейнер. Фича тара в его повсеместности и поддержки кучи аттрибутов со всевозможных ОС и ФС, конечно.

pixz

Нормально, но смущает экзотичность, хоть оно и обратно совместимо.

squashfs

Хорошо зашло для единичных архивов в десятки Гб, которые не предполагается трогать вообще никогда в идеале. Использовал бы для всего, но не хватает поддержки почти везде.

7z

Права, владельцы, ACL, xattrs.

отсутствие индекса в файловом архиве - это какой-то бред в 21 веке

Безусловно.

Э-э-э, где?

Мм, да, я ошибся — это не захардкожено, это просто дефолтный юнит.

Когда «заходишь» в tar в MC или открываешь в file-roller, он полностью распаковывается в /tmp.

0_o

А ещё можно яйца дверью прищемить и всем рассказывать, что дверь плохая.

Как сказали выше, это причина выкинуть mc и file-roller, а не причина не использовать tmpfs. Могу только поддержать.

sad but true

выкинуть mc и file-roller

tar же, ну

Я вынужден тебе сообщить, что твои варианты не очень. Если иных нет, то, пожалуй, меня всё ещё устраивает tar. Индексы можно прикрутить сбоку, но вот что уж не нужно в 99.9% случаев, так это индексы. Tar кстати не файловый архив, xz с gz тоже.

tar говно, не спорю. Но можно же хоть как-то оптимизировать! Первое что приходит в голову — построить в памяти карту расположения файлов в архиве, например. То есть распаковывать архив целиком, когда попросили показать список файлов — ну это же дебилизм чистой воды, не?

распаковывать архив целиком, когда попросили показать список файлов

А как ты тар по-другому посмотришь?

«открыв» какой-нибудь большой tar-архив в файловом менеджере

Зачем это делать? По старой досовской привычке хранить всё в zip-архивах и ходить по ним в командире Нортоне? Тогда это решается переделкой твоих тар-архивов в зиповские.

А зачем его смотреть?

зип говно, чего ты сюда его притащил

Почему бы тогде не сделать просто echo -n "" > your_data.tar.gz, раз смотреть, что внутри, не нужно

выкинуть mc

Сколько ни пробовал, пока не получается. Хоть и пользуюсь нечасто, там есть оптимальный для меня workflow. Стараюсь просто не открывать в нём архивы, потому что tar это лучшее из худшего в VFS MC - настоящий трэш это вызов unzip на *каждый* извлекаемый файл из архива.

На минуточку, ты отвечаешь в контексте того, что есть предложение «нужно выкинуть mc и file-roller», а я говорю, что причина не в них, а в формате tar.

Люди так не работают. У людей принято закрывать глаза на неудобные факты и наяривать на виртуальные сущности. Типо раз тар стандарт, значит делать в лоб на нём всё зашибись, а все проблемы у всех это от кривых рук.

Зачем это делать?

1) Вижу какой-то старый архив, надо глянуть, что там вообще.

2) Знаю, что в архиве, нужно достать один-два файла из десятков-сотен-тысяч.

«А почему бы не купить хлеба, раз уж вода мокрая?» Что за говно ты употребляешь, клей БФ?

Зачем, если можно >your_data.tar.gz? Ещё раз, это архиватор, но не файловый. Архивы, кстати, вполне себе seekable, так что дело не в тар, а в компрессорах, к которым можно прикрутить индексы.

Архивы, кстати, вполне себе seekable, так что дело не в тар, а в компрессорах, к которым можно прикрутить индексы.

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

Нет, что ты. Ты должен помнить содержимое всех архивов назубок и делать tar xf tarball.tar.gz path/to/file!

Ой, подожди, ведь что бы добраться до path/to/file, тару понадобится распаковать пол-архива (в среднем, ага).

/сарказм

(в сторону) Я понимаю, что понятие «сложность O(N)» ничего не говорит админам локалхоста. Но бородатые программеры должны же знать, что это стыдно!

но не файловый.

Зачем тогда его в каждой статье и книге предлагают использовать для этой цели?

Чтоб не как в вендовсе.

Удобно мешать с ssh например. Действительно, не как в вендовсе, подходы другие тут.

А какие ещё архивы поддерживают атрибуты, ацл и всё такое кстати?

Хотел бы я знать! Это одна из дырок *nix мира. Мой поинт в том, чтобы озвучить, что хранить файловые архивы в тар нельзя. Это отвратительно, стыдно, убого, медленно, умирают котята и щеночки. Когда-нибудь это изменится, после разработки адекватной тулзы.

Полной замены тар со сложностью O(1) вместо O(N) для файлов - не знаю. И именно это - маразм

squashfs вроде всё умеет. Поскольку дописывание архивов всё равно почти никому не нужно нынче, ему бы поддержку в том же file-roller, и было бы збс.

Так же, как это делает, например, tar -t.

Если что, под распаковкой архива я понимаю запись его содержимого на диск. Без этого, разумеется, можно обойтись.

Ну, сорян. Но это всё равно дебилизм, и хранить /tmp на диске только потому что какой-то говнокод пытается хранить там терабайты данных — это не очень. В худшем случае найди подкаталоги, в которые срут твои mc или file-roller, и сделай им bind из /var/tmp.

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

1) Вижу какой-то старый архив, надо глянуть, что там вообще.

Это не архив, это скиданные по досовской привычке всякие файлики в один архив. Архив требуется для создания архивной копии и единственное. когда он требуется, когда эти данные надо восстановить.

2) Знаю, что в архиве, нужно достать один-два файла из десятков-сотен-тысяч

Значит кто-то зачем-то создал архив, хотя требовался другой инструмент — например, снэпшот фс или git-хранилище.