LINUX.ORG.RU

Статья «про XFS».


0

0

Статья на IBM developerWorks расскажет о том где взять, как сделать и что вам даст использование одной из если не самой "продвинутой" журналируемой файловой системы SGI XFS.

>>> Статья.

anonymous

Проверено:

И каким же именно местом, это она продвинулась?

anonymous
()

Продвинулась она технологией на которой сделано. Что дает один из лучший перфомансов для журналируемых фс. По перфомансу ей есть только один конкурент - рейсерфс, но рейсер выигрывает только на специфических задачах типо работы с маленькими файлами. XFS сделана гораздо логичней чем например рейсер поэтому считается устойчивей, она годами оттестирована на мультимедийных приложениях айрикса.
у нее есть ACL, поддержка квот, attr, realtime subvolume, DAPI. Короче говоря XFS самая-самая из журналируемых фс.

anonymous
()

Плюс ещё 64 битная.

anonymous
()

попрошу ссылку на патчи 2.4 ядер

manowar ★★
()

to Manowar: RTFA -- Read The Fine Article

anonymous
()

Кстати поставил тут ее на ядре 2.4.18-up.alt4
полный порядок. апт работает нормально. ошибок с mmap не выдает.

Avel
()

В дебиане на сиде (про вуди не знаю) кстати есть
apt-get install xfsprogs (затянет и attr тоже). Так что собрать нужно будет только ядро. А еще для дебиана есть дискеты и iso бутные с поддержкой xfs чтоб можно было сделать чистую инсталяцию на xfs.
А еще у xfs есть dump и соответсвенно restore.

CuPoTKa
()

у нее есть ACL, поддержка квот, attr, realtime subvolume, DAPI. Короче говоря XFS самая-самая из журналируемых фс. ====================================================

Ну не надо так идиализировать. Достоинства безусловно есть, но есть и нюансы. Например то что вы говорите realtime subvolume работает только в Irix и вряд ли будет развиваться в Linux. Например для того чтобы положить файлы данных БД( например Oracle) - она увы не годится по причине снижения быстродействия и увелеиченных требований к ресурсам процессора и притом прилично по сравнению с той же ext2. Когда я пробовал ее примерно полгода назад имелся такой маленький баг, который при создании большого файла приводил систему в каматозное состояние( Вроде и система жива, а сделать ничего нельзя). Да еще я на нее возлагал надежды , надеясь увидеть размер блока болье 4к. То что она умеет работать с больщими блоками на SGI для меня пустой звук. А так перспективы у нее конечно есть.

СтранниК

anonymous
()

To СтранниК:

"realtime subvolume работает только в Irix и вряд ли будет развиваться в Linux."

Одному уже сказали "RTFA -- Read The Fine Article". Повторить?

anonymous
()

Я ее тоже юзаю с Ноября прошлого года на Слаквари 8.0 и ядре 2.4.5, но, блин, а как ACL администрить, могет кто-нибудь подсказать ?

anonymous
()

По поводу большого файла у меня всё нормально

anonymous
()

СтранниК
> Например для того чтобы положить файлы данных БД( например Oracle) - она увы не годится по причине снижения быстродействия

Не надо класть БД вообще ни на какие ФС. Они только мешают СУБД.
Кладите на RAW-тома.


AffreuxChien
()

Realtime subvolume есть и в линухе для хфс. И если будет нужно то будет развиваться. Я не большой специалист по базам данный оракла но помойму это не то что называет realtime. Это нужно для других целей realtime не значит повышение перфоманса. А можно узнать зачем Вам блоки больше чем 4к? Больше блок = больше внутренняя фрагментация. Кстати а точно нету или все таки когда создается фс можно задать и больше надо проверить... Даже если щас нет то это в развитии. хфс в линухе будет поддерживать все фичи родной айриковской хфс.
Естественно что журналируемая фс проигрывает нежурналирумаемой по перфомансу, кстати ext2 вообще почти что самая быстрая фс. Ей все проигрывает. У каждой фс есть ньюансы но у хфс меньше, трудно найти другую журналируемую фс которая по какому-нибудь параметру бы превосходила хфс.

anonymous
()

Realtime subvolume есть и в линухе для хфс. И если будет нужно то будет развиваться. Я не большой специалист по базам данный оракла но помойму это не то что называет realtime.

========================================== Ну конечно это не для использования Oracle.

<< Это нужно для других целей realtime не значит повышение перфоманса. А можно узнать зачем Вам блоки больше чем 4к? Больше блок = больше внутренняя фрагментация. Кстати а точно нету или все таки когда создается фс можно задать и больше надо проверить... Даже если щас нет то это в развитии. хфс в линухе будет поддерживать все фичи родной айриковской хфс. >>>

Большой размер блоков для БД имеет знаение например для пакетных заданий или для систем DSS.

СтранниК

anonymous
()

2AffreuxChien

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

СтранниК

anonymous
()

кстати все в курсе, что oss.sgi.com уже с неделю в дауне?

anonymous
()

Серьезно??? :) Что-то не заметили этого. Это что-то другое у Вас в Дауне :)

anonymous
()
Ответ на: комментарий от anonymous

> Да и быстродействие БД на чтение снижается, за счет того что ОС не использует кэш
По-моему отдаёт бредом - кэш БД вроде никто не отменял.

> с файликами то проблем меньше
А вы raw совместно с LVM использовали?

rabbit
()

В БД _нет_ никаких операций, для которых необходимо было бы держать файлы.
ФС - только мешает. Структуры данных и каталогизация данных в РСУБД совершенно иные.

> Да и быстродействие БД на чтение снижается, за счет того что ОС не использует кэш.

Кэш ФС в случае работы с БД абсолютно неэффективен. ФС не знает и не может знать методов обращения к данным в БД, он только отбирает память, которую можно выделить на буфера БД.

Итого:
Никаких преимуществ у размещения БД на ФС нет, только замедление.

AffreuxChien
()

2rabbit

> Да и быстродействие БД на чтение снижается, за счет того что ОС не использует кэш По-моему отдаёт бредом - кэш БД вроде никто не отменял.

> с файликами то проблем меньше А вы raw совместно с LVM использовали? =================================== Читайте доку уважаемый. Само собой кэш присутствует. И что физического чтения при использовании кэша нет? За счет того что ос кэширует фаловые операции ( не важно эфективно или нет) быстродействие по чтению с файлов будет выше( это и опытом подтверждается). По-поводу LVM: Вместо того чтобы сделать обычный resize файла данных я должен привлечь еще LVM.( Давно ли в Linux работает стабильно LVM?). Не стоит использовать те вещи, выйгрыш от внедрения которых сомнителен, а сложность эксплуатации гораздо выше.

СтранниК

anonymous
()

2AffreuxChien

Все ты вы в теории красиво рассказывает, а вот как насчет практики? Я так тоже умею.

СтранниК

anonymous
()

> а вот как насчет практики?
Практика стоит в серверной комнате, с DB2 7.2
На RAW объемные выборки идут быстрее, чем на ФС.

AffreuxChien
()

Теоретически читал где-то что фс медленнее прямого доступа раз в 6

anonymous
()

Практика стоит в серверной комнате, с DB2 7.2 На RAW объемные выборки идут быстрее, чем на ФС. ===================================== Ну вообще-то про Oracle речь шла. Да еще насчет чтений. Надеюсь вы слышали что ОС читает не один требуемый блок, а блок размером 64к либо 128к и за счет этого сообственно и достигается быстродейсвие.

СтранниК

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.