Их да, на случай если я поступил не правильно, есть ли возможность переноса всей системы на новый раздел без тотальной переинсталяции?

Просто копируешь, поправляешь загрузчик и готово.

btrfs пока ещё сыровата и на домашнем компьютере скорее не нужна.

Просто копируешь

Не забудь опцию -p для сохранения прав и времени файлов.

сделай бэкап системы например вот так http://aboutubuntu.ru/backup-and-restore-ubuntu-by-tar-and-gz.html

а когда отформатируешь системный раздел в ext4 и развернёшь систему из бэкапа, не забудь в /etc/fstab указать etx4 в качестве файловой системы раздела, куда монтируется корневой каталог

Интересует рецепт приготовления правильной btrfs

Попробуй накатить свежее ядро (3.4.0), там скорость btrfs повышена. А вообще: я вот никаких оптимизаций не делал и всё прекрасно работает.

btrfs

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

То, что у вас все прекрасно работает так это же замечательно. Значит не все потеряно у меня с переходом на btrfs.

// [offtop] на аве Бальтазар из Зачарованных. Классный сериал, особенно
// нравилась Пейдж. [/oftop]

// [offtop]

ставлю на «Nip/Tuck»

И вместо того, чтобы как всегда установить на раздел ext4, выбрал в качестве файловой системы: btrfs.

«Нога, дурак, ружье, стрелять» (c)

это вы к тому

Что я зря поставил btrfs?

А вот вообще, что посоветуете поставить на 500Gb хард. Разделы автоматически создаются не делаю никакого выноса /home и /var.

Раньше вот использовал ext4...

Ах да, файлы хранятся различного объема, но обычно мегабайтов 5-10 самые большие. Ни видео, ни особо крупных файлов нет вообще.

А вот вообще, что посоветуете поставить на 500Gb хард. Разделы автоматически создаются не делаю никакого выноса /home и /var.

NTFS

NTFS

Фу, эту богомерзкую ФС ? Еретик!

А вот вообще, что посоветуете поставить на 500Gb хард. Разделы автоматически создаются не делаю никакого выноса /home и /var.

ext4 или reiserfs

А вот вообще, что посоветуете поставить на 500Gb хард.

RTFM. 512MB boot, остальное в LVM, / на 40GB, /var на столько же, /tmp на tmpfs, /var/tmp на 4GB, /home 100GB. Позже по ходу дела можно расширить любой из разделов (LVM, да!)

и нафига ему так бить диск на разделы на ДЕСКТОПЕ?

Позже по ходу дела можно расширить любой из разделов (LVM, да!)

Может человеку проще не заморачиваться и не следить за недостатком места в отдельных разделах, а? 21 век на дворе, а вы всё ещё пользуетесь «ручником» — ЗАЧЕМ?

Вот именно. Btrfs + subvolumes = никаких проблем с разметкой, гаданием сколько чему места выделить и т.д.

hammer fs

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

И после дюжины хороших бэд-блоков в правильных местах похоронить все данные. Зато да, «не нужно думать», «21 век». Поколение прогрессивных дебилов, мать вашу. Я уже с удовольствеим представляю, как через енекоторое время вы начнете заявлять что файловым системам ещё и fsck не нужен, потому что всё равно «операционку проще переставить за час, а потом с клоуда бэкап развернуть а кино и так из торрентов качается»

И после дюжины хороших бэд-блоков в правильных местах похоронить все данные

Нормальные люди делают бэкапы своих ценных данных. И да, ОС и фильмы к ценным данным не относятся.

Зато да, «не нужно думать», «21 век»

Да, именно так. Время задротства из-за мелочей и диалапного интернета ушли в прошлое.

включи lzo-сжатие (-o compress=lzo).
не знаю что там в ubuntu, но в моей генте с btrfs на корне приложения запускаются быстрей чем с reiserfs или ext4 (субъективно и на глаз, конечно)

zfs create syspool/rootfs/original
zfs create syspool/home
zfs create syspool/var-tmp
zfs create syspool/usr-local
zfs create syspool/var-cache
zfs create syspool/var-log
zfs create syspool/var-spool

:-P

И потом похоронить это всё сразу и вместе. Нормально, да.

Выронить разделы, в fstab noatime,compress=lzo.

Уже долго использую btrfs из ядра (сейчас 3.3.6) у 3.4 некоторые проблемы с драйверами (пока ещё) и никаких нареканий. Возможно собака зарыта в другом месте.

И после дюжины хороших бэд-блоков в правильных местах похоронить все данные.

Я думал, в Btrfs сделана как танк на избыточности критичных к жизнеспособности частей: метаданные не единожды дублируются, и в саму файловую систему заложены механизмы определения корректности метаданных и в случае повреждения — автоматического их восстановления без запроса со стороны пользователя, переноса данных со сбойных блоков в свободное пространство с обязательным сигналом пользователю, если ФС не может справиться с корректировкой. Неужели я ошибаюсь и всё так же лучше доверять древним Ext* в вопросах надёжного файлохранилища, которые если что-то и теряют, то молчком, и могут хотя бы что-то рассказать толко после очередного запука fsck в безопасном режиме?

Я уже с удовольствеим представляю, как через енекоторое время вы начнете заявлять что файловым системам ещё и fsck не нужен

И, правда, зачем нужен fsck, если есть нормальный рабочий процесс записи на CoW-ФС, не нуждающийся в дополнительных проверках логической целостности пространства метаданных и данных? Если нужен scrub'инг, то для этого должны быть веские на то причины: ожидание повреждение данных из-за долгого к ним необращения и/или возможной/естественной деградации среды хранения. Сами по себе байтики на винчестерах не перемешиваются или вы другого мнения? ;) Или у вас своё мнение на этот счёт? А, знаю: ошибки в работающем коде самой файловой системы. Тогда так и говорите: «Btrfs ещё нуждается в тестировании».

И, правда, зачем нужен fsck, если есть нормальный рабочий процесс записи на CoW-ФС

Ты слышал такое слово как «бэд-блок»? Ну так вот - он возникает ВНЕЗАПНО. В самом произвольном месте. И похереивает и КОВ, и херов, и фребздов.

P.S.: штатный алгоритм контрольной суммы в ZFS элементарно фейлится на двухбитовых ошибках.

Ты слышал такое слово как «бэд-блок»? Ну так вот - он возникает ВНЕЗАПНО. В самом произвольном месте. И похереивает и КОВ, и херов, и фребздов.

И чем тебе поможет Ext* на LVM точно в таком же случае?

Вопрос без ответа. :))

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

У Ext* нужно сначала запустить fcsk в безопасном режиме, подождать, пока он отработает (так как ФС в это время недоступна на запись), сложит все похеренные найденные данные в каталог /.lost+found под ничего незначащими именами и только после его работы можно будет наконец посмотреть, что за кашу он «сварил» (свалил) в каталоге восстановления. :))

штатный алгоритм контрольной суммы в ZFS элементарно фейлится на двухбитовых ошибках.

Не видел такого. Если сказал «А», то говори и «Б» — пруфлинк или трепло.

Поищи. На LOR'е В одном из тредов про ZFS я приводил пример - не ссылку, а именно пример - исходный байт, какие биты изменяются и то что контрольная сумма не меняется.

используй сжатие. По ощущениям быстрее чем ext4.

Так мне ещё и искать надо? Смешной ты. :)

А нахрена мне тебе чего-то доказывать? Во первых, ты не знаешь даже азов математики, во вторых, мне за это не платят.

А нахрена мне тебе чего-то доказывать?

Сказанное принято доказывать, а не трепаться.

Сказанное принято доказывать, а не трепаться.

10 октября 2009 года, 14:50. Там был пример.

Так ссылка будет? Или просто потрепаться зашёл?

Дату и время я тебе сказал. Было это на ЛОРе. Информации для поиска - достаточно.

Читаем внимательно man zfs: http://www.freebsd.org/cgi/man.cgi?query=zfs&manpath=FreeBSD 9.0-RELEASE&...

checksum=on | off | fletcher2,| fletcher4 | sha256

	   Controls the checksum used to verify data  integrity.  The  default
	   value  is  on, which automatically selects an appropriate algorithm
	   (currently, fletcher4, but this may change in future releases). The
	   value  off  disables  integrity  checking  on  user data. Disabling
	   checksums is NOT a recommended practice.

	   Changing this property affects only newly-written data.