The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Представлен проект OpenZFS, направленный на  унификацию разв..., opennews (ok), 18-Сен-13, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


35. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +2 +/
Сообщение от AlexAT (ok), 18-Сен-13, 11:56 
> а на андройде? на андройде zfs будет?

Попытка прикрутить к мотоциклу двигатель от грузового ЗИЛа обычно кончается почти так же. И имеет такой же смысл.

Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

42. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +/
Сообщение от Михрютка (ok), 18-Сен-13, 12:04 
>> а на андройде? на андройде zfs будет?
> Попытка прикрутить к мотоциклу двигатель от грузового ЗИЛа обычно кончается почти так
> же. И имеет такой же смысл.

опять тег "сарказум" отломали, ироды!

Ответить | Правка | Наверх | Cообщить модератору

78. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +/
Сообщение от еще один аноним (?), 18-Сен-13, 14:18 
Это точно, даже смешно - большинство вышестоящих товарищей и не поняло что это был сарказм. Вероятно потому, что в свете упоминания распберрипи такой вопрос мог показаться им серьезным. Действительно, как этот монстр (при его потребностях в памяти) сможет крутиться в распберри?
Ответить | Правка | Наверх | Cообщить модератору

79. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +/
Сообщение от AlexAT (ok), 18-Сен-13, 14:20 
> Это точно, даже смешно - большинство вышестоящих товарищей и не поняло что
> это был сарказм. Вероятно потому, что в свете упоминания распберрипи такой
> вопрос мог показаться им серьезным. Действительно, как этот монстр (при его
> потребностях в памяти) сможет крутиться в распберри?

Ну... этого монстра в чистой теории можно научить использовать системный кэш, а не ARC.

Ответить | Правка | Наверх | Cообщить модератору

90. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +/
Сообщение от Аноним (-), 18-Сен-13, 15:00 
> Ну... этого монстра в чистой теории можно научить использовать системный кэш, а не ARC.

Что-то мне кажется что линуксоиды с учетом лицензии воротить такой объем работ воротить не станут, а остальные дистрофики - "опять мимо винного понесет". Что они там разработать могут?

Ответить | Правка | Наверх | Cообщить модератору

115. "Представлен проект OpenZFS, направленный на  унификацию разв..."  –1 +/
Сообщение от Михрютка (ok), 18-Сен-13, 16:30 
> Ну... этого монстра в чистой теории можно научить использовать системный кэш, а
> не ARC.

особенно в контексте распберри с его огромными объемами памяти. и особенно если учитывать, нафига вообще ARC был придуман. да, наверное, можно.

Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

123. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +1 +/
Сообщение от Аноним (-), 18-Сен-13, 17:01 
> учитывать, нафига вообще ARC был придуман. да, наверное, можно.

Большая часть ZFSа была придумана в основном по причине отсутствия в соляре соответствующих подсистем.

Ответить | Правка | Наверх | Cообщить модератору

209. "Представлен проект OpenZFS, направленный на  унификацию разв..."  –3 +/
Сообщение от Аноним (-), 19-Сен-13, 15:01 
>> Это точно, даже смешно - большинство вышестоящих товарищей и не поняло что
>> это был сарказм. Вероятно потому, что в свете упоминания распберрипи такой
>> вопрос мог показаться им серьезным. Действительно, как этот монстр (при его
>> потребностях в памяти) сможет крутиться в распберри?
> Ну... этого монстра в чистой теории можно научить использовать системный кэш, а
> не ARC.

Эй, вы все - лукайте сюды:

set zfs:zfs_arc_max=1073741824

Усекли, не? Можно и поменьше цифирь поставить. Компрене ву?

Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

218. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +2 +/
Сообщение от andy (??), 19-Сен-13, 16:04 
> Эй, вы все - лукайте сюды:
> set zfs:zfs_arc_max=1073741824
> Усекли, не? Можно и поменьше цифирь поставить. Компрене ву?

Г-н Войнов, строчите помпезные заметки в блоге и не пишите херни
тут.

Ответить | Правка | Наверх | Cообщить модератору

224. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +1 +/
Сообщение от Аноним (-), 19-Сен-13, 16:24 
> Эй, вы все - лукайте сюды:

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

> set zfs:zfs_arc_max=1073741824
> Усекли, не?

Да, усекли. И потом у меня на компе с 16 гиг оперативы после этого кульного совета 15 гигов оперативы будут курить бамбук, тогда как диск с гигом кэшатины будет истошно тормозить, поскольку в ZFS как-то особо и нечему быть быстрым "самому по себе". Дизайн где не сделали экстенты, забили на дефрагер болт и прочая просто не имеет причин для быстрой работы.

Ответить | Правка | К родителю #209 | Наверх | Cообщить модератору

228. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +1 +/
Сообщение от AlexAT (ok), 19-Сен-13, 17:55 
И щито, оно от этого научится системный кэш использовать? А если я 0 (ну или там 16384, 65536, 262144, 1048576, не больше) поставлю - должный результат будет? Или будут тормоза на уровне удава по стекловате?

У меня у сторейджа на виртуалке под ESXi - всего 512 Мб памяти. На всё про всё, включая ОС/SMB/NFS/GlusterFS/иещенесколькоразныхвещей. Гиг выделять жирновато. LVM/ext4, угу. Всякая всячина - от ФС с файлами в несколько гиг объемом, до ФС с тысячами файлов по 500 килобайт в среднем (хомяк с документами, фото и прочим маразмом). И прикинь, это счастье 1Gbps через сетку на диски и назад (можно даже одновременно) спокойно протаскивает, ни разу не напрягаясь. Без всяких многогигабайтных непоймизачемкешей, оторванных от системы.

Ответить | Правка | К родителю #209 | Наверх | Cообщить модератору

238. "Представлен проект OpenZFS, направленный на  унификацию разв..."  –5 +/
Сообщение от nagualemail (ok), 19-Сен-13, 21:47 
> У меня у сторейджа на виртуалке под ESXi - всего 512 Мб
> памяти.

Одмины локалхоста суровы ... учитывая цену оперы это явно не от недостатка денег ;)))


Ответить | Правка | Наверх | Cообщить модератору

239. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +5 +/
Сообщение от andy (??), 19-Сен-13, 22:12 
> Одмины локалхоста суровы ... учитывая цену оперы это явно не от недостатка
> денег ;)))

А покупать оперативу на каждую прихоть таких вот wannabe энтерпрайзных
админов, которых на кривой козе хрен объедешь, это, безусловно, от переизбытка
ума, так?

Ответить | Правка | Наверх | Cообщить модератору

245. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +2 +/
Сообщение от Аноним (-), 20-Сен-13, 01:26 
> админов, которых на кривой козе хрен объедешь, это, безусловно, от переизбытка ума, так?

Еще веселее как они фиксированное число сватают как панацею. Специально обученные обезьяны при компьютере - это феерично!

Ответить | Правка | Наверх | Cообщить модератору

242. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +1 +/
Сообщение от AlexAT (ok), 20-Сен-13, 00:02 
> Одмины локалхоста суровы ... учитывая цену оперы это явно не от недостатка
> денег ;)))

На площадке 24Гб RAM, и скоро будет 32. Просто там вполне себе есть, чем занять память.
Если сторейдж каши не просит, и отлично живет на 512Мб - зачем ему больше?

Ответить | Правка | К родителю #238 | Наверх | Cообщить модератору

244. "Представлен проект OpenZFS, направленный на  унификацию разв..."  –1 +/
Сообщение от Михрютка (ok), 20-Сен-13, 00:23 
> У меня у сторейджа на виртуалке под ESXi - всего 512 Мб
> памяти. На всё про всё, включая ОС/SMB/NFS/GlusterFS/иещенесколькоразныхвещей. Гиг выделять
> жирновато. LVM/ext4, угу. Всякая всячина - от ФС с файлами в
> несколько гиг объемом, до ФС с тысячами файлов по 500 килобайт
> в среднем (хомяк с документами, фото и прочим маразмом). И прикинь,
> это счастье 1Gbps через сетку на диски и назад (можно даже
> одновременно) спокойно протаскивает, ни разу не напрягаясь. Без всяких многогигабайтных
> непоймизачемкешей, оторванных от системы.

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

Ответить | Правка | К родителю #228 | Наверх | Cообщить модератору

252. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +1 +/
Сообщение от Аноним (-), 20-Сен-13, 02:38 
> эм, секунду, если стораж виртуализованный, то непонятно, в чем ваш пойнт.

Наверное в том что скорость работы оперативы и гигабитного эзернета "немного" отличаются, не? :)

Ответить | Правка | Наверх | Cообщить модератору

256. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +1 +/
Сообщение от AlexAT (ok), 20-Сен-13, 09:15 
> эм, секунду, если стораж виртуализованный, то непонятно, в чем ваш пойнт.

Пойнт в том, что все эти многогигабайтные ARC'и - костыль, без которого вполне нормально можно жить при нормальной реализации.

Ответить | Правка | К родителю #244 | Наверх | Cообщить модератору

265. "Представлен проект OpenZFS, направленный на  унификацию разв..."  –1 +/
Сообщение от Михрютка (ok), 20-Сен-13, 14:43 
>> эм, секунду, если стораж виртуализованный, то непонятно, в чем ваш пойнт.
> Пойнт в том, что все эти многогигабайтные ARC'и - костыль, без которого
> вполне нормально можно жить при нормальной реализации.

я чего-то не понимаю? ARC - кеш ZFS. вы считаете его костылем ровно потому, что он делает приблизительно то же самое, что страничный кеш, и хотите от него избавиться? а L2ARC при этом линуксовый кеш набивать будет? при таком подходя я вообще не понимаю, зачем использовать ZFS. Тем более на виртуальном стораже, когда ZFS будет работать поверх какой-нибудь VMFS.

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

Ответить | Правка | Наверх | Cообщить модератору

273. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +1 +/
Сообщение от AlexAT (ok), 20-Сен-13, 21:18 
> я чего-то не понимаю? ARC - кеш ZFS. вы считаете его костылем
> ровно потому, что он делает приблизительно то же самое, что страничный

Нет, я считаю его костылём потому, что это именно костыль - никак не интегрированный с системой.

> кеш, и хотите от него избавиться?

Я хочу, чтобы кэшем управляла подсистема VMM, а не левая задняя нога ФС, ничего о VMM не представляющая. И чтобы память нормально CoW'илась, а не копировалась при запуске процессов. И чтобы mmap работал нормально.

Вердикт: ext4 живёт на 512Мб, не прося каши, и спокойно протаскивает гигабит, а больше домашнему сторейджу и не уперлось. Success story с ZFS на 512 Мб не видел. Любителей юзать память впустую прошу не беспокоить.

Ответить | Правка | Наверх | Cообщить модератору

275. "Представлен проект OpenZFS, направленный на  унификацию разв..."  –1 +/
Сообщение от Михрютка (ok), 20-Сен-13, 23:23 
> Вердикт: ext4 живёт на 512Мб, не прося каши, и спокойно протаскивает гигабит,
> а больше домашнему сторейджу и не уперлось. Success story с ZFS
> на 512 Мб не видел. Любителей юзать память впустую прошу не
> беспокоить.

ну тащемта как я и предполагал: success story с использованием белаза для поездок в соседний супермаркет я не видел. любителей возить руду из карьера на жд станцию прошу не беспокоить. как-то так, да.

Ответить | Правка | Наверх | Cообщить модератору

286. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +2 +/
Сообщение от AlexAT (ok), 21-Сен-13, 08:56 
> ну тащемта как я и предполагал: success story с использованием белаза для
> поездок в соседний супермаркет я не видел. любителей возить руду из
> карьера на жд станцию прошу не беспокоить. как-то так, да.

Тут сейчас обсуждается вариант малого NAS, угу. Если внимательно тред почитаешь - он начался с андроида. МикроNAS под виртуалкой - по требованиям суть та же эмбедовка, только с другого боку - приложение к основной площадке, которое должно быть максимально скромным и незаметным.

Linux и ext3/4 сейчас легко вкрутить почти на любую железку, не особо жертвуя производительностью этой железки, и не имея надобности ставить овердохуа рам - лишь бы CPU был достаточно вменяемый. В т.ч. на NASы, в телефоны и прочие девайсы.

Как ты думаешь, почему вендоры SOHO NAS в сторону ZFS сейчас (да и на перспективу) не смотрят вообще никак?

А если ты про белазы и кровавые энтерпрайзы - то выдыхай, ZFS там только на солярке в нормальной эксплуатации встречается, да и то в количестве инсталляций на уровне статистической погрешности. Основные игроки - ext3/4 и NTFS. Ну и да - управление кэшем у ZFS совершенно не энтерпрайзное - его надо тюнить, причем вплотную, что применимость ограничивает еще больше. Хотя, тем, кто решился на солярку (я в своё время видел сервер за овердохера баксов под... сквид; и еще одно такое чудо под некую систему управления, навязанное неким вендором, стоит сейчас без дела - чудо оказалось неэксплуатабельным в условиях конкретной задачи, и быстро было заменено собственной системой) - оное имхо безразлично, понты дороже денег.

Ответить | Правка | Наверх | Cообщить модератору

301. "Представлен проект OpenZFS, направленный на  унификацию разв..."  –1 +/
Сообщение от Михрютка (ok), 23-Сен-13, 02:19 
> Тут сейчас обсуждается вариант малого NAS, угу. Если внимательно тред почитаешь -
> он начался с андроида. МикроNAS под виртуалкой - по требованиям суть

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

> Как ты думаешь, почему вендоры SOHO NAS в сторону ZFS сейчас (да
> и на перспективу) не смотрят вообще никак?

ето вы точно мне отвечаете? ето я хоть одним словом уговариваю вас, что ZFS - хорошее решение для 512М памяти и двух-четырех шпинделей? мне кажется, это вы ворвались в тредик с вашим юзкейсом о 512М ОЗУ внутри бесплатного esx и объявили, что для вас ZFS не подходит. хотя вас никто вроде и не убеждал в обратном.

>[оверквотинг удален]
> там только на солярке в нормальной эксплуатации встречается, да и то
> в количестве инсталляций на уровне статистической погрешности. Основные игроки - ext3/4
> и NTFS. Ну и да - управление кэшем у ZFS совершенно
> не энтерпрайзное - его надо тюнить, причем вплотную, что применимость ограничивает
> еще больше. Хотя, тем, кто решился на солярку (я в своё
> время видел сервер за овердохера баксов под... сквид; и еще одно
> такое чудо под некую систему управления, навязанное неким вендором, стоит сейчас
> без дела - чудо оказалось неэксплуатабельным в условиях конкретной задачи, и
> быстро было заменено собственной системой) - оное имхо безразлично, понты дороже
> денег.

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

Ответить | Правка | К родителю #286 | Наверх | Cообщить модератору

302. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +2 +/
Сообщение от AlexAT (ok), 23-Сен-13, 07:35 
> даже и не знаю, что вам ответить на ваш выхлоп. про zfs только на солярисе - это капитанинг
> про статистическую погрешность - это вы выдумали

Ни одной вменяемой статьи про долю рынка конкретной ОС - это как раз "уровень статистической погрешности".

Из того, что удаётся наскрести по сусекам гугла: доля Unix на серверном рынке за 2012 -  12.6%, из них 52% - IBM, еще 36% - HP. Т.е. у бедной солярки не более 12% от 12% - не более 1.5% всего серверного рынка, а там есть еще и другие игроки. Что как бэ подтверждает вывод об "уровне статистической погрешности".

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

Как-то так.

Ответить | Правка | К родителю #301 | Наверх | Cообщить модератору

303. "Представлен проект OpenZFS, направленный на  унификацию разв..."  –2 +/
Сообщение от nagualemail (ok), 23-Сен-13, 13:26 
>[оверквотинг удален]
> рынке за 2012 -  12.6%, из них 52% - IBM,
> еще 36% - HP. Т.е. у бедной солярки не более 12%
> от 12% - не более 1.5% всего серверного рынка, а там
> есть еще и другие игроки. Что как бэ подтверждает вывод об
> "уровне статистической погрешности".
> И - да - речь идёт только о брендированном рынке. А если
> здесь взвесить еще число инсталляций Linux, выполняемых вовсе не маститыми вендорами
> - то сама доля вышеупомянутого рынка оказывается где-то ниже плинтуса (числа
> предлагаю погуглить самому). Еще более снижая долю почти не существующей соляры.
> Как-то так.

А основная часть это сервера с вин ? Кажется я начинаю догадываться кто составял эту статистику ... :)))

Ответить | Правка | К родителю #302 | Наверх | Cообщить модератору

310. "Представлен проект OpenZFS, направленный на  унификацию разв..."  –2 +/
Сообщение от Михрютка (ok), 24-Сен-13, 00:48 
>[оверквотинг удален]
> Из того, что удаётся наскрести по сусекам гугла: доля Unix на серверном
> рынке за 2012 -  12.6%, из них 52% - IBM,
> еще 36% - HP. Т.е. у бедной солярки не более 12%
> от 12% - не более 1.5% всего серверного рынка, а там
> есть еще и другие игроки. Что как бэ подтверждает вывод об
> "уровне статистической погрешности".
> И - да - речь идёт только о брендированном рынке. А если
> здесь взвесить еще число инсталляций Linux, выполняемых вовсе не маститыми вендорами
> - то сама доля вышеупомянутого рынка оказывается где-то ниже плинтуса (числа
> предлагаю погуглить самому). Еще более снижая долю почти не существующей соляры.

вам подсказать, или вы сами увидите, где лажаетесь с выбором метрик?

Ответить | Правка | К родителю #302 | Наверх | Cообщить модератору

342. "Представлен проект OpenZFS, направленный на  унификацию разв..."  –2 +/
Сообщение от Фтщтнь (?), 15-Окт-13, 23:46 
>[оверквотинг удален]
> Нет, я считаю его костылём потому, что это именно костыль - никак
> не интегрированный с системой.
>> кеш, и хотите от него избавиться?
> Я хочу, чтобы кэшем управляла подсистема VMM, а не левая задняя нога
> ФС, ничего о VMM не представляющая. И чтобы память нормально CoW'илась,
> а не копировалась при запуске процессов. И чтобы mmap работал нормально.
> Вердикт: ext4 живёт на 512Мб, не прося каши, и спокойно протаскивает гигабит,
> а больше домашнему сторейджу и не уперлось. Success story с ZFS
> на 512 Мб не видел. Любителей юзать память впустую прошу не
> беспокоить.

ZFS на 256МБ RAM в виртуалке, ЧЯДНТ? Еще один любитель порассуждать о вкусе устриц?

Ответить | Правка | К родителю #273 | Наверх | Cообщить модератору

343. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +/
Сообщение от AlexAT (ok), 16-Окт-13, 20:22 
> ZFS на 256МБ RAM в виртуалке, ЧЯДНТ? Еще один любитель порассуждать о
> вкусе устриц?

И как, шустро ползает? На 256 Mb RAM сама BSD 8/9 с трудом заведется без свопа, не говоря уже о ZFS.

Ответить | Правка | Наверх | Cообщить модератору

352. "Представлен проект OpenZFS, направленный на  унификацию разв..."  –2 +/
Сообщение от nagualemail (ok), 17-Окт-13, 01:06 
>> ZFS на 256МБ RAM в виртуалке, ЧЯДНТ? Еще один любитель порассуждать о
>> вкусе устриц?
> И как, шустро ползает? На 256 Mb RAM сама BSD 8/9 с
> трудом заведется без свопа, не говоря уже о ZFS.

Сам то пробовал или теоретик ?


Ответить | Правка | К родителю #343 | Наверх | Cообщить модератору

350. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +3 +/
Сообщение от Аноним (-), 17-Окт-13, 00:45 
> ZFS на 256МБ RAM в виртуалке, ЧЯДНТ?

К психиатру на прием не записались. Настолько долбануться не каждому удается. А рациональное обоснование такому изворату вы сможете придумать? :)

Ответить | Правка | Наверх | Cообщить модератору

351. "Представлен проект OpenZFS, направленный на  унификацию разв..."  –3 +/
Сообщение от nagualemail (ok), 17-Окт-13, 01:05 
>> ZFS на 256МБ RAM в виртуалке, ЧЯДНТ?
> К психиатру на прием не записались. Настолько долбануться не каждому удается. А
> рациональное обоснование такому изворату вы сможете придумать? :)

Резко похолодало, поциенты нервные, на людей бросаются ...


Ответить | Правка | К родителю #350 | Наверх | Cообщить модератору

430. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +1 +/
Сообщение от Аноним (-), 20-Окт-13, 21:27 
> Резко похолодало, поциенты нервные, на людей бросаются ...

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

Ответить | Правка | К родителю #351 | Наверх | Cообщить модератору

304. "Представлен проект OpenZFS, направленный на  унификацию разв..."  –2 +/
Сообщение от iZEN (ok), 23-Сен-13, 21:03 
Смешные линуксоиды понабежали и сравнивают собственные реализации NTFS (в лице ext* и монструозиной xfs) на 512 МБ ОЗУ с верифицирующейся ZFS, которой нужно на порядок больше в силу её РАСШИРЕННЫХ возможностей. Ой, не могу, держите меня семеро. :))
Ответить | Правка | К родителю #228 | Наверх | Cообщить модератору

305. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +1 +/
Сообщение от AlexAT (ok), 23-Сен-13, 21:25 
Верифицировалась-верифицировалась, да не выверифицировалась.

---

http://lists.freebsd.org/pipermail/freebsd-stable/2013-July/... - проблема ZFS/BSD/mmap, давно (с 2010!!! http://www.dovecot.org/list/dovecot/2010-June/049631.html) известная, и хрен до сих пор пофикшенная. Собственно, что и ожидалось от навесной надстройки между FS и VMM ака ARC. В современных условиях получается неэксплуатабельно, поскольку mmap() не юзает ныне только ленивый.

http://lists.freebsd.org/pipermail/freebsd-fs/2012-November/... - как? Щито? Верификация и непротиворечивость от фатальных сбоев дискового контроллера не спасают? (это такой жесткий капитанинг, ибо всем, кроме упоротых, понятно) Данные записаны успешно, а после записи благополучно потеряны старые? Т.е. в эксплуатации - всё равно разворачивать бэкап, ибо риск потери остаётся. "Тогда зачем платить больше" (с)?

---

Это я к тому, что в эксплуатации по надежности ZFS ни разу не лучше прочих систем, как бы её ни пиарили. Всё равно обязательно держать бэкапы, и всё равно обязательно применение рук при анализе сбоев. Хреновость вижу в том, что она еще и ряд сбоев скрыть пытается, но это уже на вкус и цвет.

Снапшоты и прочие вкусности - это да, пока да. Вон btrfs уже почти production ready (дистры начинают переползать), его активно обезбаживают, нашпиговывают вкусными фичами достаточно модульно (отключите мне кэш для БД выборочно в ZFS?), он не требует никаких навесных костылей для работы, и - самое главное - мейнстримовый, т.е. прекрасно интегрирован в систему.

Ответить | Правка | Наверх | Cообщить модератору

306. "Представлен проект OpenZFS, направленный на  унификацию разв..."  –2 +/
Сообщение от Михрютка (ok), 23-Сен-13, 21:51 
>[оверквотинг удален]
> ZFS/BSD/mmap, давно (с 2010!!! http://www.dovecot.org/list/dovecot/2010-June/049631.html)
> известная, и хрен до сих пор пофикшенная. Собственно, что и ожидалось
> от навесной надстройки между FS и VMM ака ARC. В современных
> условиях получается неэксплуатабельно, поскольку mmap() не юзает ныне только ленивый.
> http://lists.freebsd.org/pipermail/freebsd-fs/2012-November/... - как?
> Щито? Верификация и непротиворечивость от фатальных сбоев дискового контроллера не спасают?
> (это такой жесткий капитанинг, ибо всем, кроме упоротых, понятно) Данные записаны
> успешно, а после записи благополучно потеряны старые? Т.е. в эксплуатации -
> всё равно разворачивать бэкап, ибо риск потери остаётся. "Тогда зачем платить
> больше" (с)?

ггг

google://site:lkml.indiana.edu ext4 data corruption
About 41,400 results (0.10 seconds)

google://site:lists.freebsd.org zfs data corruption
About 4,980 results (0.37 seconds)

"И эти люди запрещают мне ковыряться в носу!"

Ответить | Правка | Наверх | Cообщить модератору

307. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +1 +/
Сообщение от AlexAT (ok), 23-Сен-13, 22:03 
> ггг
> google://site:lkml.indiana.edu ext4 data corruption
> About 41,400 results (0.10 seconds)
> google://site:lists.freebsd.org zfs data corruption
> About 4,980 results (0.37 seconds)
> "И эти люди запрещают мне ковыряться в носу!"

Либо выдача таргетированная, либо кто-то врёт.

--- site:lkml.indiana.edu ext4 data corruption
Результатов: примерно 2 040 (0,11 сек.)
--- site:lists.freebsd.org zfs data corruption
Результатов: примерно 4 980 (0,68 сек.)

Ну и да:

--- site:lkml.indiana.edu ext4
Результатов: примерно 47 400 (0,12 сек.)
--- site:lists.freebsd.org zfs
Результатов: примерно 22 900 (0,32 сек.)

2040/47400 vs 4980/22900

Ответить | Правка | Наверх | Cообщить модератору

308. "Представлен проект OpenZFS, направленный на  унификацию разв..."  –3 +/
Сообщение от Михрютка (ok), 23-Сен-13, 23:34 
>[оверквотинг удален]
> --- site:lkml.indiana.edu ext4 data corruption
> Результатов: примерно 2 040 (0,11 сек.)
> --- site:lists.freebsd.org zfs data corruption
> Результатов: примерно 4 980 (0,68 сек.)
> Ну и да:
> --- site:lkml.indiana.edu ext4
> Результатов: примерно 47 400 (0,12 сек.)
> --- site:lists.freebsd.org zfs
> Результатов: примерно 22 900 (0,32 сек.)
> 2040/47400 vs 4980/22900

а это у вас в настройках гугля стоит галочка "Не показывать жесткое порно"

Ответить | Правка | Наверх | Cообщить модератору

431. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +/
Сообщение от Аноним (-), 20-Окт-13, 21:28 
> а это у вас в настройках гугля стоит галочка "Не показывать жесткое порно"

Ха-ха, использование ZFS во фряхе - да, похоже на BDSM. Да и название системы как бы намекает...

Ответить | Правка | Наверх | Cообщить модератору

312. "Представлен проект OpenZFS, направленный на  унификацию разв..."  –1 +/
Сообщение от iZEN (ok), 27-Сен-13, 23:53 
> Верифицировалась-верифицировалась, да не выверифицировалась.

Помоги лучше человеку: http://www.linux.org.ru/forum/admin/9630280
с потерянным RAID mdadm вместо того, чтобы постоянно приводить ссылки многолетней давности.

Ответить | Правка | К родителю #305 | Наверх | Cообщить модератору

313. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +1 +/
Сообщение от AlexAT (ok), 28-Сен-13, 12:07 
2013 и 2012 - это "многолетняя давность"? Сочувствую. Многолетняя давность только у бага BSD+ZFS+mmap, который с 2010 тянется, и до сих пор не пофикшен. Видимо, просто никому не нужно в реале.

А по ссылке - там надо экстренно высылать выпрямитель рук, а не помогать с массивами. На дисках какая-то каша - NTFS вперемешку с линухами. За такие рецепты (VMWare Player на сервере с виндой, в котором Linux, к которому каким-то образом сырые диски или разделы подмонтированы) надо ссаными тряпками гнать из админов, пока не набедокурили.

Вообще в ветке всё правильно сказали - man mdadm ; man mdadm.conf, и всё будет шоколадно, если RAID не на одном диске весь лежал - видел и такое, когда делают два раздела, между ними - RAID1, а потом удивляются, что при отказе винта на RAID1 данные потерялись. Не говоря уже о том, что производительность такого поделия... ээээ... гкхм...

Ответить | Правка | Наверх | Cообщить модератору

314. "Представлен проект OpenZFS, направленный на  унификацию..."  +1 +/
Сообщение от arisu (ok), 28-Сен-13, 12:22 
> А по ссылке — там надо экстренно высылать выпрямитель рук

поздно. и, кажется, у носителя крепления для рук только на заднице, в других местах не предусмотрено.

Ответить | Правка | Наверх | Cообщить модератору

315. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +/
Сообщение от iZEN (ok), 28-Сен-13, 17:01 
> Верифицировалась-верифицировалась, да не выверифицировалась.
> ---
> http://lists.freebsd.org/pipermail/freebsd-stable/2013-July/... - проблема
> ZFS/BSD/mmap, давно (с 2010!!! http://www.dovecot.org/list/dovecot/2010-June/049631.html)
> известная, и хрен до сих пор пофикшенная.

Да вот же её решение: http://www.dovecot.org/list/dovecot/2010-June/049918.html
Проблема оказалась в кривом коде Dovecot.


> http://lists.freebsd.org/pipermail/freebsd-fs/2012-November/... - как?
> Щито? Верификация и непротиворечивость от фатальных сбоев дискового контроллера не спасают?

Да там не фатальный сбой дискового контроллера, а ошибка адресации пространства диска за пределами 2 TB в драйвере mfi(4) (LSI MegaRAID SAS driver):
http://lists.freebsd.org/pipermail/freebsd-fs/2012-November/...
http://lists.freebsd.org/pipermail/freebsd-fs/2012-November/...

> (это такой жесткий капитанинг, ибо всем, кроме упоротых, понятно) Данные записаны
> успешно, а после записи благополучно потеряны старые? Т.е. в эксплуатации -
> всё равно разворачивать бэкап, ибо риск потери остаётся. "Тогда зачем платить
> больше" (с)?

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

> Это я к тому, что в эксплуатации по надежности ZFS ни разу не лучше прочих систем, как бы её ни пиарили.

Лучше, если сквозная целостность данных поддержана непротиворечивой программной реализацией драйверов. А то так можно дойти до того, что из /dev/random получать всё время одно и то же число независимо от того, сколько раз вызывать.

> Всё равно обязательно держать бэкапы,

Ну ты понял... ;)

> и всё равно обязательно применение рук при анализе
> сбоев. Хреновость вижу в том, что она еще и ряд сбоев
> скрыть пытается, но это уже на вкус и цвет.

А какая ФС не пытается решить аппаратные проблемы своими силами, расскажи, а?

fsck (если работает) в ваших ФС вообще не знает об именах файлов и набьёт потерянные цепочки в /.lost+foud в кучу — сиди и разбирайся по содержимому. :)) В ZFS хотя бы знаешь, что конкретно потеряно среди терабайтов уцелевших данных.

> Снапшоты и прочие вкусности - это да, пока да. Вон btrfs уже
> почти production ready (дистры начинают переползать), его активно обезбаживают, нашпиговывают вкусными фичами достаточно модульно
> отключите мне кэш для БД выборочно в ZFS?

zfs set primarycache=none poolname/rsubdfs
zfs set secondarycache=none poolname/rsubdfs

>, он не требует никаких навесных костылей для работы, и -
> самое главное - мейнстримовый, т.е. прекрасно интегрирован в систему.

ZFS тоже интегрирована в систему и не требует костылей.

Ответить | Правка | К родителю #305 | Наверх | Cообщить модератору

316. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +/
Сообщение от AlexAT (ok), 28-Сен-13, 17:44 
> Да вот же её решение: http://www.dovecot.org/list/dovecot/2010-June/049918.html
> Проблема оказалась в кривом коде Dovecot.

А кривой код в dovecot показать не изволишь? Проблема на самом деле не решена, и по моей ссылке от 2013 года всплывает уже в торрент-клиентах и прочих приложениях. Т.е. "кривой код" не в dovecot, а в реализации ZIL, видимо. На прочих несетевых FS всё работает прекрасно.

Что самое эпичное - в форках соляры тоже всплывает: http://www.kdump.cn/forums/viewtopic.php?id=736 , что, в общем, и не удивительно - на соляре оно такой же костыль:

"ZFS doesn't mix well with mmap(2). This is because ZFS uses the ARC instead of the Solaris page cache. But mmap() uses the latter. So if anyone maps a file, ZFS has to keep the two caches in sync."

> Да там не фатальный сбой дискового контроллера, а ошибка адресации пространства диска
> за пределами 2 TB в драйвере mfi(4) (LSI MegaRAID SAS driver)

Это и есть фатальный сбой контроллера/драйвера. Какой бы "непротиворечивой" ZFS в сферической теории в вакууме ни была - при сбоях той же адресации её ничего уже не спасёт.

> Если драйвер для железки написан криво, то

Хвалёная ZFS должна остаться "непротиворечивой" (основной козырь пиарщиков), нэ? Не остаётся. Значит толку от этой "непротиворечивости" - ровно 0.00.

>> Всё равно обязательно держать бэкапы,
> Ну ты понял... ;)

Именно. Что смысла в ZFS в текущей реализации чуть больше нуля - и так есть масса решений, не требующих угребищных костылей над VMM для своей работы.

> А какая ФС не пытается решить аппаратные проблемы своими силами, расскажи, а?

И какие же аппаратные проблемы пытаются решить ext'ы?

> zfs set primarycache=none poolname/rsubdfs
> zfs set secondarycache=none poolname/rsubdfs

Я сказал для БД, а не для тома. На томе кроме БД еще чего-то быть может.

> ZFS тоже интегрирована в систему и не требует костылей.

Особенно её кэш.

Ответить | Правка | Наверх | Cообщить модератору

317. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +/
Сообщение от iZEN (ok), 28-Сен-13, 18:51 
>> Да вот же её решение: http://www.dovecot.org/list/dovecot/2010-June/049918.html
>> Проблема оказалась в кривом коде Dovecot.
> А кривой код в dovecot показать не изволишь?

Похоже, ты даже по ссылке не прошёл.
///---
Here are fixes:

http://hg.dovecot.org/dovecot-2.0/rev/c24ee1ebb159
http://hg.dovecot.org/dovecot-2.0/rev/b2ffb6846973
---///


> Проблема на самом деле не решена, и по моей ссылке от 2013 года всплывает уже
> в торрент-клиентах и прочих приложениях.

Где конкретно?

> Т.е. "кривой код" не в dovecot, а в реализации ZIL, видимо. На прочих несетевых FS всё работает прекрасно.

С подавляющим большинством программ ZFS работает прекрасно. Может в консерватории кривого прикладного ПО что-то подправить надо?

> Что самое эпичное - в форках соляры тоже всплывает: http://www.kdump.cn/forums/viewtopic.php?id=736

Что "тоже"? По ссылке вообще другая ситуация, связанная с отзывчивостью.

> , что, в общем, и не удивительно - на соляре оно такой же костыль:
> "ZFS doesn't mix well with mmap(2). This is because ZFS uses the
> ARC instead of the Solaris page cache. But mmap() uses the
> latter. So if anyone maps a file, ZFS has to keep
> the two caches in sync."

И правда, неудивительно.

>> Да там не фатальный сбой дискового контроллера, а ошибка адресации пространства диска
>> за пределами 2 TB в драйвере mfi(4) (LSI MegaRAID SAS driver)
> Это и есть фатальный сбой контроллера/драйвера.

Это не сбой, а баг в драйвере.
Если калькулятор при сложении определённых цифр (например, "2") выдаёт неверные результаты ("2+2=5", "2+3=6" и .т.д.), а во всех других случаях ведёт себя адекватно ("3+4=7", "1+5=6" и т.д.), то это не сбой, это БАГ.

> Какой бы "непротиворечивой" ZFS в сферической
> теории в вакууме ни была - при сбоях той же адресации
> её ничего уже не спасёт.

А Ext* спасёт? А Btrfs спасёт? Сомневаюсь.

>> Если драйвер для железки написан криво, то
> Хвалёная ZFS должна остаться "непротиворечивой" (основной козырь пиарщиков), нэ? Не остаётся.

ZFS останавливает работу. Не видел что ли? И даже scrub запустили на смонтированном(!) повреждённом пуле. Сомневаюсь, что такое можно было произвести на искорёженной Ext4.

> Значит толку от этой "непротиворечивости" - ровно 0.00.
>>> Всё равно обязательно держать бэкапы,
>> Ну ты понял... ;)
> Именно. Что смысла в ZFS в текущей реализации чуть больше нуля -
> и так есть масса решений, не требующих угребищных костылей над VMM
> для своей работы.

У ZFS преимущество по управлению томами и квотами. Кроме того, она уменьшает время простоя из-за восстановлений данных из бэкапов, так как известно, какие именно файлы требуется восстановить.

>> А какая ФС не пытается решить аппаратные проблемы своими силами, расскажи, а?
> И какие же аппаратные проблемы пытаются решить ext'ы?

Не придуривайся! Классические ФС на SSD пытаются решить известно какие проблемы, так как CoW у них в зачатке или не реализован совсем.

>> zfs set primarycache=none poolname/rsubdfs
>> zfs set secondarycache=none poolname/rsubdfs
> Я сказал для БД, а не для тома. На томе кроме БД еще чего-то быть может.

Не различаешь файловую систему poolname/rsubdfs, выделенную для СУБД, от тома? Тяжёлый случай. :(
Впрочем, для тома — ZVOL — делается аналогично. Свойства ZFS primarycache и secondarycache для тома тоже действительны.

>> ZFS тоже интегрирована в систему и не требует костылей.
> Особенно её кэш.

Угу. Отдельный кэш на чтение L2ARC и вынесенный ZIL на SSD рулят и педалят так, что не снилось никаким костылям для Ext*. ;)

Ответить | Правка | Наверх | Cообщить модератору

320. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +/
Сообщение от AlexAT (ok), 29-Сен-13, 15:33 
> Похоже, ты даже по ссылке не прошёл.
> ///---
> Here are fixes:
> http://hg.dovecot.org/dovecot-2.0/rev/c24ee1ebb159
> http://hg.dovecot.org/dovecot-2.0/rev/b2ffb6846973
> ---///

Слышал звон, но не знаешь, где он? По твоим двум ссылкам выше ничего, имеющего хоть малейшее отношение к багу ZFS+mmap+dovecot, нет. Там исправления сетевого кода. Учись читать то, что пишешь, прежде чем писать.

> Где конкретно?

Конкретно - сходи сюда:
http://thr3ads.net/freebsd-stable/2013/07/2662417-Help-with-...
Picard/flac, rtorrent

> С подавляющим большинством программ ZFS работает прекрасно. Может в консерватории кривого прикладного ПО что-то подправить надо?

Так и запишем - каждое прикладное ПО надо тестировать на совместимость с ZFS, потому что остальное - работает вовсе не с "подавляющим большинством", а везде. Итого: неэксплуатабельно. Ну, как уже говорил - источник виден: mmap, вот только mmap ныне не юзает разве что ленивый.

> Что "тоже"? По ссылке вообще другая ситуация, связанная с отзывчивостью.

Источник проблемы - один и тот же: костыль над VMM под названием ZIL/ARC. Проблема другая, причина - та же.

> А Ext* спасёт? А Btrfs спасёт? Сомневаюсь.

Не спасёт. Но не надо тогда говорить, что ZFS "защищена". Ни хрена она не защищена, во всяком случае, не более ext/btrfs в данном конкретном случае.

> ZFS останавливает работу. Не видел что ли? И даже scrub запустили на
> смонтированном(!) повреждённом пуле.

А толку? Данные всё равно в заднице - надо доставать из бэкапов.

> Не придуривайся! Классические ФС на SSD пытаются решить известно какие проблемы, так
> как CoW

Не обольщайся. Так как CoW реализован в контроллере, и так, как надо контроллеру. TRIM - это механизм связи между ФС и контроллером, вполне естественный в данном случае. В случае ZFS получим CoW-поверх-контроллерного_CoW, а это вполне себе снизит эффективность работы второго по мере заполнения драйва без очистки (даже при наличии TRIM). Так что ZFS на SSD только усложняет ситуацию. Для флешей есть F2FS, к слову.

> Не различаешь файловую систему poolname/rsubdfs, выделенную для СУБД, от тома?

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

Спрошу в лоб тогда: таки для отдельных файлов выключить CoW реально, или нет? Надо редко, но надо. Разработчики BTRFS вполне себе понимают, зачем это может понадобиться.

> Угу. Отдельный кэш на чтение L2ARC и вынесенный ZIL на SSD рулят
> и педалят так

Что стоимость решения увеличивается раза в 2-3, при аналогичной производительности. А если выкинуть костыли и взять родную для ZFS ОС - то и раз в 20-30.

Ответить | Правка | Наверх | Cообщить модератору

309. "Представлен проект OpenZFS, направленный на  унификацию разв..."  –1 +/
Сообщение от nagualemail (ok), 23-Сен-13, 23:44 
> Смешные линуксоиды понабежали и сравнивают собственные реализации NTFS (в лице ext* и
> монструозиной xfs) на 512 МБ ОЗУ с верифицирующейся ZFS, которой нужно
> на порядок больше в силу её РАСШИРЕННЫХ возможностей. Ой, не могу,
> держите меня семеро. :))

Их поделия еще и отстают от NTFS из-за отсутсвия вменяемого дефрагментатора :)))

Ответить | Правка | К родителю #304 | Наверх | Cообщить модератору

353. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +/
Сообщение от Аноним (-), 17-Окт-13, 01:09 
> Их поделия еще и отстают от NTFS из-за отсутсвия вменяемого дефрагментатора :)))

Да, вы по дефрагментации NTFS великий эксперт.

Ответить | Правка | Наверх | Cообщить модератору

332. "Представлен проект OpenZFS, направленный на  унификацию разв..."  +/
Сообщение от анонизмус (?), 02-Окт-13, 21:03 
Ну выпускает же в Пиндостане мотомастерская мотоциклы с автомобильными двигателями...
Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру