Запись на LVM-раздел происходит странно.

то есть lv целиком из 2 физ. дисков?

на sdb и sdc созданы разделы sdb1 и sdc1 размером в весь диск каждый, из sdb1 и sdc1 создана группа lvm, в группе один volume, который занимает всю группу. Я думал, что данные при таком раскдаде пишутся сначала на первый диск sdb1, затем, после заполнения первого на второй sdc1, ан нет.

Так может ты в stipe их объединил, а не jbod?

Так может ты в stipe их объединил, а не jbod?

Никак нет, именно в jbod, харды разные, один 2Тб, второй 1,5Тб, lvm раздел, соответственно 3,5Тб.

А кто сказал, что если JBOD, то данные должны писаться последовательно? Я подозреваю, что происходит балансировка для равномерного износа носителей

И, кстати, раздел-то какой? PV растянут на оба диска, VG один, LV один?

а разве можно один пв на два диска?

тьфунах, один VG на два PV

Это не есть гуд, в таком случае надёжность такого lvm такая же как у страйпа, то есть никакая.

Один vg на два pv, на vg один lv.

А какую надёжность хочется от JBOD?

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

Я к тому, что обеспечивать надёжность - не задача JBOD :)

Да это понятно, но в данном случае если летит один хард я теряю всё. Лучше разберу я это lvm на диски обратно. Всегда думал, что jbod пишет последовательно, хорошо что догадался iostat запустить.

Хочешь надёжность - делай raid 1 или 5, а алгоритмы JBOD, по-моему, вообще нигде не стандартизованы

Хочешь надёжность

В данном случае не хочу, но терять 2Тб из-за дебильных алгоритмов записи тоже не хочу.

Это не есть гуд, в таком случае надёжность такого lvm такая же как у страйпа, то есть никакая.

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

Есть мнение, что выбором того, на какой конкретно сектор lvm-раздела писать, выбирает не сам lvm, а драйвер файловой системы на нём.

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

Подозреваю, скорее всего, ничего, кроме ext*, там нет, а ексты выбирают айноды вовсе не хаотично

XFS

И кстати, ИМХО ты изначально поступил неправильно - выделил всё свободное место в VG под LV. Нужно было выделить в LV столько место, сколько под твою задачу требуется сейчас плюс немного сверху. А остальное оставить свободным - для дальнейших манёвров.

Манёвры не нужны, это обычная файловая помойка.

Манёвры не нужны, это обычная файловая помойка.

И тем не менее, оставление свободного пространства в LV - это решение твоей надуманной «проблемы».

Кстати, попробую сейчас в ext4 форматнуть, посмотрим что будет.

Гыгыгы, XFS. Человек, выбравший XFS для файлопомойки, говорит о надёжности? Бесперебойник-то есть? На всякий случай, все незакрытые файлы после сбоя окажутся нулевого размера

в VG конечно же...

надуманной «проблемы»

Это не надуманная проблема, это намеренное снижение надёжности, там где об этом не просили. Если бы я хотел страйп, то я бы его и сделал, но я хочу последовательную запись данных.

Короче, я бы на твоём месте не парился. На моей памяти (с 2003 года) нет ни одного сдохшего от старости диска. Только недавно 2 диска отдали концы. Правда, из-за механических повреждений контроллера

Скорее всего XFS «размазывает» данные равномерно по всему объёму логического тома, предоставленного ей, чтобы обеспечить одинаковую (приемлемую) скорость доступа к любому файлу на ней.

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

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

5 минут и всё будет понятно, форматирую в ext4.

А непоследовательная плюс ко всему уменьшает фрагментацию

Каким образом?

Попробуй ещё UDF с разными media type. Думаю там есть интересующая тебя последовательная запись.

5 минут и всё будет понятно, форматирую в ext4.

Чтобы было, как тебе хочется, форматировать надо в FAT16 или UDF. Даже FAT32, не говоря о юниксовых ФС, хранит таблицу в конце диска. Юниксовые системы размазывают метаданные, да ешё и в нескольких копиях по всему диску, а данные разных файлов обычно пишут как можно дальше друг от друга для уменьшения фрагментации.

Попробуй ещё UDF с разными media typ

Это такой извращенный метод расстаться с данными?

Ты оказался абсолютно прав. На lvm форматированный в ext4 пишет строго последовательно. Проблема в том, что я не хочу ext4, она тормоз, по сравнению с xfs.

Это такой извращенный метод расстаться с данными?

Так вроде автор темы и так хочет странного...

Каким образом?

Пока есть более 50% свободного места, каждый файл гарантированно занимает линейный участок диска.

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

форматированный в ext4 пишет строго последовательно

Запишем: «отказаться от ext4 в продакшен».

На lvm форматированный в ext4 пишет строго последовательно.

Один диск забил?

Один диск забил?

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

Запишем: «отказаться от ext4 в продакшен».

Давно пора.

Какое же ext4 тормозное поделие, при параллельной записи система просто умирает.

Давно пора.

Никогда и не было, а теперь уже точно не будет.

Это не надуманная проблема, это намеренное снижение надёжности, там где об этом не просили. Если бы я хотел страйп, то я бы его и сделал, но я хочу последовательную запись данных.

Если у тебя сдохнет один из винтов, то ты из XFS всё равно ничего не вытащишь.

Если у тебя сдохнет один из винтов, то ты из XFS всё равно ничего не вытащишь.

Я это уже понял. Удалил lvm, пусть будут два харда отдельно.

с опцией barrier

нулевого размера точно не будет

Такое поведение фс при внезапном отключении проверено? Или просто ожидается, что всё, вроде бы, должно пройти гладко, но на практике неизвестно как оно будет?

Такое поведение фс при внезапном отключении проверено?

Проверено, файл не нулевой, сколько успело, столько записалось.