я когда первый раз установил убунту, 6.04 словил кэрнел паник при простом обновлении, я тогда даже в ppa и настройки не лез даже...

Ну, господа

pedobear, erzent, King_Carlo, reprimand, Ivan_qrt и прочие сочувствующие.

Эксперимент с записью на ФС одинаковых файлов «пока есть место». Файлы были забиты рандомом.

Поскольку это всё CoW, в случае ошибки записи файла делался sync и проводилась ещё одна попытка (на всякий случай).

BTRFS

        0-byte 512-byte 1024-byte 2048-byte
-------------------------------------------
16M      20959     7588      4698      1844
128M    322233   115038     71607     28598
1024M  1370701   522487    316951    183192

REISER4

        0-byte 512-byte 1024-byte 2048-byte
-------------------------------------------
16M     100280    21581     12462      6760
128M    818482   175439    101520     55135
1024M  6564200  1400997    812038    441488

Лог эксперимента

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

А тенденции не видно? Если я запущу тест на 50G (я уверен, что результат будет аналогичен), ты тоже скажешь, мол, «50G ничего не значит»?

я уверен, что результат будет аналогичен

Мало ли что ты там уверен. У меня на ~70-гиговом SSD всё норм работает.

ты тоже скажешь, мол, «50G ничего не значит»?

Я скажу - точнее, уже сказал: хватит страдать херотой.

«Норм работает» не означает, что плотность файлов не скатилась в СГ (как было продемонстрировано для мелких размеров).

Норм работает - это норм работает, а что там куда скатывается у нервозных теоретиков - меня не волнует.

зачем мне это при 4 тб дисках? у меня сейчас на домашнем компе ссд на 512 гб и 3 hdd по 4 тб,расскажи, когда я почувствую эту проблему?

Ты её уже должен чувствовать, ВЕДЬ ШИШКИН СКАЗАЛ!!!111

эта проблема меня волновала в 2004-2007, когда у меня был винчестер на 30 гб,но сейчас у меня всё кроме бута и свапа меньше 60 гб не бывает.

Продолжай наблюдение.

Ггг. Ну да, потерять пару десятков гигабайт — не проблема, действительно. Ок, мне больше нечего сказать.

какая проблема при свободных 11 терабайтах.

Ext4 на 4-терабайтном разделе тоже потеряет гигабайты места банально под иноды. Напиши в рассылку какие они там все идиоты и ответы скопипасть сюда.

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

Ггг. Ну да, потерять пару десятков гигабайт — не проблема, действительно. Ок, мне больше нечего сказать.

А не заполнять zvol больше 85% это нормально? Сколько будет 15% от 4ТБ ? Всего лишь 614Гб, мелочь. Ок, мне больше нечего сказать.

Для нервозного теоретика - конечно не имеет смысла. Только у меня в приоритете практика, и если ФС уже год как работает на 5 баллов, то теоретические проблемы, вылезающие в особо феерических условиях, вызывают у меня примерно такую реакцию

А кто спорит с тем, что reiser4 эффективнее, чем семейство ext2fs? Но там это простительно, ибо by design.

reiser4 эффективнее, чем семейство ext2fs

Эффективнее, красивее, стройнее... прям ФС-непризнанный гений. Почему она не в ядре? Почему она не умеет снапшоты? Мне ехать, а не на теоретическую красоту фапать.

Но там это простительно, ибо by design

В Btrfs это тоже by design, но у тебя от этого почему-то бомбит.

Значит, zfs тоже неэффективно использует дисковое пространство.

Потому что не допилено. Всегда ваш, К. О.

Нет, в btrfs это не осознанное решение, а идиотизм, допущенный при выборе алгоритмической базы.

Кого угодно может не волновать что угодно. Ты же говорил о превосходстве конкретно btrfs над конкретно reiser4 (в обратной формулировке), что я и потрудился экспериментально опровергнуть для набора частных случаев. Дальше сраться не имеет смысла.

идиотизм, допущенный при выборе алгоритмической базы

Бида-пичаль. Сейчас же снесу её со своего компа и побегу накатывать Reiser4, ахаха. И пофигу, что она у меня отлично работает, ведь ИКСПЕРТЫ ГОВОРЯТ....

Ты же говорил о превосходстве конкретно btrfs над конкретно reiser4

Мда? Покажешь - где?

И это результаты с включенным, судя по логу, сжатием на btrfs. Любопытно. Без сжатия, в таком тесте,результаты будут гораздо хуже.

И это результаты с включенным, судя по логу, сжатием на btrfs. Любопытно. Без сжатия, в таком тесте,результаты будут гораздо хуже.

Это только разультаты создания файлов. А потом btrfs начнет дополнительно расползаться при перезаписях. Где-то я видел тест, где после многочисленных перезаписей сжатая btrfs занимает в несколько раз больше места, чем несжатая ext4 при том же сценарии.

ВЕДЬ ШИШКИН СКАЗАЛ

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

Я тут нашёл один наш проект, в нём 952037 файлов переменного размера от нескольких кб до мб и занимает это дело 587Гб. Попробую закинуть это дело на btrfs.

Сжатие там совершенно не играет, поскольку файлы — рандом. Кстати, оно включено на обеих ФС.

Про академическую правоту я уже высказался ранее по треду.

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

Идеального в реальном мире не существует.

http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg38049.html

Сама стабильность [2]

Надо валить на lvm + ext4 пока не поздно.

Вали -))

Надо валить на lvm + ext4 пока не поздно.

Если твои данные представляют хоть кукую то ценность, то btrfs однозначно не вариант. Пока это игрушка.

А не заполнять zvol больше 85% это нормально? Сколько будет 15% от 4ТБ ? Всего лишь 614Гб, мелочь. Ок, мне больше нечего сказать.

ну у pedobear'а вон на три четверти 2-гиговая бтрфска заполнилась только и ему уже диск стало жалко. Сколько будет 25% от 4ТБ? Мелочи какие :)

Значит, zfs тоже неэффективно использует дисковое пространство.

Из вброса sdio сделан далекоидущий вывод ни о чем. Поздравляю!

А не заполнять zvol больше 85% это нормально?

Во-первых, не zvol, а zpool, во-вторых, можешь смело заполнять, с данными ничего плохого не случится, только скорость упадёт.

Я специально, т. к. из его слов (если считать, что он ничего не умолчал) следует именно это.

А не заполнять zvol больше 85% это нормально? Сколько будет 15% от 4ТБ ? Всего лишь 614Гб, мелочь. Ок, мне больше нечего сказать.

Я надеюсь дома у тебя ни в одном шкафу и в холодильнике нет ни кубодециметра свободного места - все шкафы забиты под завязку.

Я надеюсь дома у тебя ни в одном шкафу и в холодильнике нет ни кубодециметра свободного места - все шкафы забиты под завязку.

Ну, под праздник так и получается. И что с того? Покупать два холодильника?

Использовать шкафы со сжатием.

Использовать шкафы со сжатием.

С дедупликацией.

Шкафы при заполнении не теряют своих качеств, в отличие от.

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

Не тупи с тупыми аналогиями.

Не тупи с тупыми аналогиями.

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

Шкафы при заполнении не теряют своих качеств, в отличие от.

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

IRL дедупликация и так есть, правда, на квантовом уровне -))

скорость доступа к данным действительно снижается

Ага, только причины ты не указал. ты описал снижение доступа из-за поиска файла в большой директории, а не из-за дикой фрагментации COW-fs.

Возвращаясь к вашей тупой аналогии: Взяв из шкафа из пачки бумаги листы, написав и вернув их в шкаф, не-COW-fs вернет их в пачку на свои места, а COW-fs всегда положит их на новое место. И когда эти листы будут разбросаны по всему шкафу, начинаются тормоза из-за seek'a по диску.

начинаются тормоза из-за seek'a по диску

Это справедливо только для хардов, которые, к счастью, медленно, но верно уходят в прошлое.