Привет LOR. Объясните в чём отличие BIOS/U(EFI)? MBR,GPT,LVM? Куда физически устанавливаются разделы на диске? Swap -файл или раздел?

dar

MBR, GPT -

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

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

Да.

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

Нет. Это:

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

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

Можно и так сказать, количество старья с биосами с каждым днем сокращается.

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

Первый — скажем так, особый раздел для хранения временных данных, не поместившихся в ОЗУ.

Второй — каталог для кэшей и временных файлов, создаваемых программами в линуксе.

tar -t

O(n)

Хороший, кстати, показатель общего повышения грамотности в индустрии. Сейчас за O(n) тебе по рукам настучат, начиная с собеседования или с первого зачета по специальности. Но тогда, когда в голову людям пришло, что использовать потоковый архиватор в качестве архиватора общего назначения является отличной идеей, это было в норме. (Как и всякие проблемы с размерами данных после 2^31, кстати). То, что изменить ситуацию не спешат - это уже другое. Лень, «и так сойдет», а где-то и просто невежество. Озвучивать надо такие проблемы, тогда больше шансов, что у кого-то дойдут руки

хранить /tmp на диске только потому что какой-то говнокод пытается хранить там терабайты данных — это не очень.

Ну, пожалуй.

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

Возможно, я зря гнал на file-roller, он вроде в $XDG_CACHE_DIR мусорил. MC я собираюсь как-нибудь выкинуть, слишком кривая программа.

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

Вообще на SSD не ощущается :)

Тупить не надо ни в вендовзе, ни в лайнуксе. Подходы не просто другие, они гибкие.

ssh user@host tar czf - /path/to/data | indexed_archiver --import-from-tar-stream -f data.xxx никто не мешает сделать.

Tar вообще часто используется даже для локального копирования или перемещения файлов по определенному фильтру. Это не отменяет его неприменимости для архивов в файлах.

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

А что, в твоём дистре TMPDIR отменили? Я так 1C запускаю (TMPDIR=~/tmp 1cv8) для обновления, потому что линуксовый клиент как раз в темп срёт на гиги, а ещё и самому рамы надо вагон, а тачку на 64Гб мне давать пока не хотят.

Если так важно иметь быстрый список файлов, клади его рядом.

Да я ему много раз уже объяснял, что он пользуется таром не по назначению, а потом жалуется на двери, которые яйца щемят.

Как этот список поможет тару вытащить файл с конца архива без распаковки всего, что до него?

Важно иметь возможность быстро просмотреть содержание любого локально лежащего на диске с RA архива и вытащить оттуда данные без тупого оверхеда. Так то и сортировать можно пузырьком! Только это невежество и стыд

Да и когда у тебя нищеведро с 16 Гб памяти можно попасть в неприятную ситуацию,

У меня нищеведро с 8 гигами и /tmp в tmpfs

tmpfs /tmp tmpfs size=4G,noatime 0 0

Открываю архивы по 20-40 ГБ в Ark, /tmp ничем не переполняется.

P.S. Юзаю Openrc.

таром не по назначению

ты бредишь. Именно за использование тара по назначению я и топлю.

Индесксы можно там же положить, емнип решения для этого были.

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

Он просто не читал ман к tar'у

# tar --list -f etcportage.tar.xz
etc/portage/
etc/portage/savedconfig/
etc/portage/savedconfig/sys-apps/
etc/portage/savedconfig/sys-apps/busybox-1.29.2
etc/portage/savedconfig/sys-kernel/
etc/portage/savedconfig/sys-kernel/linux-firmware-20180825
etc/portage/repo.postsync.d/
etc/portage/repo.postsync.d/q-reinit
etc/portage/repo.postsync.d/example
etc/portage/package.accept_keywords/
etc/portage/package.accept_keywords/zz-autounmask
etc/portage/package.mask/
etc/portage/package.mask/webkit-gtk
etc/portage/package.mask/mesa
etc/portage/package.mask/gimp
etc/portage/package.mask/kde
etc/portage/package.mask/qtwebkit
etc/portage/package.use/
etc/portage/package.use/busybox
etc/portage/package.use/uses
etc/portage/repos.conf/
etc/portage/repos.conf/gentoo.conf
etc/portage/repos.conf/layman.conf
etc/portage/make.profile
etc/portage/package.unmask
etc/portage/env/
etc/portage/env/webkit-gtk.conf
etc/portage/package.env
etc/portage/envq/
etc/portage/make.conf

dar

Точно! Я ведь его в одном из вариантов своих бекапилок использовал. Короче, есть несколько вариантов архиваторов, можно поискать. Но, как уже говорилось, их непопулярность мешает использованию: отсутствет поддержка в файловых менеджерах; в статьях, советах и книгах их не приводят в пример для создания архивов, поэтому тары продолжают плодиться.

Были. Но начинать надо с того, что бы в книжках для чайников и в постах на форумах не советовать делать 'tar czf data.tar.gz'. Этот прием не общий, а для частного случая, который в современном мире все реже и реже требуется.

Но начинать надо с того, что бы в книжках для чайников и в постах на форумах не советовать делать 'tar czf data.tar.gz'. Этот прием не общий, а для частного случая, который в современном мире все реже и реже требуется.

Это потому, что их отпугнет «шайтан-окно», которое не только кушает, всё что ты вводишь, но и плюется? Ты точно клей нюхаешь.

У тебя уж очень сильно пригарает от отсутствия такой ненужной возможности. Где действительно нужен произвольный доступ к файлам ес-но используют другие архивы или ФС со сжатием.
А mc - это такой ФМ, который с задачами ФМ справляется хуже всего.

У меня пригорает от tar.gz на всяких хостах, созданных недалекими админчиками, размером под сотню гигов, с неизвестным размером данных внутри, с неизвестным содержимым.

А чо, давайте tar czf bkp123.tar.gz /var забубенем, как умные дядьки посоветовали в 1995 году.

Этот tar.gz, содержит непонятные данные, которые не помещатся на 300GB раздел при распаковке, список файлов в котором строится 6 часов, еще и побитый слегка... Это плод тупости 'tar czf' в мануалах.

тут про тебя кино сняли https://www.youtube.com/watch?v=TzaVd6zl2bA

с неизвестным размером данных внутри, с неизвестным содержимым.

unzip -l bkp123.tar.gz

Этот tar.gz, содержит непонятные данные

Не выдумывай.

O(n)

Да я не спорю, что O(n). Мы тут разговариваем про место на диске, а не про время.

Я исходил из предположения, что говнософт игнорирует $TMPDIR. Так-то всё ещё проще, конечно.

unzip -l bkp123.tar.gz

gunzip, конечно же

ну попробуй, потом расскажешь

Попробовал. О чем тебе рассказать?

# ls -sh g.tar.gz 
489M g.tar.gz
# time gunzip -l g.tar.gz 
         compressed        uncompressed  ratio uncompressed_name
          512227747          1911869440  73.2% g.tar

real    0m0,002s
user    0m0,002s
sys     0m0,000s
# time tar -tf g.tar.gz |wc -l
127225

real    0m12,131s
user    0m11,888s
sys     0m1,491s

Еще попытка. Тут же как: пока на шкуре в продакшене не прочувствуешь, не поймешь, насколько кривые бывают инструменты.

Clue: uncompressed = real_uncompressed mod 4294967296

(но это мы немного отклонились от темы tar. Gzip больше не трогаем, умываю руки. Просто жизненный опыт - с реальными архивами tar, размером в сотню гигабайт, работа затруднена на пустом месте. И вызывает удивление его повсеместная рекомендация. А уж в связке с gz - вообще какая-то дурь)

Clue: uncompressed = real_uncompressed mod 4294967296

О, я про этот баг забыл, думал давно починили. И вокэраунд, конечно, эпичный предлагался.

вокэраунд

:) да, он меня тоже порадовал тогда

И ведь не починить - формат такой. «Используется во всём мире». Печалька

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

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

Ваше нищеведро - так себе нищеведро. На моём нищеведре 1Гб памяти и 12Гб tmpfs в /tmp при 12Гб своп-разделе. При этом engrampa (форк file-roller) и mc каким то образом читают tar архивы не засирая /tmp и не вешая систему. И в /home они тоже не пишут - читают в какой то индекс. Да, и у меня скостылена система бэкапов на bash+tar+zbackup, так что периодически приходится гонять большие несжатые .tar

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

Тут. И где то в ответах под последей моей темой с разметкой диска.

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

Это и есть раздел для UEFI?

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

А, значит tmpfs вообще не занимает месста на диске, это просто строка в /etc/fstab?

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

LVM вроде бы удобнее чем табличные разделы изменять, или нет? Я уже ломал ОС из-за кривизны рук, поэтому мне нужен var.

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

Я понимаю. Но думаю что будет легче подготовитья к модернизации компьютера сейчас. А немного это сколько и это место оставить нерамеченным лучше?

Это и есть раздел для UEFI?

Скорее всего.

А, значит tmpfs вообще не занимает месста на диске, это просто строка в /etc/fstab?

tmpfs — это файловая система. А монтируется ли она из fstab, из .mount-юнита, автоматически ядром или руками командой mount — дело десятое.

LVM вроде бы удобнее чем табличные разделы изменять, или нет? Я уже ломал ОС из-за кривизны рук, поэтому мне нужен var.

А зачем их изменять? Я ещё понимаю дуалбут с виндой (нельзя заранее предсказать, сколько места на диске тебе потребуется в каждой из ОС), но для дуалбута с виндой LVM как раз ничем не поможет, потому что винда его не поддерживает.

Во всех остальных случаях зачем тебе вообще куда-то двигать разделами? Всякие служебные разделы (типа ESP и /boot) максимально предсказуемы, swap пихаешь в конец диска по размеру оперативной памяти или вообще в файл, остальное на один раздел (с подтомами по желанию). Зачем что-то дальше задрачивать?

Я уже ломал ОС из-за кривизны рук, поэтому мне нужен var.

Отдельный /var в такой ситуации не поможет.

Быстрее всего работает система, установленная на SSD. Всё остальное - хрень.

Вангую, что они распаковывают содержимое архивов рядом, в скрытый каталог.