Разметка дисков в Linux. Программы и рекомендации

Про максимальный размер файла в Ext3 наврали. Здорово работает с большими файлами. (4GB точно). Опять же гонят про ACL и Ext3 (или там на 2.6 они ещё не смотрели?).

2anonymous:

>Про максимальный размер файла в Ext3 наврали.

Да и про ext2 тоже - нет там ограничения на 2Г

Еще наврали про расширенные атрибуты и ext3 - в 2.6 они есть.

> partimage/partimaged
> Обе программы предназначены для создания точных образов разделов.
> Формально это можно сделать даже с помощью "штатных" средств ОС,
> например команды dd:
>
> dd if=/dev/hda1 | bzip > hda1.bz2
>
> Но у такого подхода есть несколько недостатков. Первый и главный --
> при этом архивируются не только реальные данные, но и "мусор",
> содержащийся в незанятых секторах. Соответственно на выполнение
> данной операции потребуется больше времени, и результирующий файл
> также будет больше.
tar -cljf hda1.tar.bz2 `mount | grep /dev/hda2 | cut -f 3 -d ' '`
не катит? Конечно, ФС должна быть смонтирована.

> Кроме того, при использовании Ext2/Ext3 необходимо самостоятельно
> позаботиться о разбиении образа на фрагменты допустимых размеров --
> скажем, так:
>
> dd if=/dev/hda1 | bzip | split --bytes=671088640
Unix-way явно е в почете

> Есть и другие неудобства, поэтому лучше использовать
> специализированные инструменты.
А лучше всего для каждой отдельной задачи иметь отдельную прогу с графическим интерфесом, причем этот GUI не должнен использовать ни один из распространенных toolkit'ов, а все отрисовывать сам

> Например, partimage "понимает" FAT16/FAT32, Ext2/Ext3, XFS,
> ReiserFS, JFS, HPFS (поддержка NTFS, UFS и HFS находится в состоянии > бета-тестирования) и благодаря этому сохраняет и восстанавливает
> только блоки данных.
Т.е. он сам реализует чтение ФС? А ядро зачем? Ладно понимаю, что утилиты обслуживающие ФС должны знать о ее устройстве - но для резервного копирования...

> Кроме того, программа может подключаться к удаленному серверу, где
> работает демон partimaged, для централизованного хранения и
> развертывания образов.
NFS, Samba и другие сетевые ФС уже видимо неактуальны

Обший вывод:
Далеко еще linux программам до pqmagic!

И кто-ж такой умный написАл про максимальные размеры файлов?
ext3 Reiser XFS JFS
BS | 4K 4K 4K 4K
Max
File System | 16TB 17,600GB 18,000PB 32PB
Max
File Size | 2TB 1,200GB 9,000PB 4PB

Что-то нас плохими статьями закидывает.

> Про максимальный размер файла в Ext3 наврали.

Видать, они с ограничением ядра (но не FS) 2.2 перепутали... :-)

А то что ReiserFS более критична к сбоям электроэнергии чем ext3 - это как true or false?

> Видать, они с ограничением ядра (но не FS) 2.2 перепутали... :-)

Точнее, даже не ядра, а драйвера ext2 в ядре.

2jackill: и поправили это не в 2.4.18, а еще в 2.3. То есть, 2.4 сразу с нормальным драйвером было.

> ASPDiskManager. Данная утилита умеет изменять размеры разделов FAT16/FAT32, Ext2/Ext3, ReiserFS, но не NTFS.

Мда, а я не знал, взял и подвинул и все получилось...

2Begemoth

> tar -cljf hda1.tar.bz2 `mount | grep /dev/hda2 | cut -f 3 -d ' '` > не катит?

Нет. Таймштампы собьются при распаковке. И сокеты будешь вручную восстанавливать. Еще есть грабли. Например, размер lost+found, хотя это уже и не актуально. Короче, tar для дампа корневой - плохой выбор.

> Конечно, ФС должна быть смонтирована.

Товаришч, меж прочим, предлагает способ спасения любой FS. Даже той, которую Linux в принципе монтировать не умеет :) Твой способ не такой универсальный. Тут уже ACLы вспоминали - tar их куда засунет? > > dd if=/dev/hda1 | bzip | split --bytes=671088640 Unix-way явно е в почете

Эту фразу надо понимать - "не в почете"? Ну и ну :) Замени dd на cat и что может быть проще и юниксвэистей? cat, спец-файл и три конвейера :) В виндах народ для этого будет нортон-утилиты ставить или что-нить в этом роде.

split нафиг не нужен, как и самбы с энэфэсами. Гнать все после бзипа ssh'елом на другой комп и всех делов-то. Для убирания мусора от удаленных файлов забить предварительно раздел cat'ом из /dev/zero в файл и стереть его тут же. Конечно ФС должна быть смонтирована :)

тогда уж и sync сказать не забыть. :-)

ASP рулит, как всегда... Сколько я в винде не пользовался PM, узнал только, что никакой не "мэджик", а дерьмо редкостное. А вот ASPDiskManager - по своим качествам выше и лучше всего мной увиденного. Молодцы они...

$$$ http://www.acronis.com/ - классные утилиты по бэкапу и разбиению дисков. Есть продукты под linux, а есть лив Сд на базе linux с которого можно многое что делать. Жалко что всё за $ :(

www.acronis.com linux версия работает без всяких сериал нумберов (из командной строки) качать отсюда http://download.acronis.com/trueimageserver8.0_s_en.tar.gz

>> tar -cljf hda1.tar.bz2 `mount | grep /dev/hda2 | cut -f 3 -d ' '` > не катит?

>Нет. Таймштампы собьются при распаковке. И сокеты будешь вручную >восстанавливать. Еще есть грабли. Например, размер lost+found, хотя это >уже и не актуально. Короче, tar для дампа корневой - плохой выбор.

Ну таймштампы не должны сбиться, а вот с нард-залинковыми и "дырявыми" файлами tar работает не корректно в отличие например от cpio.

"При необходимости работать с файлами размером более 2 GB можно создать отдельный раздел ReiserFS или XFS" странно... а я думал, что рейзер рулит на мелких файлах...

> Товаришч, меж прочим, предлагает способ спасения любой FS. Даже той, > которую Linux в принципе монтировать не умеет :) угу, значит прога должна сама реализовывать поддержку чтения всех нужных ФС, ну-ну...

> Твой способ не такой универсальный. Тут уже ACLы вспоминали - tar их > куда засунет? > > dd if=/dev/hda1 | bzip | split --bytes=671088640 > Unix-way явно е в почете > Эту фразу надо понимать - "не в почете"? Ну и ну :) Замени dd на cat и > что может быть проще и юниксвэистей? cat, спец-файл и три конвейера :) > В виндах народ для этого будет нортон-утилиты ставить или что-нить в > этом роде. А ты статью не читал? Сразу видно. Так вот там этот канал приводится в смысле - "вот как приходится извращаться". И утверждается что для каждой задачи нужно использовать специализированные программы (те же нортон утилиты). То же ты мог бы заметить если бы удосужился внимательно прочитать мой пост.

По поводу tar - написал то что превым пришло в голову - но смысл тот что эту задачу можно решить стандартными средствами.

Хочу принести свои извинения читателям как электронной, так и бумажной версии журнала. К сожалению я невольно ввёл Вас всех в заблуждение -- Ext2/Ext3 уже умеют работать с файлами размером более 2 Гбайт. В настоящий момент ограничение на работу с файлами такого размера могли остаться у некоторых прикладных программ. После того как в Ext2/Ext3 появилась поддержка файлов большого размера, оставалось изменить, как минимум, glibc + прикладной софт. _Официально_ эта проблема была решена в последних версиях glibc, до этого использовались специальные патчи. К сожалению выяснил я это уже в тот момент, когда статья ушла в набор. Увы. :-(

-- С уважением, Александр Куприн, автор

2Begemoth:

> Еще наврали про расширенные атрибуты и ext3 - в 2.6 они есть.

Но в 2.4 нет. А версия 2.6 ещё не настолько хороша, что её использовать, хотя Fedora Core и SuSE Linux активно пропихивают использование именно ядра 2.6, выбросив из дистрибутива 2.4

> > Кроме того, программа может подключаться к удаленному серверу, где
> > работает демон partimaged, для централизованного хранения и
> > развертывания образов.

> NFS, Samba и другие сетевые ФС уже видимо неактуальны

Ну, и что? Статья посвящена специализированному софту. Если кому-то проще использовать для хранения сетевую ФС, пожалуйста. Так можно, если задаться целью, ещё с десяток вариантов привести.

Ну, по поводу файлов > 2 Гб На РедХате 7.2 с ядром по умолчанию (2.4.7) большие файлы не создавались. Лечилось апгрейдом ядра. Так что, ребятки, видимо ни один из вас ранние 2.4 не пробовал

>>Про максимальный размер файла в Ext3 наврали. >Да и про ext2 тоже - нет там ограничения на 2Г

У меня на RH7.3 и ext3 при создании файла больше 2Гб он просто без предупреждения исчезает. нарывался на логах httpd и, самое неприятное, на mysqldump'е :-/

Берёшь два файла по полтора гига, склеиваешь их хоть через cp, хоть через cat - и опаньки. Результатирующий файл просто исчезает.

>Точнее, даже не ядра, а драйвера ext2 в ядре. >2jackill: и поправили это не в 2.4.18, а еще в 2.3. То есть, 2.4 сразу с нормальным драйвером было.

У меня ext3 и 2.4.20 - всё одно, больше 2Гб не поддерживается.

> Берёшь два файла по полтора гига, склеиваешь их хоть через cp, хоть через cat - и опаньки. Результатирующий файл просто исчезает.

Это он просто переходит на новый уровень бытия. Есть ли жизнь после /dev/null ?

> У меня ext3 и 2.4.20 - всё одно, больше 2Гб не поддерживается.

Сказали же, софт его не понимает. У меня на сервере ext2 и ядро 2.4.19 (но это RH 6.2) по NFS залил на него пару DVD под 4 гига каждый. На сервере увидеть и попользовать нельзя, а по NFS запросто. На рабочей станции стоит ASPLinux 7.2...

>Сказали же, софт его не понимает.

Я знаю, что ошибка в либах. Только мне от этого не легче, т.к. не работает _всё_, от cp до mysqldump и httpd :)

>Но в 2.4 нет. А версия 2.6 ещё не настолько хороша, что её использовать, хотя Fedora Core и SuSE Linux активно пропихивают использование именно ядра 2.6, выбросив из дистрибутива 2.4

На самом деле нет только в generic-ядрах. Если заглянуть, например, в поставку redhat, то мы увидим наши ACL'и.

P.S. Кто же пользуется generic? (только оголтелые молодые слакварщики)

>Ну, и что? Статья посвящена специализированному софту. Если кому-то проще использовать для хранения сетевую ФС, пожалуйста. Так можно, если задаться целью, ещё с десяток вариантов привести.

Тут скорее претензия к разведению лишних сущностей. Если что-то одно уже поднято, то незачем поднимать что-то еще - это ведет к увеличению вероятности появления уязвимости.

> (см. man mount, опция data=journal).
т.е строка в fstab
/dev/hdc2 / ext3 defaults 1 1
после модификации должна выглядеть так:
/dev/hdc2 / ext3 data=journal 1 1

> Тут скорее претензия к разведению лишних сущностей. Если что-то одно > уже поднято, то незачем поднимать что-то еще - это ведет к увеличению > вероятности появления уязвимости. А еще к тому, что программа если делает backup - то пусть она делает backup, передавать файлы по сети не ее задача.

Точно.

>> Товаришч, меж прочим, предлагает способ спасения любой FS. Даже той,

> > которую Linux в принципе монтировать не умеет :)

> угу, значит прога должна сама реализовывать поддержку чтения всех

> нужных ФС, ну-ну...

Ха! Зачем нужна поддержка ФС если речь идет о чтении/записи блочного устройства безотносительно его содержимого?

> А ты статью не читал? Сразу видно. Так вот там этот канал приводится в смысле - "вот как приходится извращаться".

Читал. По диагонали. Но сейчас глянул - про извращения ни слова. Действительно автор этот способ не рекомедует.

Но речь у нас зашла о спасении ФС, причем в продолжении темы статьи - ФС-м разного типа. Так вот, даже сто лет существующую ext2 практически невозможно спасти так, что бы при восстановлении получить полностью совпадающую копию с сохранением ВСЕХ атрибутов. Ни tar, ни cpio, ни даже специально для этого созданные dump/restore не помогут. Про последнюю парочку из опыта трехлетней давности, может сейчас и спасут отца русской демократии, но как они с ext3 отработают - вопрос...

А вот вариант cat /dev/[hs]d??? будет жить еще ооочень долго. Абсолютная копия всего что хошь, исключая badblocks. :)

> Так что, ребятки, видимо ни один из вас ранние 2.4 не пробовал

Ченджлоги почитай, что ли... :-) А что там у RH было - то им ведомо... Хотя, оно в прошлом, хоть так, хоть эдак...

> Берёшь два файла по полтора гига, склеиваешь их хоть через cp, хоть
> через cat - и опаньки. Результатирующий файл просто исчезает.

Ты их не в mc ли смотреть пытаешься ? Что ls говорит ?

> А вот вариант cat /dev/[hs]d??? будет жить еще ооочень долго. > Абсолютная копия всего что хошь, исключая badblocks. :) hidden вот еще что ты не заметил - автора этот вариант не устраивает, потому что размер дампа будет равен размеру раздела диска, а он хочет, чтобы блоки не занятые файлами были пропущены - поэтому проге надо знать как устроена ФС. Именно поэтому я предложил вариант с tar.

> чтобы блоки не занятые файлами были пропущены - поэтому проге надо > знать как устроена ФС. Именно поэтому я предложил вариант с tar.

И что это дает ? Ты получишь копию данных с файловой системы, но не копию самой фс: после восстановления файлы будут лежать не по тем местам. В большинстве случаев это по барабану, но если копия-таки нужна и именно самой фс, так tar использовать нельзя. А вот что-нибудь вроде cat /dev/... | tar ... вполне можно и попробовать.

> Обший вывод: > Далеко еще linux программам до pqmagic! acronis partition export (disk suite), есть бут диск с линукс ядром. единственное чего я не понимаю, почему ребята из акронис не сделали нормальную версию для линукс, хотя шаги к этому уже есть - тру имэйдж сервер.

именно

>Обший вывод: Далеко еще linux программам до pqmagic!

Вывод: ты - осел! (прошу прощения) А pqmagic до YAST-a "как до Шанхая босиком"