> Для ФС из прошлого века тоже кое-что сделали:

vmscan: Factor out page reference checks (help workloads with large amounts of shortly used file mappings, like rtorrent hashing a file or git when dealing with loose objects)

Только какое это отношение имеет к случайной записи мелкими кусками?

так что в каком-то смысле «фапает» тут именно *torrent-клиент.

Напишите свой - который будет писать строго последовательно, - и он нахер никому не будет нужен.

>Ни ты, ни твои познания не представляют для меня никакого интереса.

Куда уж мне до убунтубогов :D

Кстати, об "эпичном баге"

Хоть один нытик додумался покачать торренты в tmpfs, и посмотреть, не исчезнут ли тормоза при этом. Или только бесцельно ныть горазды?

чуточку притормаживало, но не стопорило систему.

72800+0 записей считано
72800+0 записей написано
скопировано 72800000000 байт (73 GB), 713,789 c, 102 MB/c

>а в кривых настройках swapiness, т. к. это единственный io, который может приводить к описываемым проблемам интерактивности.

ага, это при том, что swap отключен ;D

>а почему железка должна задрачиваться на записи?

Потому что: 1) чьи-то шальные ручки могут ызывать fsync; 2) чьи-то кривые ручки могут подкрутить sysctl, урезающий buffers (кеш записи)

а кэш может писаться последовательно - только в метаданных указывается какой кусок файла где положен.

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

>dd if=/dev/zero of=~/file bs=1000000 с noop и при опции sync СОВЕРШЕННО не подвешивает комп!!!

ага, т.к. источник данных - ram(условно), число write-запросов аж 1 =)

> в кривых настройках swapiness, т. к. это единственный io, который может приводить к описываемым проблемам интерактивности.

Да нету у меня свопа, нету! Нахрен он нужен на не слишком нагруженном компе с 8гб?)

>Может причина не в запросах к диску, а в кривых настройках swapiness, т. к. это единственный io, который может приводить к описываемым проблемам интерактивности.

проверил. дело не только в нём.

Вот был бы своп - так проблема решилась бы настройкой swapiness инфа 100%, а так - мучайся =)

про это, да, забывать не стоит. а то может порвать диск на части ))

> Вот был бы своп - так проблема решилась бы настройкой swapiness инфа 100%, а так - мучайся =)

Типа «нет проблем? Давайте их создадим и героически решим!»?

> 2) чьи-то кривые ручки могут подкрутить sysctl, урезающий buffers (кеш записи)

вот это да, нужно править.

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

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

>> Squashfs

Add support for lzma and lzo compression

Ну наконец-то, теперь не придётся патчить ваниль..

Придется. Там всего лишь добавлена инфраструктура для их поддержки. Сами они отсутствуют. Так что это дезинформация.

Не, это типа как в анекдоте про козу :)

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

Да-да. :) Только это притча библейская.

>для десктопа фрагментация не так страшна, как для сервера

Не скажи. Сильно фрагментированный файл будет выдавать на линейном чтении скорость 1-3 MB/s. Оно тебе надо? Да и распухание числа инодов не может положительно отразиться на производительности.

> Фрагментации, к которой ты призываешь, лучше избегать.

Поэтому лучше фапать диск до изнеможения, пожирая ценные IOPs'ы и не давая никому более работать?

Кто мешает от этой самой фрагментации избавиться пост-фактум? Да и при больших размерах блоков эффект от фрагментации гораздо менее заметен, чем при мелких (8К и менее).

> Да и распухание числа инодов не может положительно отразиться на производительности.

Один файл - один инод, вне зависимости от фрагментации. Или ты о чем-то другом?

> потому что баг внезапен и рабочего пока фикса не существует

Этот «внезапный» баг возник ещё в 2.1 и с тех пор не вылечен.

Я уже высказывал предположение, правда немного с другой стороны: kernel-девелоперы в большинстве своём я думаю не бедные люди, позволить себе купить десктопную железяку, чтобы воспроизвести баг в своём детище вполне могут, другое дело - что не могут воспроизвести/исправить, или не хотят по неизвестным причинам

>Я все свои машины посекторно шифрую.

mount -o sync
?

>Да и при больших размерах блоков эффект от фрагментации гораздо менее заметен, чем при мелких

Потери емкости сам посчитаешь?

Дык баг воспроизводится на самом топовом железе. Что может быть на десктопе топовее, чем i7 на x58?!

Нет, зачем? Всюду ноуты либо хорошие ИБП.

>dd if=/dev/zero of=~/file bs=1000000 с noop и при опции sync СОВЕРШЕННО не подвешивает комп!!!

ага, т.к. источник данных - ram(условно), число write-запросов аж 1 =)

а вот и нифига! )
поставил в два потока - тоже всё гуд. поставил в три потока - нет подвисаний и всё тут!
скорость, конечно, разделилась. жесткий еле слышно шумел, как и при одном потоке.

> Потери емкости сам посчитаешь?

Не актуально уже давно.

>>Да и при больших размерах блоков эффект от фрагментации гораздо менее заметен, чем при мелких

Потери емкости сам посчитаешь?

Какие нах потери емкости, если речь идет о торрентах? Да и винты нынче не по 20МБ. Или вы какие-то особенные торренты качаете, из мириад 20-байтных файлов состоящие?

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

Но... ты понимаешь сам, что вероятность одновременности этих двух операций в обычной жизни вообще нулевая.

У меня этот баг проявляется только в одном случае: если я пользуюсь встроенным в лаптоп кардриддером. Копирование любого файла >~ 100Mb делает иксы неюзабельными (а так как я скидываю через него свои фотки/видео с камеры, то этот баг бесит меня страшно). Зависит от железа.

>притормаживает - это мягко сказано -))

гуй намертво повисает

У меня в фоне компиляция + запустил вашу «dd if=/dev/zero of=~/file bs=1000000», отзывчивасть упала, но ничего намертво не повисает, только фризы раз в 10 секунд на полсекунды

> фризы раз в 10 секунд на полсекунды

Ты считаешь это нормальным? У меня примерно так же, если не на всю грузить. Т.е. кино смотреть даже можно, не дергается, но если попытаться переключиться на другое окно, словишь фриз секунд на 5-10.

> С таким же успехом «можно смело игнорировать» любые баги.

Ты передо мной права качать надумал что ли? 12309 — не один баг. Если ты никогда не был в шкуре разработчика, тебе не понять, что такое левые репорты, которые засоряют эфир, но к твоему конкретному багу отношения не имеют. Чтобы баг фиксить, надо сначала его идентифицировать, найти «кто виноват», и кто будет чинить. А там просто нытик-тред какой-то.

> Ты передо мной права качать надумал что ли?

А ты чем-то отличаешься от остальных? Кровь голубая, пенис 50см?

Если ты никогда не был в шкуре разработчика

Был.

Чтобы баг фиксить, надо сначала его идентифицировать, найти «кто виноват»

Пусть ищут. Там болта положили.

А там просто нытик-тред какой-то

Что накодили, то и фиксить надо. Понятно, что FOSS и всем пофиг чуть более, чем полностью, но тем не менее.

>Да и при больших размерах блоков эффект от фрагментации гораздо менее заметен, чем при мелких (8К и менее).

И много ты видел фс, созданных с размером кластера больше 4kb?

>Ты считаешь это нормальным?

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

> Сейчас только проявляется, если писать на жесткий непрерывным потоком

Ага, есть такое. Мне вот пару раз в неделю большие объемы гонять надо, так уже этот 12309 достал...

> И много ты видел фс, созданных с размером кластера больше 4kb?

В бытность фат32 мейнстримом знающие делали кластер 16к, достигая таким образом тысячи профита, ибо процессоры были намного слабее.

>Один файл - один инод, вне зависимости от фрагментации. Или ты о чем-то другом?

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

>И много ты видел фс, созданных с размером кластера больше 4kb?

ну толсто же, в смысле - FAT =)

>> Сейчас только проявляется, если писать на жесткий непрерывным потоком, что в повседневности я не делаю

а народ делает

>> Да и при больших размерах блоков эффект от фрагментации гораздо менее заметен, чем при мелких (8К и менее).

И много ты видел фс, созданных с размером кластера больше 4kb?

Вендузятник детектед! А еще на бздунов пальцем показывают...

У меня везде, кроме свопа, recordsize по умолчанию - 128К. Все что меньше 128К - занимает ровно столько секторов, сколько требуется, то есть если файл 2,5К или 86,5К- то он и занимает 2,5К или 86,5К.

> Вендузятник детектед!

Какой молодой ононимус. Тут же каждый тролль знает, что linuxfan вендузятник :)

>>Один файл - один инод, вне зависимости от фрагментации. Или ты о чем-то другом?

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

В файловой системе, использующей блоки, размер необходимых метаданных не зависит от расположения блоков, только от их количества (если, конечно, не используются какие-нибудь фокусы типа сжатия метаданных, исключения пустых блоков и т.п.). Вот в системе, использующей экстенты, размер метаданных может существенно отличаться - на непрерывный файл нужен один экстент, на файл из херовой уймы кусков - херова уйма экстентов.

>а народ делает

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

>> Вендузятник детектед!

Какой молодой ононимус. Тут же каждый тролль знает, что linuxfan вендузятник :)

Вот еще, всякую херню помнить :-)

В этой версии ядра добавлены:

- Дравйвера индусских видеокарт.

- и еще 100500 строчек ненужного кода.

>У меня везде, кроме свопа, recordsize по умолчанию - 128К. Все что меньше 128К - занимает ровно столько секторов, сколько требуется, то есть если файл 2,5К или 86,5К- то он и занимает 2,5К или 86,5К.

и каким образом такого добился? что за фс?

> и каким образом такого добился? что за фс?

MetanFS Gazprom Edition

> А ты чем-то отличаешься от остальных?

Конечно.

Кровь голубая, пенис 50см?

Нет, у меня в других местах отличия.

Пусть ищут. Там болта положили.

INSUFFICIENT DATA. Я так понимаю, что многим пользователям даже не хочется, чтобы его пофиксили, они тогда не смогут себя представлять в роли жертвы этого бага.