LINUX.ORG.RU

Btrfs - поведение и симптомы

 , , ,


1

2

Всем привет.

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

Система работает по ощущениям медленее чем на ext4. Еще и глючить в некоторых местах стала.

Подскажите может нужно какие-то оптимизации в ядре делать?

Или так она себя и ведет всегда?

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

// просто отлично тут устроился. Не хотелось бы снова терять время на
// кастомизацию.


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

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

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

hope13 ★★★
()
Ответ на: комментарий от hope13

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

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

yurikoles ★★★
()

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

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

cuki ★★★★
()

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

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

max_udoff
()
Ответ на: комментарий от max_udoff

btrfs

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

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

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

tiile
() автор топика
Ответ на: btrfs от tiile

// [offtop]

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

anonymous
()

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

это вы к тому

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

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

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

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

tiile
() автор топика
Ответ на: это вы к тому от tiile

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

NTFS

yumko ★★
()
Ответ на: комментарий от yumko

NTFS

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

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

ext4 или reiserfs

lyrix87
()
Ответ на: это вы к тому от tiile

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

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

xtraeft ★★☆☆
()
Ответ на: комментарий от no-dashi

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

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

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

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

max_udoff
()
Ответ на: комментарий от iZEN

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

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

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

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

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

max_udoff
()

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

thematt
()
Ответ на: комментарий от no-dashi
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

r2d2
()
Ответ на: комментарий от r2d2

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

no-dashi ★★★★★
()

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

unikum ★★★★★
()

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

Sholy
()
Ответ на: комментарий от no-dashi

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

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

iZEN ★★★★★
()
Ответ на: комментарий от no-dashi

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

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

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

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

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

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

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

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

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

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

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

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

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

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

no-dashi ★★★★★
()

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

Mynah
()
Ответ на: комментарий от iZEN

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

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

Читаем внимательно 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.
Сейчас по умолчанию используется более стойкий алгоритм fletcher4.

iZEN ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.