reiserfs

онтопик эту хрень не поддерживает

Разупорись!

нечего сказать - не пиши

Грепнул по исходникам ядра

$ git grep reiserfs | wc -l
2645

Мне есть что сказать, а вот ты тупость городишь. Вон, анон ниже привёл тебе пруф, раз ты такой неверующий.

не вижу - анон в игноре

Грепнул по исходникам ядра

$ git grep reiserfs | wc -l
2645

anonymous (16.04.2015 23:16:07)

Так то.

да, был не прав

Ты, вероятно, с reiser4 спутал.

Всем спасибо! Я понял: btrfs ещё не готова. Причём, ни к десктопу ни (тем более) к серверу.

А она и не будет готова. Грубая толпа Торвальдса и сотоварищей не подходит для написания таких тонких материй, как файловая система. Они только тупую ext2 могут успешно курочить :)

Кто использует btrfs повседневно для хранения каких-либо данных? Каковы ваши впечатления? Есть нюансы?

использую на нескольких компьютерах (desktop) и серверах. кроме снапшотов — ни какого функционала НЕ использую.

*** общие впечатления хорошие. ***

нравится работа с громандным количеством мелких файлов (ext4 тут не подходит, так как ext4 выдеяюет inode НЕ динамически). использовать другие файловые системы (кроме ext4 и btrfs) — смысла не вижу, так как ext4 и btrfs — это мэйнстрим в GNU/Linux.

из минусов btrfs — на данный момент — это постепенное накопление УЖАСНОЙ фрагментации в некоторых файлах. (проблема обходится через опцию «autodefrag», но «autodefrag» тоже имеет свои недостатки)

Протестировал работу btrfs и ext4 на старом 2.5/80Gb hdd.
В итоге на btrfs тормоза, chromium запускается ~50 сек [...]
На ext4, chromium запускался ~7 секунд [...]

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

...и это ОЧЕНЬ интересно один разок понаблюдать! то есть, на мой взгляд это очень интересный феномен :) ..

другое дело что этот феномен ни как нельзя использовать на практике.

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

например, говоря про файловую систему — этот феномен ведь практически ни чего не говорит про производительность файловой системы на компьютере (а лишь говорит об производительности файловой системы на *старом* компьютере)

но всё равно это остаётся интересным! :-)

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

Комп как раз не старый - четырёхъядерный Xeon и 4Gb ram.
Специально на старом hdd тестил, чтобы он заведомо был узким место.

именно

Комп как раз не старый - четырёхъядерный Xeon и 4Gb ram.
Специально на старом hdd тестил, чтобы он заведомо был узким место.

ну тогда это совсем другое дело! :)

(очень кстати хорошо что у тебя есть такая возможность проверок!).

но в этом случае — что-то здесь не так...

проведи попробуй ещё разок этот эксперимент. не должно быть такого — это явная где-то ошибка.

например, если на HDD оказался один из секторов плохим, то он будет считыватсья несколько раз, до тех пор пока не прочитается (некоторое количество таких секторов — увеличивают время чтения многократно, но только в «особые» моменты).

если в «нужное» место попал такой сектор — то вот как раз так и получится. :-)

а если жёсткий диск имеет механические проблемы с поиском секторов — то это кстати может негативно сказаться на btrfs — в бОльшей степени чем на ext4.

...так как btrfs в бОльшей мере подвержена фрагментации (см сообщение немного выше(*)..) . файлы web-браузера склонны становиться очень фрагментированными (со временем) — в btrfs, в случае если нет «autodefrag».

то есть — расскажи — сеолько времени было btrfs у тебя на том компе (сразу ли оно начало тупить? или со временем деградация накопилась?), и было ли «autodefrag»? («autodefrag» должно быть установлено сразу после форматирования btrfs, а не когда деградация уже накопилась)

# P.S.: и да — почему оперативной памяти так мало? всё-таки кеширование файловой системы — должно быть. без кеширования плохо :-)

4Gb ram
btrfs
почему оперативной памяти так мало?

Так и запишем, жрёт память аки свинья помои.

глупенький, если у тебя 4G и при этом ты не запускаешь ни какие программы — то разумеется этого хватит на всё :-)

а если у тебя 4G , и при этом ВСЕ эти 4G съели GUI-программы....

....то как ты считаешь — кэш файловой системы будет ли работать в этом случае? :-)

жрёт память

файловая система — нет. не жрёт :) .. она почти-всю свою память отдаст на «нужное дело» как только ядро попросит файловую систему об этом :-)

На самом деле, btrfs я тестил на двух разных 2.5 hdd - сначала на 80Gb потом скопировал всё на 120Gb. На 120 винте работало немного быстрее, но с тем же залипанием значков на десктопе и долгим запуском chromium.

Затем форматнул 80Gb в ext4 и перенёс туда систему ещё раз, на ext4 всё стало работать гораздо шустрее.

Кэш браузера храню в tmpfs

XDG_CACHE_HOME=/tmp/.cache

tmpfs on /var/log type tmpfs (rw,noatime,nosuid,nodev,noexec)
tmpfs on /tmp type tmpfs (rw,noatime,size=100%)

Система(gentoo) изначально стояла и стоит на 32Gb флешке

/dev/sdb on / type btrfs (rw,noatime,compress=zlib,ssd,ssd_spread,space_cache,autodefrag)

btrfs filesystem defragment -r -v -czlib /

btrfs balance start / -v -musage=75 -dusage=75

затем перенёс всё на другой hdd, там всё тоже самое

Сейчас у меня одна и та же система на трёх носителях - флешка с btrfs, hdd(80gb) c ext4, hdd(120gb) с btrfs.

переносил на винт с помощью dd, затем убрал из fstab на hdd опции ssd* отключил флешку и загрузился с винта, выполнил дефрагментацию

переноси через

btrfs send ... | btrfs receive ...

иначе, ты переносишь со всеми накопившимия деградациями..

выполнил дефрагментацию

как это ни странно — но эта дефрагментация НЕ исправляет особо ни чего. (поэтому и рекомендую ``btrfs send ... | btrfs receive ...`` и сразу флаг ставь «autodefrag» )

Hе, память тут точно не при делах, 4GB это дофига. Плюс у меня там ещё 4Gb swap в zram. Вся система, спокойно в ram(tmpfs) пересобирается.
А при обычном использовании, потребление памяти не вылазит за 1.5Gb, всё остальное в кеш идёт.

кстати, да.. заметил ты большой любитель сжатия :-)

не буду утверждать что это обязательно плохо..

но не через мерно ли ты его везде засовываешь? :-)

Тогда уж проще новую fs создать, да тупо файлы в неё скопировать, так же как на ext4 переносил.
Хотя вру, переносил не через dd, а через pv

pv < /dev/sda > /dev/sdb

Кэш браузера храню в tmpfs

XDG_CACHE_HOME=/tmp/.cache

ну в таком случа у тебя точно какая-то неисправнось

если кеш Хромиума НЕ был якобы узким местом — то что тогда было узким местом — в момент открытия Хромиума?

учитывая твою перехаканную вдоль и поперёк систему (повсеместное включение «оптимизирующих» настроек и сжатий) — ...

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

потому что в ситуации когда всё поумолчанию — даже на самом дерьмовом жёстком диске (на нормальном компе) — не может Хромиум открываться несколько десятков секунд.

и ещё раз напишу про твои оптимизации :-)

вот вырезка из документации:

Mount -o ssd_spread is more strict about finding a large unused region of the disk for new allocations, which tends to fragment the free space more over time

то есть что им имеем.. я вижу это так:

если ты накопил огромную кучу фрагментированног освободного места — то ни какие дефрагментаторы это уже не смогли исправить.

(а как они исправят это? здесь только всё поновой форматировать!)

и потом dd (pv) — перенёс деградированную файловую систему на механический жёсткий диск — что всё УСУГУБИЛО, и в результате создало такой вот интересный феномен который ты имеешь.

впрочем — это очень занимательная история :-)

Тогда уж проще новую fs создать, да тупо файлы в неё скопировать, так > же как на ext4 переносил.
Хотя вру, переносил не через dd, а через pv

ну если тебе это кажется проще — то ОК..

а вообще если btrfs имеет встроенный специализированный инструмент для переноса снапшотов между разделами — то мне кажется этим инструментом надо пользоваться :-)

включение «оптимизирующих» настроек и сжатий

Zram начинает работать, когда ядро хочет свапануть. При обычном использовании компа, на 4Gb ram, у меня до этого никогда не доходит. Использую только для компиляции чего-нибудь тяжелого, чтобы вся сборка шла в ram (tmpfs умеет вытеснять себя в swap).
В том компе, на постоянной основе, система работает на ssd, поэтому не хочется диск тереть компиляцией.
С ssd(ext4) chromium стартует меньше секунды.

А btrfs compression, сильно помогает при работе с флешек или sd, например на arm mini-pc, там у меня gentoo спокойно работает с 4Gb sdcard.

Вот собственно и все «хаки».

btrfs имеет встроенный специализированный инструмент для переноса снапшотов между разделами

А вдруг там какая-нибудь скрытая деградация перенесётся :-)
Попробую вечером, для полноты эксперимента, на новой fs потестить.

ну там тоже всё не гладко :-)

сейчас пока-что вот так:

https://bugzilla.kernel.org/show_bug.cgi?id=68891

Работаешь кэпом и ставишь идиотские смайлики вместо знаков препинания в конце каждого предложения ты, а глупенький значит я... Ты уверен?

1) Да, но ты нам не верь.

2) Я: ноуты, десктопы, на домашнем NAS даже на 3 харда натянул. Год прошел, полет нормальный. Снапшоты — прикольная штука, почитай и настрой. Главное бэкапься на нормальные файловые системы. Нюанс: для образов виртуалок надо выключать COW.

3) Как-то жил же до 3.13, наверное и с ним ничего.

расскажи нам, сколько там надо памяти, чтобы zfs было комфортно и чтобы были очевидны её преимущества?

~1 Гб кэша на 1 Тб пула.

Похоже что тормоза btrfs на hdd из-за фрагментации, она на флешке незаметна была, после клонирования перенеслась на hdd и там уже проявилась в тормозах.

А defrag я запускал в уже загруженной с hdd системе, из иксов, он тогда все открытые файлы пропускает - не дефрагментирует, тоесть всё что стартует при включении компа осталось фрагментированным.

Сейчас глянул на флешке фрагментацию бинарника chromium'а:

# filefrag /usr/lib/chromium-browser/chrome
/usr/lib/chromium-browser/chrome: 688 extents found

Вот ещё весьма авторитетное мнение Шишкина, он шарит в матане и программировании и он прав:

It must be a highly unexpected and difficult question for file system
developers: «how efficiently does your file system manage disk space»?

In the meanwhile I confirm that Btrfs design is completely broken:
records stored in the B-tree differ greatly from each other (it is
unacceptable!), and the balancing algorithms have been modified in
insane manner. All these factors has led to loss of *all* boundaries
holding internal fragmentation and to exhaustive waste of disk space
(and memory!) in spite of the property «scaling in their ability to
address large storage».

This is not a large storage, this is a «scalable sieve»: you can not
rely on finding there some given amount of water even after infinite
increasing the size of the sieve (read escalating the pool of Btrfs
devices).

It seems that nobody have reviewed Btrfs before its inclusion to the
mainline. I have only found a pair of recommendations with a common
idea that Btrfs maintainer is «not a crazy man». Plus a number of
papers which admire with the «Btrfs phenomena». Sigh.

Well, let's decide what can we do in current situation..
The first obvious point here is that we *can not* put such file system
to production. Just because it doesn't provide any guarantees for our
users regarding disk space utilization.

I'll explain on a simple example, why is it important. Think of a file
system as a bank, which deducts an interest q. I.e. amount of money N
that you put on your account can be reduced to (N - qN). That said,
in order to buy a suit which costs M you should put to your account
not less than M/(1-q). Now imagine that the bank deducts 100% (q=1).
Will you bring your money to such bank? No. Not just because you are
greedy, but also because you won't be able to schedule your purchases.
So why should we push our users to keep money in such bank?

I should remind for developers that we work for *users*. They want a
*good* environment to run programs. Our subsystems should provide
*efficient* management of user's resources (such as memory and disk
space). A subsystem which is going to send all user's resources to the
toilet is *bad*!!!

If you decide to base your file system on some algorithms then please
use the original ones from proper academic papers. DO NOT modify the
algorithms in solitude: this is very fragile thing! All such
modifications must be reviewed by specialists in the theory of
algorithms. Such review can be done in various scientific magazines of
proper level.

Personally I don't see any way to improve the situation with Btrfs
except full redesigning the last one. If you want to base your file
system on the paper of Ohad Rodeh, then please, use *exactly* the
Bayer's B-trees that he refers to. That said, make sure that all
records you put to the tree has equal length and all non-root nodes of
your tree are at least half filled.

As to current Btrfs code: *NOT ACK*!!! I don't think we need such
«file systems».

Thanks!

авторитетное мнение Шишкина

этот «авторитет», за 10+ лет, так и не смог свою поделку в ядро продвинуть

А как это, пардон, связано? Какой-то у тебя неаргументный аргумент. Не говоря уже о том, что он (Шишкин) вообще-то и не хочет пропихивать r4 в ядро. Да и r4 не его, а (ныне несуществующей) Namesys...

А почему мнение какого-то там Шишкина, должно для меня быть авторитетным? Чем он знаменит?
Вот Oracle я знаю по virtualbox и btrfs, а Шишкина нет.

этот «авторитет», за 10+ лет, так и не смог свою поделку в ядро продвинуть

Ага, он до сих пор стоит в длинной очереди из тех, кто Торвальдсу в клювике хорошую файловую систему принёс.

А почему мнение какого-то там Шишкина

Не хочешь мнения Шишкина - не надо. Повтыкай в матан сам, разберись как следует, сформируй своё мнение, удивись, покайся в собственной былой безграмотности, затем скажи спасибо Шишкину, за то, что он уже давно всё разжевал.

Что такое - «матан»?
У меня есть ядро, там есть выбор fs, по ним есть инфа.
Я знаю, что если fs не включена в ядро, значит на то есть причины, какие - мне пофиг.

этот «авторитет», за 10+ лет, так и не смог свою поделку в ядро продвинуть

Это из разряда: «почему Гейм до сих пор не в Сколково». Ответ достаточно банальный: он туда и не просился.

Сейчас немного лучше ситуация: вместо 17% полезного использования свободоного места 33%. Хотя такой тест с сотнями тысяч двухкилобайтовых файлов мне кажется высосанным из пальца.

Сравнил ядро со Сколково.

Хотя такой тест с сотнями тысяч двухкилобайтовых файлов мне кажется высосанным из пальца.

у меня на компьютерах — несколько сотен тысяч мелких файлов (для вполне практических дел — а не синтетические тесты)...

..а что с ними не так? :-) .. что я должен ощущать — какие негативы?

При реальном размере данных ~300МБ на диске они занимаю 1G.

Разговоры об «авторитете» я оставлю верунам. Здесь же речь идёт исключительно о техническом обосновании и логике. Или ты как раз из тех верунов, для которых «обоснование» — пустой звук?

Хинт: «эту ФС никто и не продвигал в ядро». Такая причина делает ФС плохой?

При реальном размере данных ~300МБ на диске они занимаю 1G.

ясно. ну это фигня, вобщем-то...

такое даже легко просто незаметить.

Хинт: эту ФС продвигали в ядро, но не приняли.

Для меня, «обоснование» - это когда код включен в ядро.
Больше, я ничего не знаю и знать не хочу.

Мне пофиг на «матан» и прочее. Да, я верю, что на kernel.org лежит стабильное ядро.