LINUX.ORG.RU
ФорумTalks

Решил попробовать btrfs

 ,


1

1

Зачесалось мне, тут, пощупать в деле btrfs, а именно - её фичу прозрачной компрессии. Что ж, дурное дело - нехитрое.

[$] sudo dd if=/dev/zero bs=1M count=1024 of=btrfs.img                                        
1024+0 записей получено
1024+0 записей отправлено
 скопировано 1073741824 байта (1,1 GB), 11,4495 c, 93,8 MB/c
[$] sudo mkfs.btrfs ./btrfs.img                                                               

WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

fs created label (null) on ./btrfs.img
	nodesize 4096 leafsize 4096 sectorsize 4096 size 1.00GB
Btrfs Btrfs v0.19
[$] sudo mount -t btrfs -o compress=lzo ./btrfs.img /mnt
[$] df -h /mnt                                                                             
Файловая система Размер Использовано  Дост Использовано% Cмонтировано в
/dev/loop0         1,0G          56K  894M            1% /mnt
Хм, где мои 106 метров? А, ну да, метаданные-шметаданные, занято, значит нужно, наверное. Что ж, попробуем на неё что-нибудь записать. Например, папку с фоточками.
[$] du -h Барселона
24M	Барселона/Конфа
93M	Барселона/Монсеррат
540M	Барселона
Отлично, размер подходит. Пишем:
[$] sudo rsync -av Барселона /mnt
sending incremental file list
Барселона/
Барселона/P1020344.JPG
...
...
...
Барселона/P1020541.JPG
Барселона/P1020541.MOV
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
rsync: write failed on "/mnt/Барселона/P1020541.MOV": No space left on device (28)
rsync error: error in file IO (code 11) at receiver.c(322) [receiver=3.0.9]
rsync: connection unexpectedly closed (2388 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9]
WTF? O_o
[$] du -h /mnt
0	/mnt/Барселона/Конфа
0	/mnt/Барселона/Монсеррат
206M	/mnt/Барселона
206M	/mnt
[$] df -h /mnt
Файловая система Размер Использовано  Дост Использовано% Cмонтировано в
/dev/loop0         1,0G         206M   76M           74% /mnt
O_O
Отличненько мы место сэкономили... И это ещё предлагают использовать для корня в мейнстрим-дистрибутивах? Вы как хотите, а я пас. Проживу, как-нибудь, без сжатия.
Дискасс.

★★★★★

Последнее исправление: Axon (всего исправлений: 3)

попробуй заново, только добавь к опциями монтирования max_inline=256

i-rinat ★★★★★
()
Ответ на: комментарий от unikum
sudo btrfs filesystem df /mnt                                                             :(
Data: total=279.38MB, used=204.11MB
System, DUP: total=8.00MB, used=4.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=358.31MB, used=456.00KB
Metadata: total=8.00MB, used=0.00
Axon ★★★★★
() автор топика
Ответ на: комментарий от Kindly_Cat

То, что btrfs жрёт место под свои нужды - ни для кого не секрет.

Ext4 тоже жрёт. Нюанс в количестве.

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

Это не детская болезнь, а совершенно свежая регрессия.

Ты, конечно, понимаешь, что эта регрессия внесена невинным изменение в стабильной серии, и осознанно пользуешься ФС такого уровня зрелости?

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

Охотно верю, что тебе нужен был раздел в 1 гигабайт и ты искренне огорчился из-за того, что btrfs на таких маленьких разделах непригодна.

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

Вот и вопрос: какого хрена из всего раздела под данные отведена только четверть? И второй вопрос: 279.38 + 358.31 + 8 + 8 + 4 = 657.69. Где ещё 340 метров?

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

Охотно верю, что тебе нужен был раздел в 1 гигабайт

Если места дофига, то зачем его экономить? Не один, так пять, принципиальной разницы нет.

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

Сделал в 8 раз больше места, чем у меня, для того же объёма данных. Молодец, чо. Выхлоп btrfs filesystem df в студию.

Axon ★★★★★
() автор топика
Последнее исправление: Axon (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Ты, конечно, понимаешь, что эта регрессия внесена невинным изменение в стабильной серии, и осознанно пользуешься ФС такого уровня зрелости?

От этого не застрахована ни одна живая ФС. Ещё раз: shit happens.

Axon ★★★★★
() автор топика
Ответ на: комментарий от Axon
avalon Графика # btrfs filesystem df /mnt/temp
Data: total=827.19MB, used=555.27MB
System, DUP: total=8.00MB, used=4.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=409.56MB, used=2.02MB
Metadata: total=8.00MB, used=0.00
Kindly_Cat
()
Ответ на: комментарий от Axon

И вы хотите сказать, что это нормально для раздела на 8 гигабайт, да?

btrfs динамически выделяет сегменты из пула. Это размер такого сегмента. Наполнится — будет выделен новый.

i-rinat ★★★★★
()
Ответ на: комментарий от Kindly_Cat

Мне как-то всё равно, я мегабайты не считаю.

Счастливый вы человек. Богатый, наверное. Хотел бы я, чтобы мне тоже было пофиг на десятикратный оверхед...

Axon ★★★★★
() автор топика
Ответ на: комментарий от i-rinat

btrfs динамически выделяет сегменты из пула. Это размер такого сегмента. Наполнится — будет выделен новый.

Ok. Почему у меня он не выделился?

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

Где там десятикратный? Каталог весит 554 Мб.

А места на восьмигиговом разделе всего 827.19 Мб.

Axon ★★★★★
() автор топика
Последнее исправление: Axon (всего исправлений: 4)
Ответ на: комментарий от Axon

Ещё раз: shit happens.

Ещё раз: этот shit не просто так happened.

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

А можно то же самое, но понятнее?

Это как LVM. Для данных, метаданных и системной информации btrfs выделяет «LV». То есть под метаданные сразу выделяется сплошной кусок. Под данные — другой кусок. Как только куски кончаются, добавляется ещё LV нужного типа. А если ты подцепляешь ещё один девайс/раздел к btrfs — это как если ты к LVM к группе томов цепляешь ещё один PV.

i-rinat ★★★★★
()
Ответ на: комментарий от Kindly_Cat

Это место, выделенное для данных. У меня, вот, оно кончилось, и привет. Таким чудесным образом на гигабайтный раздел помещается 280 метров данных, а на восьмигигабайтный - 830 метров.

Axon ★★★★★
() автор топика
Ответ на: комментарий от i-rinat

Это как LVM. Для данных, метаданных и системной информации btrfs выделяет «LV». То есть под метаданные сразу выделяется сплошной кусок. Под данные — другой кусок. Как только куски кончаются, добавляется ещё LV нужного типа. А если ты подцепляешь ещё один девайс/раздел к btrfs — это как если ты к LVM к группе томов цепляешь ещё один PV.

Эээммм... А нафига такие сложности? И почему это не работает?

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

Копирую туда же вдогон фильм:

┌─[/zero/shell/frag/basic]
└─[frag@avalon]: du -h /media/video/Movies/Бегущий\ по\ лезвию.mkv 
4,8G    /media/video/Movies/Бегущий по лезвию.mkv
avalon Movies # rsync -av "Бегущий по лезвию.mkv" /mnt/temp
sending incremental file list
Бегущий по лезвию.mkv

sent 5115142341 bytes  received 31 bytes  44673732.51 bytes/sec
total size is 5114517894  speedup is 1.00
avalon Movies # btrfs filesystem df /mnt/temp
Data: total=7.17GB, used=5.29GB
System, DUP: total=8.00MB, used=4.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=409.56MB, used=8.95MB
Metadata: total=8.00MB, used=0.00
Kindly_Cat
()
Ответ на: комментарий от Axon

Ok. Почему у меня он не выделился?

А хз. Я в коде не копался. Но подозреваю, что из-за сжатия. До сброса на диск нельзя сказать, сколько места займёт, так что btrfs перестраховывается.

Ну и ещё есть такой момент: btrfs «мыслит» масштабно. Используются сегменты (не помню точного термина) порядка 0.5-1 ГБ. На разделе в 1 ГБ ей тесно.

Кстати, я проверил у себя на 1 ГБ разделе (debian testing, 3.2.0 с патчами, btrfs v0.19) со сжатием lzo. Записывал музычку, по 7-10 МБ файл. Записалось 700 с чем-то метров, без вопросов. Правда потом свободное место как-то странно скакнуло с 220 метров до 140. Точных цифр не заметил.

i-rinat ★★★★★
()
Ответ на: комментарий от Axon

А нафига такие сложности?

Какие сложности? Это, по сути, LVM, перенесённая на уровень ФС, ну так никто и не говорил, что Btrfs это просто ФС.

Kindly_Cat
()
Ответ на: комментарий от i-rinat

Ясно, спасибо за объяснения. В общем, мистики стало поменьше, как и желания когда-либо ещё прикасаться к этому порождению сумрачных гениев из оракла. Пусть тонет в костылях где-нибудь подальше от меня.

Axon ★★★★★
() автор топика
Последнее исправление: Axon (всего исправлений: 1)
Ответ на: комментарий от Axon

У меня столько фото нет. Вот копирую размеров в 3,8 Гб:

avalon Movies # rsync -av /media/data/data/Графика /mnt/temp
avalon Movies # btrfs filesystem df /mnt/temp
Data: total=7.17GB, used=3.81GB
System, DUP: total=8.00MB, used=4.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=409.56MB, used=15.49MB
Metadata: total=8.00MB, used=0.00
Kindly_Cat
()
Ответ на: комментарий от Kindly_Cat

Какие сложности? Это, по сути, LVM, перенесённая на уровень ФС

Вот эти сложности. В конце концов, если уж пихать LVM в FS, то зачем делать такую наркоманскую стратегию выделения томов?

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

А если нужна скорость - tmpfs.

Прочитал, задумался. А существует ли fs со 100% кешированием на чтение? т.е. пишем на диск и одновременно в память, а читаем из памяти, при загрузке естественно загружаем ее содержимое в память. Для критичных к скорости чтения мест могло бы быть интересно.

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

Так и скажи, что с самого начала хотел подартаньянствовать.

С самого начала я хотел попробовать новую для себя FS. А когда я увидел то, что увидел, я просто не смог не вбросить такое сюда.

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

А существует ли fs со 100% кешированием на чтение? т.е. пишем на диск и одновременно в память, а читаем из памяти, при загрузке естественно загружаем ее содержимое в память. Для критичных к скорости чтения мест могло бы быть интересно.

любая FS + tmpfs + unionfs?

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

А ты LVM когда-нибудь пользовался? Обычно таким образом и поступают - выделяют или расширяют тома по мере необходимости.

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

А существует ли fs со 100% кешированием на чтение? т.е. пишем на диск и одновременно в память, а читаем из памяти

Кхм. Вообще-то любая ФС должна вести себя так - за это отвечает менеджер памяти ОС.

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

В конце концов, если уж пихать LVM в FS, то зачем делать такую наркоманскую стратегию выделения томов?

О, это мой любимый вопрос. :-)

А как бы сделал ты? Вот давай на пальцах набросай идею менее «наркоманской» стратегии. И поближе к реализации. Не «выделяем где-то там», а «проходим по списку пустых мест и выбираем наименьшее из подходящих».

i-rinat ★★★★★
()
Ответ на: комментарий от Kindly_Cat

А ты LVM когда-нибудь пользовался?

Нет. Не вижу нужды.

Обычно таким образом и поступают - выделяют или расширяют тома по мере необходимости.

Какая может быть необходимость в том, чтобы не выделять всё место сразу?

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

Какая может быть необходимость в том, чтобы не выделять всё место сразу?

Лучше скажи, зачем выделять всё место сразу.

Kindly_Cat
()
Ответ на: комментарий от i-rinat

А как бы сделал ты? Вот давай на пальцах набросай идею менее «наркоманской» стратегии.

Всё пустое место на девайсе - в один том. Если пользователю понадобилось разбить его на два (непонятно ещё, зачем это вообще делать), то двигаем данные и откусываем нужный кусок.

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

вроде как через aufs можно такое сделать

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

Лучше скажи, зачем выделять всё место сразу.

Чтобы не было как сейчас в btrfs, очевидно. Место лишним не бывает, а вот наоборот - вполне. Так зачем, всё-таки, его специально ограничивать?

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