xfsprogs 3.2.0 с поддержкой нового дискового формата

1

4

Сегодня представлен мажорный релиз набора пользовательских утилит — xfsprogs 3.2.0.

За год с момента выхода предыдущей версии 17 разработчиков сделали более 300 коммитов, изменив около 30000 строк кода.

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

Другие изменения:

улучшения в многопоточности для xfs_repair;
xfs_db переведён на использование библиотеки libxfs (общего движка для пакета утилит);
xfs_db теперь использует контрольные суммы для проверки целостности метаданных;
xfs_io поддерживает возможности, добавленные в linux с момента предыдущего релиза xfsprogs;
проведена работа по минимизации отличий кода libxfs и ядерной реализации.

Начиная с linux 3.15-rc5, пятая версия дискового формата признана стабильной и готовой для промышленного использования.

Также следует отметить отход от руководства разработкой компании SGI — оригинального разработчика XFS.

>>> Подробности

Ссылка

←	Каталог пакетов TeX Live (update)

Релиз vifm 0.7.7

→

← 1 2 →

Кто-нибудь пользуется это фс? Есть профит для хранения на ней файлов больших размеров?

~~katya_mama~~
(17.05.14 10:14:21 MSK)

Ссылка

Ответ на: Чушь от Ilshat 17.05.14 07:26:16 MSK

И что? Бекап баз это нагрузка вообще ни о чем. У тебя последовательная запись и чтение. Под реальной нагрузкой (куча сиков, реврайтов кусков файлов, ридов ....) драйвер xfs просто виснет.

Reset ★★★★★
(17.05.14 10:19:40 MSK)

Ответ на: комментарий от AVL2 17.05.14 01:44:21 MSK

В стандартных файловых системах большие объемы не хранят. Для этого есть более вменяемые решения, например hdfs.

Reset ★★★★★
(17.05.14 10:21:34 MSK)

Ответ на: Чушь от Ilshat 17.05.14 07:26:16 MSK

20ТВ, постоянно бэкапятся базы, до 1,5ТБ, там же шары, бакула и т.д.

одним разделом? молодец, чо

anonymous
(17.05.14 12:45:41 MSK)

Ссылка

Ответ на: комментарий от Reset 16.05.14 21:39:29 MSK

Для них это совсем не 0.00001%, а процентов 10 минимум

~~no-dashi~~ ★★★★★
(17.05.14 12:56:58 MSK)

Ответ на: комментарий от no-dashi 17.05.14 12:56:58 MSK

RH обычно используют как подстилку под оракл, а ораклу fs не нужна.

Reset ★★★★★
(17.05.14 13:11:00 MSK)

Ответ на: комментарий от Reset 17.05.14 10:21:34 MSK

В стандартных файловых системах большие объемы не хранят. Для этого есть более вменяемые решения, например hdfs.

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

~~mashina~~ ★★★★★
(17.05.14 13:17:43 MSK)

Ответ на: комментарий от d 16.05.14 19:04:48 MSK

SSD, которой всего полгода. Дефрагментатор гонял - не помогло.

gadfly ★★
(17.05.14 13:32:26 MSK)

Ответ на: комментарий от Reset 17.05.14 13:11:00 MSK

RH обычно используют как подстилку под оракл, а ораклу fs не нужна.

Сказал как отрезал. А почему оракл а не убунту? Зачем недомолвки, скрываешь правду: «RH обычно используют как подстилку под убунту, а после скачивания образа установщика Убунточки RH не нужна».

anonymous
(17.05.14 13:46:11 MSK)

Ссылка

Ответ на: комментарий от mashina 17.05.14 13:17:43 MSK

_хранят_ как раз в специализированных решениях типа hdfs

Reset ★★★★★
(17.05.14 15:46:48 MSK)

Ответ на: комментарий от Reset 17.05.14 15:46:48 MSK

_хранят_ как раз в специализированных решениях типа hdfs

это которая на жаба написана?

anonymous
(17.05.14 16:23:43 MSK)

Ответ на: комментарий от anonymous 17.05.14 16:23:43 MSK

и?

Reset ★★★★★
(17.05.14 16:24:54 MSK)

Ответ на: комментарий от Reset 17.05.14 16:24:54 MSK

а, ну, в такие «хранилища» что-то ложить... разве что под засыпку нафталином...

anonymous
(17.05.14 16:33:15 MSK)

Ссылка

Ответ на: комментарий от Reset 17.05.14 15:46:48 MSK

_хранят_ как раз в специализированных решениях типа hdfs

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

~~mashina~~ ★★★★★
(17.05.14 16:58:10 MSK)

Ссылка

Ответ на: комментарий от anonymous 16.05.14 16:43:52 MSK

Это когда всё прогрессивное человечество использует ZFS и HAMMER?

~~esandmann~~
(17.05.14 18:08:02 MSK)

Ответ на: комментарий от ArtKun 16.05.14 16:33:58 MSK

Значит, разделы нужно форматировать заново утилитой новой версии?

Они не осилили версии FS?

~~esandmann~~
(17.05.14 18:08:38 MSK)

Ссылка

Ответ на: Чушь от Ilshat 17.05.14 07:26:16 MSK

бакула

Скотт Бакула шоле?

~~esandmann~~
(17.05.14 18:13:53 MSK)

Ссылка

Ответ на: комментарий от esandmann 17.05.14 18:08:02 MSK

ZFS и HAMMER

ненужно и ненужно в квадрате

anonymous
(17.05.14 18:16:50 MSK)

Ответ на: комментарий от anonymous 17.05.14 18:16:50 MSK

Ну линуксоеды-то могут утешать себя как хотят. Типа: «Проверено временем» или «ext3 + ssh + tar позволяют мне хранить мой прон в нескольких надежных местах» и даже «у меня в корпусе неподключенный диск с бекапом за прошлый месяц»

~~esandmann~~
(17.05.14 18:42:33 MSK)

Ссылка

Ответ на: комментарий от Reset 17.05.14 10:21:34 MSK

Угу, например, имеем полку 36Тб и необходимость зеркалить на нее через rsync соответствующий объем файловых данных. Впорос, при чем тут кластерные fs?

~~AVL2~~ ★★★★★
(17.05.14 20:53:39 MSK)

Ссылка

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

lucentcode ★★★★★
(17.05.14 23:28:56 MSK)

Ответ на: комментарий от lucentcode 17.05.14 23:28:56 MSK

А начиная с ext3fs использовать нестандартную ФС уже не было необходимости.

Минимальный набор фич для сравнения с XFS Ext получил только в 4ой версии. Это preallocation и extents. И всё ещё в Ext нет dynamic inode allocation. Такую ФС опасно ставить на очень большие носители с непредсказуемым будущем.

~~mashina~~ ★★★★★
(18.05.14 00:23:40 MSK)
Последнее исправление: mashina 18.05.14 00:24:16 MSK (всего исправлений: 1)

Ответ на: комментарий от MiniRoboDancer 17.05.14 03:00:46 MSK

перенёс туда ещё и свопфайл с ext3
GNU/linux
свопфайлы

А чего так по-оффтопски?

Flammpanzer
(18.05.14 15:27:18 MSK)

Ответ на: комментарий от mashina 18.05.14 00:23:40 MSK

Добавлю, что в ext4 ещё только-только запиливается хранение квот в служебных структурах вместо файлов в корне.

Gotf ★★★
(18.05.14 15:32:21 MSK)

Ссылка

Ответ на: комментарий от gadfly 17.05.14 13:32:26 MSK

А TRIM не пробовал делать?

SSD еще и на SF наверное.

anonymous
(18.05.14 18:42:24 MSK)

Ответ на: комментарий от Flammpanzer 18.05.14 15:27:18 MSK

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

~~MiniRoboDancer~~ ★☆
(18.05.14 19:08:12 MSK)

Ссылка

Ответ на: А TRIM не пробовал делать? от anonymous 18.05.14 18:42:24 MSK

/dev/sda2 on /home type xfs (rw,noatime,attr2,discard,inode64,allocsize=65536k,noquota)

gadfly ★★
(18.05.14 19:21:25 MSK)

Ответ на: комментарий от Reset 17.05.14 10:19:40 MSK

И что? Бекап баз это нагрузка вообще ни о чем. У тебя последовательная запись и чтение. Под реальной нагрузкой (куча сиков, реврайтов кусков файлов, ридов ....) драйвер xfs просто виснет.

Там хитро очень. В XFS есть экстенты (или как их там), которые нужно выделить заранее при создании ФС. Запись и подтверждения в один экстент не залочат остальные экстенты. Это в теории приводит к некоему подобию реального времени при прогнозируемой параллельной нагрузке.

Например, запись восьми видеопотоков на раздел с >=8 экстентами. fsync одного из файлов не поставит раком запись в остальные файлы.

anonymous
(18.05.14 19:22:27 MSK)

Ответ на: комментарий от anonymous 18.05.14 19:22:27 MSK

Запись и подтверждения в один экстент не залочат остальные экстенты.

Экстенты — совсем не то. Ты говоришь об allocation groups (AG).

Например, запись восьми видеопотоков на раздел с >=8 экстентами. fsync одного из файлов не поставит раком запись в остальные файлы.

Это зависит от allocation policy.

d ★★★★
(18.05.14 20:00:12 MSK) автор топика

Ответ на: комментарий от anonymous 18.05.14 19:22:27 MSK

Там хитро очень. В XFS есть экстенты (или как их там), которые нужно выделить заранее при создании ФС. Запись и подтверждения в один экстент не залочат остальные экстенты. Это в теории приводит к некоему подобию реального времени при прогнозируемой параллельной нагрузке.

Всё совсем не так. Экстент это способ перечисления используемых блоков файлом (потоком) в виде диапазонов значений, экстент выделяется динамически. В противоположность перечислению каждого блока в отдельности как это у ФС типа ext2/3.

А о чём ты говоришь называется allocation group (AG), это что-то вроде отдельной файловой системы с которой можно работать независимо от других AG. В частности внутри XFS так и делает, т.е. балансирует все IO между несколькими AG внутри которых пытается оптимизировать запись на диск.

Уменьшить влияние fsync можно только уменьшением сиков или увеличением потолка по сикам. Сам факт порезки хранилища на AG этому не помогает, но обычно большие разделы XFS лежат на нескольких физических носителях (JBOD + RAID) и если правильно резать на AG, то можно положить отдельные AG на отдельные носители, т.е. будет полная параллельность при одновременной записи.

И с другой стороны XFS использует preallocate во время записи, т.е. заранее резервирует длинный непрерыный экстент пр-ва уменьшая фрагментацию и кол-во сиков при дальнейшей записи и чтении.

~~mashina~~ ★★★★★
(18.05.14 20:49:45 MSK)

Ответ на: комментарий от mashina 18.05.14 20:49:45 MSK

В XFS есть экстенты (или как их там),

А о чём ты говоришь называется allocation group (AG)

Перепутал... :) давно читал про xfs, подзабыл как оно правильно называется.

Уменьшить влияние fsync можно только уменьшением сиков или увеличением потолка по сикам.

Я немного не об этом. Падение скорости винта из-за сиков естественно не пройдет. Это на уровне ФС практически нерешаемо (ну крому ФС в стиле NIL2FS/F2FS при постоянной записи без чтения).

Есть раздел reiserfs3 1.5 Gb с торрентами, на котором при перезаписи небольшого файлика (.torrent) ФС уходит в себя на минуту-другую. При этом ядро лочит все последующие операции ввода-вывода на этом разделе (не знаю по какой причине, может дерево там разрослось, может журнал фрагментирован). Файловый менеджер, текстовый редактор после нажатия «сохранить», даже ls в консоли - висят вместе с торрент-клиентом. Судя по мониторам все это время винт неторопливо вычитывает данные со скорость 500кб-1Мб/с с раздела. Остальные разделы медленнее, но работают.

XFS в подобной ситуации (ну чисто гипотетически предположим, что повела себя так же) залочит ввод-вывод только в той же AG, что и .torrent-файл. Остальное может тормозить уже из-за сиков винта (но ФС уже как бы не виновата)...

anonymous
(18.05.14 21:52:53 MSK)

Ответ на: комментарий от d 18.05.14 20:00:12 MSK

Например, запись восьми видеопотоков на раздел с >=8 экстентами. fsync одного из файлов не поставит раком запись в остальные файлы.

Это зависит от allocation policy.

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

anonymous
(18.05.14 22:03:22 MSK)

Ссылка

Ответ на: комментарий от Reset 17.05.14 10:21:34 MSK

В стандартных файловых системах большие объемы не хранят. Для этого есть более вменяемые решения, например hdfs.

а также ceph, glaster и пр. распределенные системы, казалось бы, при чем тут ZFS и XFS.

insider ★★★
(18.05.14 23:34:51 MSK)

Ссылка

Ответ на: комментарий от gadfly 18.05.14 19:21:25 MSK

Странно...

А fstrim -v /home сейчас что выдает?

anonymous
(19.05.14 01:02:15 MSK)

Ответ на: комментарий от anonymous 18.05.14 21:52:53 MSK

При этом ядро лочит все последующие операции ввода-вывода на этом разделе (не знаю по какой причине, может дерево там разрослось, может журнал фрагментирован). Файловый менеджер, текстовый редактор после нажатия «сохранить», даже ls в консоли - висят вместе с торрент-клиентом. Судя по мониторам все это время винт неторопливо вычитывает данные со скорость 500кб-1Мб/с с раздела.

Что значит не торопливо? Явно он упёрся в потолок по IO. Обычно ядро/фс пытается опттмизировать сброс грязных кластеров, а когда приходит fsync, то приходится сбрасывать как есть. Я лично у себя такого чудотворного эффекта XFS на одном физическом носителе не замечал - если приходит синк, то всё встаёт на время так же, как и на всех остальных ФС. Сомневаюсь, что ФС что-то при этом специально лочит.

~~mashina~~ ★★★★★
(19.05.14 21:43:35 MSK)

Ссылка

Ответ на: комментарий от gadfly 18.05.14 19:21:25 MSK

(rw,noatime,attr2,discard,inode64,allocsize=65536k,noquota)

А что allocsize такой большой? Для хомяка с кучей мелких файлов это явно перебор. Мб место со временем съедается этими преаллоками и ФС становится труднее искать свободное место.

~~mashina~~ ★★★★★
(19.05.14 21:51:12 MSK)