Ищу алгоритм дефрагментации

Какая файловая система, если не секрет?

i-rinatFs, видимо ;))

Какая файловая система, если не секрет?

reiserfs 3.6

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

зачем это делается

Хочу дефрагментатор, а никто не пишет. ФС хорошо работает, когда новая, но довольно быстро «стареет».

как это будет реализовано

# reiserfs_defrag /dev/vgroup/reiserfs_partition

На отмонтированном разделе, конечно. Если offline я ещё представляю как делать, то online — слишком сложно. Хотя были мысли типа «сделать ioctl как в винде и добавить поддержку в wine». Тогда можно было бы просто запускать готовые win-дефрагментаторы.

Под венды есть дефрагментатор MyDefrag, у него порядок дефрагментации задаётся скриптом, посмоти на скрипты идущие вместе с ним.

Под венды есть дефрагментатор MyDefrag

Спасибо за наводку, нашёл его предка, JkDefrag, у него доступны исходники. В скриптах MyDefrag уровень абстракции слишком высокий.

Вообще я нагуглил UltraDefrag (и теперь JkDefrag) — у них открытый код. Но тщательного раскуривания их кода как раз и хотелось избежать. Восстанавливать алгоритм по коду — неблагодарное занятие :( , но этим, похоже, и придётся заниматься.

для ssd дефрагментатор почти бесполезен - стоит ли писать ?

для ssd дефрагментатор почти бесполезен - стоит ли писать

у меня нет ssd

скоро будет )

скоро будет )

первый запрос в гугл по словам «ssd random read performance» дал вот эти интересные картинки:

случайное чтение 4k блоками

последовательное чтение 128k блоками.

Суть: intel ssd 510 в 8,5 раз медленнее на случайном чтении, чем на последовательном. Для других лень считать, но они тоже нехило проседают.

А так наверное ты прав, если бы это действительно нужно было, уже написали бы.

не совсем верное сравнение: рандом шел на 4к, а последовательное на 128к
вот тут http://www.setupc.ru/wiki/moin.cgi/ssd_test_x25m интересные графики можно поглядеть: на 128к имеем максимум быстродействия

Если есть лишнее место, то затарить-отформатировать-растарить быстрее и надежнее любого дефрагментатора.

ok, разница в последовательном чтении — в 2,2 раза. Остаётся примерно 4 вместо 8,5.

быстрее и надежнее любого дефрагментатора

хорошо, я же не настаиваю. А по теме есть мысли какие-нибудь?

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

Лучшее, до чего я смог додуматься — использовать что-то вроде A*, а в качестве эвристики использовать сумму числа фрагментов, например. Но мне придётся хранить довольно много состояний, во много раз больше, чем информация о структуре всей ФС. В итоге затраты памяти будут огромные. И в довесок может оказаться, что конечная цель недоступна вовсе и я пройдусь по всем состояниям.

Думаю, что это очень непростая задача, и эвристики с упрощениями неизбежны ввиду огромных данных. На глобальном уровне A* вряд ли подойдет - все же перебор. А методы разные бывают. Еще можно через расширенный лагранжиан [1] пытаться решать некоторые задачи, но детали уже забыл за десять с лишним лет неиспользования :)

А как поступают создатели других файловых систем? Не интересовались? Да в той же ext4. Думаю, они поделятся :) А что если написать к ним в рассылку?

[1] Студентом я изучал по книге французского автора Мину «Математическоке программирование».

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

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

А как поступают создатели других файловых систем? Не интересовались? Да в той же ext4.

Интересовался. В ext4 дефрагментация делается так: создаётся донор (файл), удаляется, затем под него выделяется место равное размеру дефрагментируемого файла. Если число экстентов получилось меньше, то делается ioctl, который меняет копирует данные и меняет экстенты у файла и донора. Затем донор закрывается. Плюсы в том, что метод работает на подмонтированной системе и использует уже реализованные внутри ФС алгоритмы размещения файлов. Минус в том, что никто не знает, куда будет передвинут файл. Если вдруг случится, что в некотором месте файлы размером в блок разбросаны по диску и фрагментируют свободное место, e4defrag не будет их двигать.

xfs и btrfs жутковаты по размерам кода, туда не совался.

Доделал перемещение неформатированных блоков, решил нарисовать Tux'а:

http://img801.imageshack.us/img801/8654/tuxonizerprealpha.png

Реализация тут: Пишу оффлайн дефрагментатор reiserfs

ФС хорошо работает, когда новая, но довольно быстро «стареет».

может будем лечить болезнь, а не симптомы? а то мне reiser этим тоже не нравится. А дефрагментатор это паллиатив. (или raiser фрагментируется by design, как ntfs?)

может будем лечить болезнь, а не симптомы?

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

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

Насколько я понимаю, фрагментация неизбежна.

это твоя ошибка. фрагментацию можно избежать. Если у тебя нет дырки в 1Гб, но есть две дырки в 500Мб, то что мешает слить эти дырки, и пусть весь мир подождёт?! Что мешает сливать дырки не ВНЕЗАПНО, а заблаговременно? Что мешает оставлять как можно большие дырки? Да ничего не мешает, кроме ВРЕМЕНИ И ПАМЯТИ. Твой дефрагментатор == костыль, который как раз и укрупняет дырки и непрерывные файлы (т.е. тоже дырки, в которых лежат эти файлы). В уважающей себя ФС дефрагментатор встроен, и этот встроенный дефрагментатор как раз и достигает компромисса между скоростью записи и роста файлов и процентом фрагментированных дырок (как пустых, так и заполненных).

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

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

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

Очень просто, есть два крайних случая:

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

2. можно писать файлы так, что-бы дыры (в том числе и с файлами) были минимально фрагментированы. Понятно, что скорость записи упадёт ниже плинтуса, причём довольно быстро. Любопытно, что это НЕ лучший случай скорости чтения - ага, скорость чтения ОДНОГО файла максимальная, но во первых мы читаем сразу много файлов, во вторых файлы разбросаны по всему диску, даже те, которые были только-что записаны (именно они и определяют скорость по большей части). На самом деле, такие ФС тоже есть, это ISO9660 например, в неё фактически можно только добавлять, потому фрагментация равна нулю.

Очевидно компромисс где-то посередине. Также вполне очевидно, что дефрагментатор тоже должен совсем не добиваться фрагментации 0, а устанавливать её в определённое значение. Ну и кроме того группировать файлы по времени доступа (ненужные в задницу, нужные под рукой).

фрагментацию можно избежать. Если у тебя нет дырки в 1Гб, но есть две дырки в 500Мб, то что мешает слить эти дырки

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

Твой дефрагментатор == костыль, который как раз и укрупняет дырки и непрерывные файлы

Я что, принуждаю? Изредка всплывающая тема в трекере это слишком агрессивная реклама?

можно писать файлы так, что-бы дыры (в том числе и с файлами) были минимально фрагментированы

Вообще-то так ntfs и поступает, по моим наблюдениям. Это ведёт к жуткой фрагментации. Чтобы минимизировать фрагментацию дыры, файл надо писать в самом её начале. То есть алгоритм таков: используй первый пустой блок.

Также вполне очевидно, что дефрагментатор тоже должен совсем не добиваться фрагментации 0, а устанавливать её в определённое значение.

Я много думал над метрикой фрагментации. Это не такой простой вопрос, как кажется на первый взгляд. Додумал до метрики «минимальная скорость чтения файла с диска/максимальная достижимая скорость», но она зависит от множества параметров, например, от скорости диска.

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

Часто слышу байку о том, что, мол, полная дефрагментация не нужна и даже вредна. Но почему-то те, кто её вещает, забывают о read-ahead.

Допустим, есть два файла по 10 блоков. Итого 20 блоков. Время чтения будет определяться перемещениями головки. Допустим, это 20 мс. Если файлы разбросаны по диску, то время чтения двух файлов параллельно по одному блоку за раз составит 20*20=400 мс. А если они дефрагментированы, то первое чтение первого файла приведёт к чтению файла целиком (типичные значения readahead: 128 кб). Второй файл тоже будет прочитан разом. Итого время составит всего 40 мс.

В уважающей себя ФС дефрагментатор встроен

Можно список уважающих себя ФС?

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

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

Я много думал над метрикой фрагментации. Это не такой простой вопрос, как кажется на первый взгляд. Додумал до метрики «минимальная скорость чтения файла с диска/максимальная достижимая скорость», но она зависит от множества параметров, например, от скорости диска.

Я много думал

не ты первый. В середине прошлого века куча народу голову сломала.

То есть алгоритм таков: используй первый пустой блок.

называется «первый подходящий». Профессор Дональд Кнут уже всё проверил. И свои рассуждения подкрепил непробиваемым матаном. Купи себе его книжку, и прочитай($20 или на рутреккере бесплатно). Потом поговорим. Впрочем, ты можешь сам думать о том, что уже 50 лет назад уже разложено по косточкам.

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

я вот тоже не знаю, какая будет температура 1го декабря. даже не предполагаю. Наверное 43 в тени (:

называется «первый подходящий». Профессор Дональд Кнут уже всё проверил

Подмена понятий. Из твоих слов «минимизировать фрагментацию свободного пространства» напрямую следует «писать в первый попавшийся блок». Это наиболее простое решение, удовлетворяющее условиям задачи. Buddy allocation — это уже продвинутый вариант, решающий проблемы, которые ты даже не упомянул. И знаешь что самое интересное? Я использую модификацию этого алгоритма, работающую не только со степенями двойки :) Использовать только степени двойки нельзя, потому как пользователи расстраиваются, когда их гигабайтный раздел может вместить только 500 мегабайт.

Купи себе его книжку, и прочитай

Спасибо, совет полезный. Всё никак не решусь взяться :)

Потом поговорим.

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

Незачем говорить о пространном, когда уже есть реализация. Скачай код, посмотри, я из него секрета не делаю. И уже с указанием конкретных мест говори: «вот тут твой код говно, потому что ...». Часть про «потому что» — обязательна. Если говоришь про производительность, укажи алгоритм, который даст хотя бы 1% прироста скорости. Я надеюсь, я найду в себе силы признать свою неправоту.

я вот тоже не знаю, какая будет температура 1го декабря. даже не предполагаю. Наверное 43 в тени (:

Чего паясничаешь? Серьёзный вопрос же.

Пользователь записал файл. Длина — 4к. И так ещё с десяток файлов. Вопрос: можно ли занимать место сразу после первого, или нужно зарезервировать место под увеличение? Или стоило их впихнуть все рядом?

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

Допустим, нет, и нужно все файлы упаковать рядом. А они оказались затравками для логов в /var/log. И будут расти. Алгоритм отстойный, он увеличил фрагментацию файлов зазря.

Если проводить аналогии с погодой, то тут скорее подойдёт не температура, а направление ветра. Куда будет дуть ветер первого декабря? С какой скоростью?

И мне парочку давай.

одеть зимнюю куртку

Зачем ее одевать? Ей холодно?

Подмена понятий. Из твоих слов «минимизировать фрагментацию свободного пространства» напрямую следует «писать в первый попавшийся блок». Это наиболее простое решение, удовлетворяющее условиям задачи. Buddy allocation — это уже продвинутый вариант, решающий проблемы, которые ты даже не упомянул. И знаешь что самое интересное? Я использую модификацию этого алгоритма, работающую не только со степенями двойки :) Использовать только степени двойки нельзя, потому как пользователи расстраиваются, когда их гигабайтный раздел может вместить только 500 мегабайт.

вообще-то ничего такого из моих слов НЕ следует. особенно buddy memory allocation. Особенно со степенями именно двойки. В том алгоритме ценность в том, что адрес близнеца очень просто вычисляется, если это непрерывный кусок скажем памяти со сквозной адресацией. Причём тут ФС лично мне вообще неясно.

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

может перед изготовлением велосипеда есть смысл глянуть, КАК устроены чужие? Не? Потратить пару часов своей драгоценной жизни, на чтение книги «искусство велосипедостроения»... Не, я понимаю, что твой велосипед с карданным валом уже едет, но может не ты первый? Может давно уже так не делают? Может даже в книжке рассказано ПОЧЕМУ так?

Если говоришь про производительность, укажи алгоритм, который даст хотя бы 1% прироста скорости.

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

Чего паясничаешь? Серьёзный вопрос же.

ответ тоже серьёзен. Если у тебя есть конкретный сервер, то ты знаешь КАКИЕ там файлы, СКОЛЬКО их, КАК огни создаются/удаляются/читаются. Если тебе интересна статистика, поменяй и/или погугли. Я вот 37й год живу в этом городе, и потому точно знаю математическое ожидание и разброс температуры _здесь_ в начале декабря. 43х в тени точно не будет. Скорее -8. +-10 градусов. Этой точности для меня вполне достаточно. Если-бы я выращивал какую-то траву, знал-бы точнее, что-бы посеять и собрать вовремя. (:

Пользователь записал файл. Длина — 4к. И так ещё с десяток файлов. Вопрос: можно ли занимать место сразу после первого, или нужно зарезервировать место под увеличение? Или стоило их впихнуть все рядом?

EXT3/4 резервирует ЕМНИП 8 свободных блоков (обычно 8*4К) после файла. ИМХО это хорошая эвристика. Что касается уже растущих файлов, то видно надо собирать статистику, дабы отличить растущие от нерастущих файлов. можно хранить не только время модификации, но и время добавления. Или просто считать, что если файл часто меняется(и/или недавно) - он растущий. Для этого хватит стандартных атрибутов. Среди атрибутов кстати есть т.н. время удаления - полезно его тоже использовать что-бы стирать по возможности недавно удалённые, горячие файлы. ФС это не память, у нас есть куча нужных атрибутов.

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

именно потому, у меня корень на несколько гигов, и там почти ничего нет (/etc/ /root/ /bin/ /sbin/ /boot/ /lib/ и всё вроде)

Допустим, нет, и нужно все файлы упаковать рядом. А они оказались затравками для логов в /var/log. И будут расти. Алгоритм отстойный, он увеличил фрагментацию файлов зазря.

именно потому у меня /var отдельно. И /tmp тоже.

Если проводить аналогии с погодой, то тут скорее подойдёт не температура, а направление ветра. Куда будет дуть ветер первого декабря? С какой скоростью?

у метеорологов есть такая штука, «роза ветров».

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

(это цитата из вики)

размазать размазал, а собрать не можешь? Довольно таки странно видеть тему «ищу алгоритм...» после темы «пишу программу....»

Я могу полезть на мейл ру. В кеше браузера начнут плодиться сотни мелких файликов - цссок, жаваскриптиков, картинок и тд. Я могу почувствовать, что сегодня самое время посмотреть три серии my little pony в 1080p. Это 3 файла по гигу. Еще я возможно захочу поработать дома, мне надо будет развернуть рабочее окружение, это несколько сотен или тысяч мелких jar-файлов, пара образов по десятку гигабайтов и бог знает что там будет делать постгрес при импорте тестовой базы. Есть и торренты (рядом лежат блюрей рипы по 50 гигабайтов, музыкальные сборники — десятки тысяч файлов по 3–30 мегабайтов, какой-нибудь клон либ.ру - сотни тысяч архивов по десятку килобайтов на штуку). Это абсолютно обычный юз-кейс. Как тут можно что то предугадывать?

Причём тут ФС лично мне вообще неясно.

И я тоже запутался уже. Я понял твои слова определённым образом, но ошибся. Чувствую, мне этот вопрос не понять.

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

Я хочу определить свою позицию ещё раз. Я не получаю зарплату за программу и не продаю её. Если тебе она не нужна — не используй, тебя никто не может заставить. Но она нужна мне, хотя бы чтобы почесать Чувство Собственной Важности. Я не собираюсь врываться тебе домой и ставить программу у тебя.

ответ тоже серьёзен. Если у тебя есть конкретный сервер, то ты знаешь КАКИЕ там файлы, СКОЛЬКО их, КАК огни создаются/удаляются/читаются.

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

видно надо собирать статистику, дабы отличить растущие от нерастущих файлов

Я не пишу ФС и не знаю, как и, самое главное, зачем это мне делать.

Это абсолютно обычный юз-кейс. Как тут можно что то предугадывать?

1. вынеси кеш браузера в /tmp

2. сделай специальный раздел для фильмов

3. недоделанные файлы p2p я например держу в /var, а доделанные раскидываются по категориям (в частности фильмы к фильмам)

УМВР, причём много лет. «дефрагментация» у меня случается при смерти какого-нибудь винчестера.

именно потому, у меня корень на несколько гигов, и там почти ничего нет. именно потому у меня /var отдельно. И /tmp тоже.

Если я не ошибаюсь, ты говорил, что ФС должна решать эти проблемы. Вывод /var и /tmp в отдельные разделы — это общепринятые костыли. Они настолько распространены, что большинство считает их чем-то самим собой разумеющимся. Но это костыли. А это значит, ни одна из существующих ФС эти проблемы не решает. Ну и ладно, я не потяну это всё равно.

у метеорологов есть такая штука, «роза ветров».

Роза ветров даёт статистику, но не позволяет предсказать.

Довольно таки странно видеть тему «ищу алгоритм...» после темы «пишу программу....»

Тема «Ищу алгоритм дефрагментации» датируется 26 марта 2012 года. Тема «Пишу дефрагментатор reiserfs» датируется 7 сентября 2012 года, то есть спустя пять месяцев. Так что с последовательностью всё в порядке :)

может перед изготовлением велосипеда есть смысл глянуть, КАК устроены чужие? Не? Потратить пару часов своей драгоценной жизни, на чтение книги «искусство велосипедостроения»... Не, я понимаю, что твой велосипед с карданным валом уже едет, но может не ты первый? Может давно уже так не делают? Может даже в книжке рассказано ПОЧЕМУ так?

Я почти год думал перед тем как начать. Вот, почти за год до начала. Глазел в ext4 и btrfs.

но может не ты первый? Может давно уже так не делают? Может даже в книжке рассказано ПОЧЕМУ так?

Слишком пространно. Я прочитаю книгу целиком, а не частями, правда. А ещё я буду признателен тебе, если увижу ссылку на алгоритм. Подойдёт любое название, лишь бы по названию можно было его нагуглить.

Понял, виноват.

слишком высокий уровень абстракций. Я его уже не понимаю. Не понимаю, что значит «знаешь, какие там файлы».

хм... т.е. ты не понимаешь почему заболела ФС, ты не желаешь её изучать, тебе не интересны труды великих докторов, но супер-таблетку ты уже сделал. И она уже кого-то лечит. Обычно, правда, калечит, но это мелочь... Болезнь роста. Так?

Я не пишу ФС и не знаю, как и, самое главное, зачем это мне делать.

ФС устойчивая к фрагментации в каких-то ОПРЕДЕЛЁННЫХ случаях нужна. Дефрагментатор не нужен, и я уже объяснял - почему. Пиши конечно, я не против. Выпаривая собственную мочу, философский камень не получишь, но фосфор открыть можно... Проверено.

Если я не ошибаюсь, ты говорил, что ФС должна решать эти проблемы. Вывод /var и /tmp в отдельные разделы — это общепринятые костыли. Они настолько распространены, что большинство считает их чем-то самим собой разумеющимся. Но это костыли. А это значит, ни одна из существующих ФС эти проблемы не решает

в общем случае не решает. В частных - более-менее удовлетворительно. Хотелось-бы лучше.

Роза ветров даёт статистику, но не позволяет предсказать.

зачем мне предсказывать? Роза ветров позволит построить дом так, что-бы он простоял Over9000 лет. Статистика доступа позволит ФС продержаться дольше, чем живёт диск. Большего и не нужно. Если ФС изредка ошибается, это чуть замедлит доступ к некоторым файлам. Не велика беда.

т.е. ты не понимаешь почему заболела ФС, ты не желаешь её изучать, тебе не интересны труды великих докторов, но супер-таблетку ты уже сделал.

http://www.joelonsoftware.com/articles/fog0000000018.html

И она уже кого-то лечит. Обычно, правда, калечит, но это мелочь...

«Make It Work Make It Right Make It Fast»

Болезнь роста. Так?

Не могу знать. Это только со стороны видно.

ФС устойчивая к фрагментации в каких-то ОПРЕДЕЛЁННЫХ случаях нужна.

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

ты не желаешь её изучать

Изучать что, ФС вообще? Как устроена конкретно reiserfs я себе вполне неплохо представляю.

зачем мне предсказывать? Роза ветров позволит построить дом так, что-бы он простоял Over9000 лет. Статистика доступа позволит ФС продержаться дольше, чем живёт диск. Большего и не нужно. Если ФС изредка ошибается, это чуть замедлит доступ к некоторым файлам. Не велика беда.

Я уже слышал это. «You don't need to defragment Linux filesystems. Not ext3, not ReiserFS. Defragmentation is only a conce». Но постойте, а почему это мой 300-метровый файл читается две с половиной минуты вместо семи секунд? И хруст аж слыхать. Нет, это не может быть фрагментацией, её же не существует.

Выпаривая собственную мочу

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

Ты хочешь, чтобы я воплотил твою мечту об идеальной ФС? Я при всём желании не смогу.

немного не так ты меня понял - идеальной ФС не может быть. Это для меня очевидно. Однако, возможна ФС, которая умеет выполнять задачи хранилища для почты на почтовом сервере. Или возможна идеальная ФС для хранения фильмов в фильмотеке. Ну или ФС хранящая 100500 файлов с исходными текстами ПО и локальное хранилище DVCS туда-же. Было-бы круто, если-бы это была одна настраиваемая ФС.

Изучать что, ФС вообще?

для начала просто распределения памяти (не обязательно именно RAM, а вообще, в принципе. HDD это тоже память, там те же принципы, но со своими тараканами. Кстати от тараканов HDD мы скоро избавимся, получив тараканы SSD)

Я не хочу хвататься за задачу только для того, чтобы её бросить.

делать дефрагментатор == биться головой об стену. Есть всего два варианта:

1. онлайновый дефрагментатор, работающий параллельно ФС - эффектность его очевидно близка к 0. А если даже и не так, то логично его вставить в саму ФС в виде патча - если нет работы, пусть дефрагментирует, если работа есть, но не срочная - пусть дефрагментирует одновременно с записью.

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

почему-бы не сразу бросить?

Я уже слышал это. «You don't need to defragment Linux filesystems. Not ext3, not ReiserFS. Defragmentation is only a conce». Но постойте, а почему это мой 300-метровый файл читается две с половиной минуты вместо семи секунд? И хруст аж слыхать. Нет, это не может быть фрагментацией, её же не существует.

при правильном использовании EXT3, фрагментация действительно если и есть, то она не влияет на скорость. Очевидно твоё использование НЕ правильное. Т.е. твоя «роза ветров» не соответствует той, которая была в голове Ганса или там разрабов EXT3.

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

У нас не венда, которая упорно пихает ВСЁ на диск C: У нас есть все возможности для разделения файлов. Почему-бы их не использовать? Системные файлы УЖЕ разделены, мы также в состоянии разделить и пользовательские так, что-бы они сами группировались так, как оно нам нужно, для увеличения производительности. Что в этом плохого? Юзкейс «ставить ВСЁ на один раздел» разве является обычным даже для Windows95? Нет, так делают только совсем уж бегинеры.

И да, почему «вручную»? Я разве предлагаю ручками что-то там сортировать?

для начала просто распределения памяти

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

логично его вставить в саму ФС в виде патча - если нет работы, пусть дефрагментирует, если работа есть, но не срочная - пусть дефрагментирует одновременно с записью.

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

очевидно и то, что восстановление из бекапа на чистый раздел быстрее и эффективнее.

Кому очевидно? Мне вот совсем не очевидно.

почему-бы не сразу бросить?

Тут я написал два абзаца гневного ответа, но вся их суть сводится к: «Нет».