> Давайте спросим... меня!

Ох, разбудили облолодателя ынтырпрайзных конфигов :)

> REFER  MOUNTPOINT
> media   564G  6,91G    31K  /media

Вообще, 6G как бы довольно большой кус места, я думаю что Теодор имел в виду намного более клинические условия. В 6Гб аллокатору даже есть где потрепыхаться, хоть оптимальность принятых решений и будет существенно снижена.

> Так что же я вам скажу?

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

> На пуле media у меня файлопомойка и торренто-качалка без всяких RAID. Тупо:
> один раздел диска выделен под ZFS. Так вот, примерно с 98-99%
> заполненности пула (около 11 ГБ свободного пользовательского пространства) начинаются
> дикие тормоза с многопоточной записью и чтением файлов с этого пула.

Странно, iZEN сам сообщил нелестный факт о своей ФС. Не понимаю что за фигня. Он сегодня какой-то слишком честный.

> растянется надолго. Интересно то, что "клинит" только приложения, которые непосредственно
> работают с файлами из этого пула, а не те, которые вообще
> к нему никак не относятся.

А чего тут интересного? Программа запросила I/O. Запрос улетел в недра ядра. Ядро где-то в недрах отдало сие разруливать ФС и в итоге дисковой подистеме, которые раздуплятся как сумеют и не ранее того. Если это займет много времени - значит это займет много времени. В случае обычного блокирующего I/O программа будет висеть в вызове который должен непременно вернуть статус операции, ожидая завершения этой самой операции, пока ядро там раздупляется. Ядро просто не вернет управление программе пока не разрулит эту операцию, просто потому что продолжение выполнения зависит от этой операции. Если автор заранее не подумал о таком и использовал совсем олдскульные методы, это вполне может привести к клину интерфейса и отсутствию реакции на внешние раздражители. Если у проги был 1 поток и он намертво встрял в вызове, допустим, read(), программа не сможет больше ни на что реагировать пока read() не вернет нам результат. По этому поводу придумали асинхронное I/O, вынос тяжелых и медленных операций в отдельные треды, клин которых никому не создает проблем и прочая. Однако как ты понимаешь, просто вхреначить вызов чтения/записи не парясь последствиями - проще всего. А то что оно может на 100500 мс заклинить в этом месте если не повезет - упс. Не все это понимают, увы.

> То есть во время копирования можно спокойно пользоваться Firefox, Thunderbird
> и другими запущенными приложениями, а вот в Thunar приходится ждать секунд
> пять отрисовки его интерфейса на открытой папке пула.

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

> Курсор мыши не залипает.

Ты уже достал с курсором. Просвети, блин, что у тебя за комплексы? Ты постоянно вопишь что он у тебя "не залипает" как мантру. А должен залипать? Я вот даже вспомнить не могу чтобы у меня курсор залипал. Ну может в новых виндах (виста/семерка) при сильном своплении пару раз видел клины курсора, и то это надо систему в своп свалить (впрочем винды в него валятся охотно by design). На моем десктопе и ноуте с пингвином курсор катается идеально. Я вообще не знаю что надо сделать чтобы его заклинило. Ни одна из типичных активностей к такому точно не ведут.

>> ZFS, у которого странностей и неотвеченных вопросов на два btrfs хватит?
> Во всяком случае тебе никто не мешает ответить на все интересующие вопросы самому.

А тебе слабо?

> Код ZFS открыт.

Только он сцуко здоровый и сложный, поэтому я удовольствовался тем что посмотрел на общий дизайн, понял что половина решений взято с потолка + процент маркетингового булшита от саней в документации мне не по вкусу. Учтя что его никогда не будет в релизном виде в симпатичной мне системе + я искренне полагаю что из дизайна btrfs можно выжать больше, я попросту не испытываю сильного желания изучать каждый битик данных сырцов.

> Систем, реализующие возможности ZFS, две,

При том одна - проприетарная на весьма невкусных условиях, а вторая - реализует такой "продакшн", конечно, что все списки рассылки зафлужены кучей неочевидных грабель на которые стандартный ответ - "дай угадаю, у тебя ZFS?!". Пардон, продакшна с висючими сисколами, маркетингом вместо ответа на некоторые злободневные вопросы мне как-то не требуется, thank you very much, sir.

> а с  вкоряченным в ядро Linux кодом ZFS дистрибутивом — три или четыре!

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

> Кто мешает тебе, User294, взять и самому как следует рассмотреть со
> всеми крэш-тестами на выживание ФС, так сказать?

В основном соотношение объема работ vs результат от оного для меня любимого. Если ты хочешь посмотреть как я загоню zfs в полный ахтунг - да не вопрос, а какие плюшки мне за эту не нyжную персонально мне долботню мне за это обломятся? Никаких? Ну ой, так не интересно. Грубо прикинуть свойства дизайна и что для него будет откровенно (не)удобно я могу и просто посмотрев на дизайн и результаты различных бенчей, это достаточно тривиально и не требует много времени и подготовки кучи конфигураций. Улови мысль: чтобы я побежал клепать lab-like окружение и что-то там изучать, мне это должно быть зачем-то надо.

> zdb в руки и вперёд.

Ага. Вот ружье а вот патроны. Правда я не допираю на кого охотимся и почему я в этом должен принять участие.

> НЕИМОВЕРНАЯ БАРАНЬЯ УПЁРТОСТЬ!

Что-то тебя сегодня прямо на честность пробило. То ты признаешь что zfs тормозить умеет, то что ты уперт.