О скорости работы с файловой системой

Удивительно, как каких операциях btrfs вообще может быть быстрой?

я считаю норм поставщик.

Если на более быстром диске например.

Если вы считаете, что быстрее, обоснуйте ответ, пожалуйста.

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

Ну и не факт, что btrfs вообще быстрее, а не диск на котором тестировалось.

Ты хочешь чтобы мы на кофейной гуще за тебя погадали? Алсо, как ты видишь работу журнала и fsync при таком сценарии?

Ты хочешь чтобы мы на кофейной гуще за тебя погадали?

Ну может специалист по файловым системам, разбирающийся в их устройстве, придёт и ответит.

Даже если и придёт - ничего он не сможет сказать по таким вводным данным.

Экспериментально установлено, что на ext4 она работает заметно медленнее, чем на btrfs.

Скорее всего, это из-за того, что btrfs - cow. Если она копирует файлы, то физически она их копирует только при внесении изменений в одну из копий, и то, наверное, только определённые поменявшиеся куски. Больше в бтрфс скорости браться, вроде, неоткуда.

Ну ещё вариант, что в бтрфс выставлено какое-то более агрессивное кэширование. В таком случае можешь поиграться с барьерами и кэшами для ext4, привести их в тот же вид.

если создать на ext4 большой файл (сотни гигабайт), смонтировать его как диск, отформатировать в btrfs и писать файлы на него, будет быстрее, чем непосредственно на ext4, или медленнее?

Тут покажут правду только замеры. А вообще, зачем создавать файл на ext4? Уменьши её, раз место есть. Создай ещё один раздел из освобождённого пространства, а на нём уже создавай бтрфс.

Даже если и придёт - ничего он не сможет сказать по таким вводным данным.

Ну на этот вопрос я думаю он должен знать однозначный ответ: „если создать на ext4 большой файл (сотни гигабайт), смонтировать его как диск, отформатировать в btrfs и писать файлы на него, будет быстрее, чем непосредственно на ext4, или медленнее?”
(при условии что btrfs действительно быстрее)

Если ничего не путаю, то работа со смонтированным файлом идет минуя слой абстракции ФС где он лежит

Путаешь. loop devices работают ПОВЕРХ ФС и журналирование на них вполне себе распространяется. Другое дело что за счет всякого кэширования некоторые вещи могут быть быстрее.

Вопрос: если создать на ext4 большой файл (сотни гигабайт), смонтировать его как диск, отформатировать в btrfs и писать файлы на него, будет быстрее, чем непосредственно на ext4, или медленнее?

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

Скорее всего, это из-за того, что btrfs - cow

Ее явно надо просить использовать COW, иначе все грустно.

Ее явно надо просить использовать COW, иначе все грустно.

В смысле? Там же наоборот, есть опция монтирования nocow. А cow по-дефолту. Я что-то путаю?

Скорость ext4 сильно деградирует при увеличении фрагментации

Дефраг возвращал скорость?

Скорость отличалась в разы.

Это ты обновлением арча проверял?

Когда копируешь файл надо указывать флаг --reflink, иначе он будет скопирован без cow

если создать на ext4 большой файл (сотни гигабайт), смонтировать его как диск, отформатировать в btrfs и писать файлы на него, будет быстрее

да. будет быстрее. точно так же, как быстро со скоростью света записываются файлы на usb-флешку. только когда начнёшь делать sync/umount придётся подождать.

Создавал фаил, форматировал его в 3й резер

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

Дефраг возвращал скорость?

Это было несколько лет назад. ЕМНИП то дефраг возвращал скорость лишь отчасти.

Это ты обновлением арча проверял?

Поиск по базе пакетов, pacman -Qs или -Ss.

Цифры не точные(из головы), просто чтобы понять разницу. Поиск по базе на фрагметированном(за несколько лет) разделе ~ 25-30 сек. После дефрагментации ~ 10-12 сек. На смонтированом файле с райзером и на свеже отформатированном разделе с екст4 ~ 1-2 сек.

но с новыми ядрями у рейзерфс начались проблемы

По этой причине я и отказался от рейзера на этом контейнере в пользу екст3. После перевода раздела /var на btrfs эти проблемы стали неактуальными.

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

Да, долго пользовался этим подходом, пока что-то не поломали и оно стало периодически под нагрузкой мгновенно намертво ядро вешать.

…

Сейчас ext4 как legacy, а новые разделы все в xfs.

новые разделы все в xfs

И как оно с мелкими файлами сейчас работает?

Когда-то на xfs это было ужасно медленно.

https://bbs.archlinux.org/viewtopic.php?id=16464

если создать на ext4 большой файл (сотни гигабайт), смонтировать его как диск, отформатировать в btrfs и писать файлы на него, будет быстрее, чем непосредственно на ext4, или медленнее?

Как вариант, можно найти себе девушку.

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

А экспериментально не установлено, что это говнопрограмма?

кстати говоря, под большие файлы ФС надо форматировать по другому. Это говорит лишь о неумении ТС готовить ФС под свои задачи.

если создать на ext4 большой файл (сотни гигабайт), смонтировать его как диск, отформатировать в btrfs и писать файлы на него, будет быстрее, чем непосредственно на ext4, или медленнее?

Смонтировать с -o loop? Быстрее. Ибо loop кэшируется.

на xfs это было ужасно медленно

Я тогда тестирование устраивал и по результатам остановился на рейзоре. Цифр даже примерно не помню. Где то на лоре в те времена это обсуждалось.

1. Многое зависит от того, как настроить ФС,

2. Многое зависит от других подсистем ядра и их настройки.

3. Многое зависит от конфигурации компьютера в целом.

4. Да даже от носителя информации многое зависит.

Так что ты изначально неправильно сформулировал вопрос.

Другое дело что за счет всякого кэширования некоторые вещи могут быть быстрее.

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

Дефраг возвращал скорость?

Как сделать дефраг на ext4? Помимо «скопировать всё на другой диск, а потом назад».

да. будет быстрее. точно так же, как быстро со скоростью света записываются файлы на usb-флешку. только когда начнёшь делать sync/umount придётся подождать.

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

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

Или как обеспечить такое же кеширование на ext4?

Смонтировать с -o loop? Быстрее. Ибо loop кэшируется.

Что кешируется лучше? Правильно настроенная ext4? Правильно настроенная btrfs? Любой loop?

Как сделать дефраг на ext4?

e4defrag

А экспериментально не установлено, что это говнопрограмма?

Это proof-of-concept. И нет единого мнения с чего начать оптимизацию — с программы, тестовой машины, или порядка действий пользователя.

В чём по твоему мнению заключается говённость? Помимо того, что пакет разбит на 2 программы: для сохранения приходящих данных на диск и для их последующего анализа.

Путаешь. loop devices работают ПОВЕРХ ФС и журналирование на них вполне себе распространяется. Другое дело что за счет всякого кэширования некоторые вещи могут быть быстрее.

Спасибо за комментарий специалиста.

e4defrag

Спасибо.

И как оно с мелкими файлами сейчас работает?

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

В чём по твоему мнению заключается говённость?

у меня две догадки:
1. дикий io
2. постоянная запись большого объёма данных на диск.
что несколько накладывающиеся вещи, но не всегда одинаковые

Когда я последний раз смотрел на вышеупомянутый e4defrag, он по сути это и делал, только в рамках одного раздела. Т.е. разработчики, видимо, исходят из того, что большинство файлов записываются без предварительного fallocate(размер будущего файла), а, значит, сделать этот fallocate, уже зная размер, переписать полностью(!) туда файл и удалить источник, должно уменьшить фрагментацию. «Умного» дефрага как в винде, на сколько я знаю, всё ещё нет.

Как сделать дефраг на ext4?

e4defrag

Обычно весьма бесполезно. Оно только файлы дефрагментирует, а с этим в ext4 итак порядок. Свободное пространство оно не консолидирует и каталоги не оптимизирует. У ext4 заявлена офлайн-опция оптимизации каталогов, но реально не работает. И офлайн, что делает её бесполезной на серверах. Для особо запущенных случаев у меня есть такой скриптик :)

#!/bin/bash

mv "$1" "$1.tmp"
mkdir "$1"
mv "$1.tmp"/* "$1"/
rmdir "$1.tmp"
chmod a+w "$1"

Обычно весьма бесполезно.

Личный опыт подтверждает это заявление. Подробностей что ты описал не знал.

У меня на екст4 остался только корень который на ссд, так что фрагментация не критична. И хомяк который все собираюсь перенести на на тот же ссд с btrfs.

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

Там делали рефакторинг старого ужаса и в процессе накосячили. Потом дедлок починили. Но это было ещё до того, как нумерацию версий с 2.6.x сменили на 3.x. Очень давно уже.

У ext4 заявлена офлайн-опция оптимизации каталогов, но реально не работает.

Эта опция e2fsck только добавляет индекс в каталоги, если его нет. Такое может случиться, если ext3 конвертировалась в ext4 на месте. Если же ext4 создаётся с нуля, индексы там уже есть, если их специально не отключать. К дефрагментации эта фича вообще никакого отношения не имеет.

Но это было ещё до того, как нумерацию версий с 2.6.x сменили на 3.x. Очень давно уже.

Года два назад на это нарвался. Надо по форумам поднять, когда там я на зависы отписывался :)

Но это было ещё до того, как нумерацию версий с 2.6.x сменили на 3.x. Очень давно уже.

Я по тем же причинам уехал обратно на екст4.

Релиз Linux 3.9 (комментарий)

Вопрос: если создать на ext4 большой файл (сотни гигабайт), смонтировать его как диск, отформатировать в btrfs и писать файлы на него, будет быстрее, чем непосредственно на ext4, или медленнее?

А ведь кстати можно же как-то смонтировать этот образ не через -o loop, а указав физическое расположение на /dev/sd* (ну там оффсет и размер, например)? А вообще было бы прикольно если бы при -o loop оно само именно так и работало бы автоматически (обращение сразу к блочному устройству, минуя родительскую ФС). Вообще интересная тема, может оно действительно так и работает, просто мы не знаем? Кто нибудь смотрел код?

быстрее... или медленнее?

любой ответ на любой подобный вопрос без соответствующих бенчмарков - пук в лужу

Это proof-of-concept. И нет единого мнения с чего начать оптимизацию — с программы, тестовой машины, или порядка действий пользователя

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

Выше дали удовлетворительные ответы без этих данных :) Кеширование, либо отдельный раздел диска.

Программа читает 3-мерный массив данных с нерегулярной сеткой из одного из 40 форматов, загоняет их в HDF, ищет пики, приводит к регулярной сетке, ищет синхронные пики, и т.д. Конвертер и процессор — разные процессы.

я про диск спрашивал...
загоняет их в HDF - в смысле, в файл?