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

А я бы, пожалуй, использовал бы (будь оно там). Где-нибудь в /usr/include, /usr/src и /usr/share/man и тп каталогах, в которых скорость доступа не важна, а сжимаются хорошо.

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

У меня пока тоже не складывается. SPL из AUR'а не собирается с ядром 3.6, а для версии с включёнными патчами для совместимости ещё PKGBUILD'а нет. Самому возиться влом, так что подожду.

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

Одно могу сказать точно: я там ни одного хардлинка не создал. Не думаю, что они присутствуют из коробки, потому что мне может прийти в голову мысль каждую корневую директорию вынести на свой раздел, и тогда они сломаются. Так что храдлинки - это вряд ли. А можно как-то узнать, есть ли они на ФС?

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

А можно как-то узнать, есть ли они на ФС?

%n напечатает число хардлинков. Если есть, в выводе будет что-то кроме 1.

# find / -mount -type f -printf "%b %n\\n" | awk '{print $2}' | sort -u

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat
find  -mount -type f -printf "%b %n\\n" | awk '{print $2}' | sort -u
1
10
108
11
12
13
14
15
17
18
2
24
3
31
35
4
42
5
6
7
8
9

Итрересно, что это, и откуда взялось...

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

Еще журнал, кол-во инодов указывается с помощью -N кажется. Еще под журнал место уходит. На 10 гигов у меня было занятно 50 метров ext4.

Woklex
()

Вероятно, если будешь копировать из под рута через mc (который регулярно вызывает fsync), то файлы влезут на раздел btrfs. fsync от простого юзера на btrfs не прокатывает частенько. fsync нужен для пересчета размера при включенном сжатии. Но не факт, что это проканает: сильно зависит от погоды на марсе и соотношения размера раздела к размеру метаданных.

ps: сабж не нужен.

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

Вероятно, если будешь копировать из под рута через mc (который регулярно вызывает fsync), то файлы влезут на раздел btrfs.

Я копировал mc из-под своего пользователя. Пробовал и от рута. Пробовал и rsync'ом. На 1 ГБ раздел во всех случаях влезало 822МБ. На 870 случился затык.

и соотношения размера раздела к размеру метаданных.

А вот это да, как-то странно выбирается. У автора топика выделилось 200 МБ под метаданные, а у меня 50.

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

У меня вызывает по окончанию копирования. Хорошо видно, если на флешку копируешь - он подвисает на 100% на неопределенное время. Вместо fsync может вызывать fdatasync или ещё чего.

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

Хорошо видно, если на флешку копируешь - он подвисает на 100% на неопределенное время.

Это опция монтирования, flush. Примерно как sync, только делает сбрасывает буферы после закрытия файла. Если копировать много файлов, подвисать будет после каждого.

Вместо fsync может вызывать fdatasync или ещё чего.

в выводе strace -c нет подстроки sync

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

А ошибки в ext3, это тогда иллюстрация к чему, интересно?

Когда была последняя, ведущая к corruption и data loss?

http://phoronix.com/forums/showthread.php?74697-EXT4-Data-Corruption-Bug-Hits...

Я не сомневаюсь, что у Теда процесс поставлен правильно. И? Есть такое понятие, как code maturity - ext4 его еще не достигла.

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

Есть такое понятие, как code maturity - ext4 его еще не достигла.

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

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

Лучше б zfsonlinux пробовал.

Пробовал? Зеркало его же родными средствами для файл помойки потащит? Btrfs как-то стрёмно юзать, а менять уютную генточку на всякие солярки и бесов не хочется...

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

Вы осознаёте разницу между прикладной программой и файловой системой?

Да. Поэтому я перевёл / на ext4 только спустя полгода после того, как поток сообщений о проблемах схлынул и её рекомендовали в продакшен. И ещё лишь спустя год после этого я перевёл на неё файлопомойку.

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

Багрепорт уже шишкин писал хрен знает сколько лет назад в рассылку разработчикам.

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

Когда была последняя, ведущая к corruption и data loss?

Последняя известная пофикшенная? Судя по ссылке во времена переезда гугла на ext4.
А когда была последняя — понятия не имею.

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

А ошибки в ext3, это тогда иллюстрация к чему, интересно?

Когда была последняя, ведущая к corruption и data loss?

Последняя известная пофикшенная? Судя по ссылке во времена переезда гугла на ext4.

Ты говоришь об ошибке в ext4 или ext3?

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

Ошибка в ext4, которая досталась в наследство от ext3. Алсо, если ты действительно читал ссылки, то должен был заметить, что сабжевый «ужасный баг ext4» появился раньше 3.6.что-то-там, а не был вызван недавним патчем, как считалось ранее. В конечном итоге он возможно тоже будет родом из ext3.

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

должен был заметить, что сабжевый «ужасный баг ext4» появился раньше 3.6.что-то-там

Появился - возможно, и раньше, проявился - в 3.6.x

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

Пробовал?

taz@tazwork:~$ uname -a
Linux tazwork 3.6.1-pf #1 SMP PREEMPT Thu Oct 11 13:24:09 MSK 2012 x86_64 Intel(R) Core(TM) i7-3770S CPU @ 3.10GHz GenuineIntel GNU/Linux
taz@tazwork:~$ sudo zfs list
NAME               USED  AVAIL  REFER  MOUNTPOINT
zfs_test          18.6M  3.87G  44.8K  /zfs_test
zfs_test/volume1  18.4M  3.87G  18.4M  /zfs_test/volume1

Зеркало его же родными средствами для файл помойки потащит?

Да.

Btrfs как-то стрёмно юзать, а менять уютную генточку на всякие солярки и бесов не хочется...

Btrfs - лютое глюкало. К тому же зфс есть уже в репах генты, в ~ ветке.

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

К тому же зфс есть уже в репах генты, в ~ ветке.

Вообще красота. На досуге куплю пару новых хардов для ФП, опробую. Интересно, сильно ли геморно /boot и / на zfs заставить пахать?

erfea ★★★★★
()
Ответ на: комментарий от ei-grad

зачем всякие факи, если есть уютненькие толксы, где ТС может в любое время суток поплакать в жилетку добрым завсегдатаям?

registrant ★★★★★
()
Ответ на: комментарий от Axon
ei-grad@ei-grad ~ $ sudo dd if=/dev/zero bs=1M count=1024 of=btrfs.img
1024+0 записей получено  
1024+0 записей отправлено
 скопировано 1073741824 байта (1,1 GB), 5,99844 c, 179 MB/c
ei-grad@ei-grad ~ $ sudo mkfs.btrfs ./btrfs.img -M                    
                         
WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

Created a data/metadata chunk of size 8388608
fs created label (null) on ./btrfs.img
	nodesize 4096 leafsize 4096 sectorsize 4096 size 1.00GB
Btrfs Btrfs v0.19
ei-grad@ei-grad ~ $ sudo mount -t btrfs -o compress=lzo ./btrfs.img /mnt/btrfs
ei-grad@ei-grad ~ $ du -shc Фото/IMG_0* | tail -n 1                          
909M	итого                                      
ei-grad@ei-grad ~ $ sudo cp Фото/IMG_0* /mnt/btrfs 
ei-grad@ei-grad ~ $ btrfs filesystem df /mnt/btrfs
System: total=4.00MB, used=4.00KB    
Data+Metadata: total=1020.00MB, used=606.70MB
ei-grad@ei-grad ~ $ 

</thread>

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

У тебя там прямым текстом написано что блок выделенный под метаданные какого-то хрена занимает пол файловой системы. А tazhate и прочие btrfs-ненависники просто неосиляторы.

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

Офигеть, певрый годный ответ в треде. Однако, это не отменяет того факта, что btrfs неверно выделяет место при отделении метаданных от данных, судя по всему, независимо от размера раздела. По крайней мере, на 2Gb это вполне выражено.

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

У тебя там прямым текстом написано что блок выделенный под метаданные какого-то хрена занимает пол файловой системы.

Вот только место «заканчивается» задолго до того, как заполняется вторая половина.

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

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

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

Место заканчивается на текущем выделенном блоке данных, а чтобы выделить новый места не хватает. Если подкрутить metadata_ratio, то можно добиться выделения ещё нескольких блоков данных поменьше, тогда они займут почти весь девайс. А вот как подкрутить размер блоков metadata я не вижу. Надо бы найти нормальную документацию по текущим опциям, наверно в Documentaion ядра надо смотреть...

ei-grad ★★★★★
()
Последнее исправление: ei-grad (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.