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

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

Допустим, ты выделил 900 Мб под данные и 100 Мб под метаданные. Файлов было очень много и место под метаданные кончилось, а на разделе с данными ещё 400 Мб. Что делать будем?

Второй вариант, когда юзер решил записать 950 метровый файл. Для него свободно 1000 Мб, но на записи 900-го метра возникает облом. Что делать?

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

двигаем данные

Абалдеть как не по-наркомански. При каждом подключении нового девайса двигать данные? Не позорься.

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

Всё пустое место на девайсе - в один том.

Так, хорошо.

(непонятно ещё, зачем это вообще делать)

Юзер решил уменьшить раздел.

то двигаем данные и откусываем нужный кусок.

А вот тут самое интересное. Как двигать данные? Желательно не отрывая пользователя от прослушивания музончика, просмотра киношек и набора текстиков.

Это и есть тот момент, где я просил быть ближе к реализации. Не «как-то там двигаем данные», а расскажи, как именно двигать данные.

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

Чтобы не было как сейчас в btrfs, очевидно

Что за деццкий сад? В btrfs сделано аналогично lvm - тома, подтома, снапшоты, всё выделяется и удаляется динамически.

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

Интересно. У мегабакса вроде было ускорение лисы переносом профиля на tmpfs. Но у него было с костылями, а если на уровне ФС сделать, то это интересно

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

Допустим, ты выделил 900 Мб под данные и 100 Мб под метаданные. Файлов было очень много и место под метаданные кончилось, а на разделе с данными ещё 400 Мб.Что делать будем?

Axon

двигаем данные и откусываем нужный кусок.

Второй вариант, когда юзер решил записать 950 метровый файл. Для него свободно 1000 Мб, но на записи 900-го метра возникает облом. Что делать?

То же самое. Кстати, эту проблему нынешняя схема, очевидно, не решает никак. Собственно, на это я напоролся.

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

У мегабакса вроде было ускорение лисы переносом профиля на tmpfs.

У меня тоже было. Ктати, рекомендую, летает как реактивный.

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

Что за деццкий сад? В btrfs сделано аналогично lvm - тома, подтома, снапшоты, всё выделяется и удаляется динамически.

Ага, вот только, почему-то, места вечно не хватает когда оно, по факту, есть.

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

Абалдеть как не по-наркомански. При каждом подключении нового девайса двигать данные?

Зачем?

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

А вот тут самое интересное. Как двигать данные? Желательно не отрывая пользователя от прослушивания музончика, просмотра киношек и набора текстиков.

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

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

«Вечно» - это в пределах твоего теста с одногигабайтным разделом?

Зайдите в btrfs FAQ.

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

Ну. Один том на устройство. Новое устройство - новый том. Зачем двигать данные на имеющемся, я не понял?

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

Как вариант, можно их сразу по порядку раскладывать.

Наверное, я не очень понятно объясняю. Нельзя просто так подвинуть данные. Потому что метаданные указывают на данные, а не наоборот. Допустим, ты решил подвинуть блок номер 32664. Ты его даже прочитал. Но вот незадача: если просто скопировать его, то метаданные продолжат указывать именно на это старое место. А там уже неактуальные данные. Этот кусок может содержать уже данные другого файла. Или даже метаданные.

Придётся создавать обратный индекс или каждый раз обходить дерево (не файловое, а дерево метаданных).

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

А в чём разница?

Один том сразу на всё устройство. Вы читать не умеете, или издеваетесь?

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

Вот там как раз и говорится, что может кончится место для метаданных, в то время как места под данные ещё много. Поэтому и не выделяется один том на всё устройство.

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

Придётся создавать обратный индекс или каждый раз обходить дерево (не файловое, а дерево метаданных).

Зато это почти никогда не понадобится, а для всех нормальных юзкейсов значительно снизится оверхед по свободному месту.

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

Вот там как раз и говорится, что может кончится место для метаданных, в то время как места под данные ещё много. Поэтому и не выделяется один том на всё устройство.

И, в итоге, получается наоборот. А иногда получается и так же, несмотря на костыли с неполным выделением места.

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

В чём смысл? Зачем?

Ещё раз: чтобы не было как в ОП. И, на всякий случай, повторюсь: я считаю ущербным костылём саму идею запихивания LVM в FS, и все мои рассуждения о стратегии выделения томов убоги изначально, потому что находятся в рамках убогой концепции этих самых томов. Мне кажется, что даже эта убогая концепция реализована хуже, чем можно, но, даже если я неправ, то она всё равно остаётся убогой в целом.

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

чтобы не было как в ОП

Мощный аргумент.

я считаю ущербным костылём саму идею запихивания LVM в FS

Ну я и говорю: завёл тред чтобы подартаньянить. Мне вот концепция lvm-в-фc кажется офигенно удобной.

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

И как часто?

Часто.

Есть статистика?

Любимая отмазка УМВРщиков. Напомните мне, как расшифровывается аббревиатура «FAQ»?

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

Напомните мне, как расшифровывается аббревиатура «FAQ»?

Ещё более мощно.

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

Зато это почти никогда не понадобится, а для всех нормальных юзкейсов значительно снизится оверхед по свободному месту.

В теории это звучит хорошо. Если отделять дерево от данных, то делить придётся часто. Если не делить, получится как в reiserfs. Со временем начинается фрагментация из-за того, что блоки дерева разбросаны по разделу и вместо больших сплошных кусков остаётся много маленьких.

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

Тем, что меньше движений

LOL.

и в lvm снапшоты какие-то недоделанные.

А btrfs - такая доделанная, да...

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

В теории это звучит хорошо. Если отделять дерево от данных, то делить придётся часто. Если не делить, получится как в reiserfs.

Кстати, а нафига там вообще эти метаданные?

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

К третьей странице срыв покровов дошёл до ненужности метаданных...

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

Чем LVM в FS лучше LVM?

Можно двигать между PV только сегменты, занятые данными. ФС знает, где они, а LVM — нет. Для LVM это просто место. Опять таки, иногда это плюс, а иногда минус. Всё дело в компромисах.

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

Тот, кто размечает корень сабжевой ФС - ССЗБ.

Это то понятно, но речь пошла то не об этом.

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

Кстати, а нафига там вообще эти метаданные?

Чтобы ты не думал, с какого байта по какой лежит твой файл, а мог обращаться к нему по имени. Чтобы ты знал, какого он размера, когда создан и кому принадлежит. Метаданные — это данные, описывающие данные. Иногда их называют inode'ами, иногда — содержимым директорий, иногда — меткой диска и его UUID.

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

Они просто ущербные.

А разве когда они там появились это не было «Вау! Супер! Как я жил все эти годы без снапшотов!?», а?

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

Ну так скажи - сколько.

34052 байта в случае гигового раздела и тех же самых данных, что и в ОП.

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

А разве когда они там появились это не было «Вау! Супер! Как я жил все эти годы без снапшотов!?», а?

Угадай где они появились раньше, в zfs или в lvm. Плюс, почитай как работают они там и там.

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