Обсуждение (http://phoronix.com/forums/showthread.php?74697-EXT4-Data-Co...) возможный путей предотвращения повторения ситуации с появлением (http://www.opennet.me/opennews/art.shtml?num=35164) опасных проблем в реализации Ext4, вызванных продолжающимся наращиванием функциональности данной ФС, привлекло (http://phoronix.com/forums/showthread.php?74697-EXT4-Data-Co...) к себе внимание Теодора Тцо (Theodore Ts'o), создателя Ext4, который дал несколько пояснений относительно процесса разработки ФС и ответил на предложение заморозить код Ext4 и приступить к реализации Ext5.По словам Теодора Тцо идея перебросить все силы на разработку Ext5 вместо постоянной доработки Ext4 у разработчиков уже была, но такой переход принесет больше вреда, чем пользы. Во-первых, Ext4 продолжает постоянно развиваться, однако все серьезные изменения попадают в код файловой системы на начальном этапе только в виде экспериментальных функций, которые можно включить создав или смонтировав файловую систему с определенными флагами. Поэтому, пользователям, которые хотят поэкспериментировать, могут сделать это прямо сейчас, остальные же могут жить со стандартной уже отлаженной функциональностью.
Во-вторых, создание еще одной файловой системы приведет к большим затратам на исправление ошибок. Каждая новая ошибка, найденная в одной файловой системе может существовать и в другой, поэтому на их поиск и устранение придется тратить больше времени. В качестве примера Теодор привел случай с ошибкой, которая была найдена в Ext3, но не обнаружилась в Ext2, хотя силы на ее поиск в последней пришлось потратить.
Кроме того, Теодор подчеркнул, что заморозка кода не избавит от возможных ошибок, так как они могут быть найдены спустя месяцы и годы использования файловой системы. Например, недавно была найдена ошибка в файловой системе Ext4 во время перевода на Ext4 сотен тысяч машин в дата-центрах Google. Как оказалась та же ошибка присутствует и в Ext3, но она не была обнаружена за 10 лет ее существования, несмотря на повсеместное использование в промышленных масштабах.
URL: http://www.phoronix.com/scan.php?page=news_item&px=MTIxNTE
Новость: http://www.opennet.me/opennews/art.shtml?num=35178
Не вижу повода для беспокойства. Во всяком случае такого повода, чтобы взять и всё поменять. В прошлый раз серьёзная регрессия в ext4 была в 2009 году (Delayed allocation), почти 4 года назад. И такие регрессии бывают не только в этой части ядра (почитайте новость о любом минорном релизе). Да и при написании ext4 и многолетнем тестировании такие ошибки возникали постоянно, и как и тогда их быстро находят и оперативно чинят - специалисты не пропали.
Да его и нет. Об этом много говорят только потому, что ext4 самая распространенная, во всех остальных ФС тоже есть ошибки.
Баг очень редко возникающий, но сейчас на него форумные оналитеги спишут все, и посыпавшийся диск, и сбой в RAM, и развал часовни 17 века. "Вот я сердцем чую, это все проклятый баг EXT4. Доколе!!!1!!!"
А 12309 уже не актуально?
> А 12309 уже не актуально?Как минимум 1 вариант оного изловили и с помпой зашибли. Там где много грязных страниц и тормозной носитель.
> Как минимум 1 вариант оного изловили и с помпой зашибли. Там где
> много грязных страниц и тормозной носитель.Ну так то реально баг был. А в современной околинуксовой культуре под "12309" подпадают любые тормоза и глюки (неплохо еще при этом добавить, что в них виноват Поттеринг с его бинарными конфигами в XML) :D
> "12309" подпадают любые тормоза и глюки (неплохо еще при этом добавить,Ну так ламерье вечно любит списывать все вселенское зло на 1 баг без разбора. Сдох кот у соседа - 12309, подорожали продукты - 12309, скорел БП, осыпался винч? Это все 12309 проклятый.
Уважаемый, здесь речь не о регрессиях...
Ну 10 лет и быстро находят - это оксюморон. Написание любой многопоточной системы на мощной нагрузке - жуткий гемор. Уловить случай гонки на уровне ядра - нужен батальон гуру. У меня слетала ext4 на потоковой записи c тюнера - но это из категории "нефиг бетой баловаться".
> потоковой записи c тюнера - но это из категории "нефиг бетой баловаться".А я бетой балуюсь (-rc ядрами например) и ничего не слетает пока даже :). Но я знаю на что иду.
теперь вспомним что ext4 был фактически подарен после 4х лет тестирования в промышленных маштабах.
и только 2 фичи с тех пор серьезно добавлены - это online defrag и delayed allocation - от которых авторы ext4 отказались, и в одной из них нашли регресию...
Нет чтобы взяться за Reiser4, создают уже Ext5. Ну вот никак ни пойму, ну почему всем до Ext есть дело, а до одной и с самых ярких и удачных, с позиции архитектуры, нет дела???
http://en.wikipedia.org/wiki/Worse_is_better
А что Ext4 в реализации проще чем Reiser4?
"Проще" это сложное, комплексное понятие.Например, намного проще для всех, когда существует несколько разработчиков, которые понимают данный код; более того, которые работают фулл-тайм на зарплате именно ради поддержки этого кода. Сравни это с допиливанием патчей в свободное (от универа) время.
Проще переходить с extN-1 на extN тем, кому это надо, а это надо подавляющему большинству.
Распространённость решения приводит к тому, что оно хорошо интегрируется: есть *работающая* поддержка в специальных программных решениях, подразумевающая высокую надёжность этих решений. А это делает работу проще тем, кто администрирует системы.
> А что Ext4 в реализации проще чем Reiser4?В целом куда более простая штука. По сути ext3 заапгрейженный экстентами.
>> А что Ext4 в реализации проще чем Reiser4?
> В целом куда более простая штука. По сути ext3 заапгрейженный экстентами.когда=то ext4 назывался ldiskfs, и одной не без известной конторе надоело тягать стопки патчей - после чего их влили в ядра с kernel.org.
> когда=то ext4 назывался ldiskfs, и одной не без известной конторе надоело тягать
> стопки патчей - после чего их влили в ядра с kernel.org.Как я понимаю, ext4 сильно базируется на ext3. А если почитать это сообщение то создается что все заслуги принадлежат совсем другим лицам. По-моему такая формулировка не совсем честна: относительно ext3 там нового не так уж и много. Нет, есть очень удачные плюшки типа экстентов, которые основательно разгоняют античный дизайн. Но ничего такого сверхъестественного за что можно было бы все заслуги приписать только одной конторе проигнорировав заслуги всех остальных. Мне это видится как-то так. Я не прав?
> надоело тягать стопки патчейК слову о пользе. А был бы внутриядерный ABI зафиксирован, так бы и чесались стоя ;)
к слову решение о вливании было принято еще во время 2.4 с его относительно стабильным API.
кроме того портирование было всегда по ядрам дистрибутивов - где даже ABI стабильный.так что выстрел мимо. глупо так попадаться и показывать свою не образованность.
> так что выстрел мимо.(пожимая плечами) Так надоело или не надоело?
Надоело - но с стабильностью API это было не связано (на что было попытка указать).
А.
> не образованность.FAIL однако.
А то, анонимчеги всех научат уму разуму :D
> http://en.wikipedia.org/wiki/Worse_is_betterДа, и там же на примере MIT описан и подход академиков. Чреватый тем что выпуск продукта не состоится никогда или то что получится будет страшным ужасом. Ибо эти чудаки совершенно кладут на сложность. Сразу видно академиков которые класть хотели на фактический результат. Ну и что что не ездит? Зато концептуально.
>Ну вот никак ни пойму, ну почему
> и с самых ярких и удачных, с позиции архитектуры, нет дела???...и в третий раз накинул Старик на вентилятор...
Зачем рассуждать о вещах, которые вы не понимаете?
> Нет чтобы взяться за Reiser4Берись, разрабатывай. Толковых разработчиков не хватает. Только не говори мне, что ты только потрендеть горазд.
Во первых прочтите новость, никто не создает EXT5 - спите спокойно.
Во вторых по поводу более удачного дизайна Reiser4(Dancing tree): "cases of unexpected shutdown, incomplete data writes, and other occurrences that may prevent the final (balanced) transaction from completing. In general, dancing trees will pose a greater difficulty for data recovery from incomplete transactions than a normal tree" (c)
> a greater difficulty for data recovery from incomplete transactions than a normal tree" (c)Куда уж greater, если у третьего рейзера fsck может найти неправильное дерево и в результате рахъ....ть том нафиг? При том это не баг, это known issue дизайна. Ха.
> Куда уж greater, если у третьего рейзера fsck может найти неправильное дерево
> и в результате рахъ....ть том нафиг? При том это не баг,
> это known issue дизайна. Ха.Сколько раз такое было, а том цел, и данные на нем тоже.
> Сколько раз такое было, а том цел, и данные на нем тоже.Эталонная иллюстрация - авторы aMule и их сервак. На форуме по-моему до сих пор можно найти что они думают про рейзер и его средства восстановления. А если гуглануть по теме - можно найти много интересного. В частности - что авторы в курсе о проблеме и даже описывают минимум 1 сценарий когда это может произойти: если на "починяемом" томе лежал образ иной ФС reiser, например - деревья могут выдернуть из него. Разумеется починяемый том будет полностью факапнут. Авторы в курсах проблемы. Ответ - "не храните образа дисков с рейзером на рейдере". Ну вот так вот.
> и его средства восстановленияЕсли даже рейзер не научил их делать бэкапы, медицина бессильна
> Если даже рейзер не научил их делать бэкапы, медицина бессильнаБэкапы это замечательно, но все-таки fsck добивающий том вместо починки, при том что авторы оного даже знают что именно может это вызвать но не чинят - это как-то не всем нравится.
>> Если даже рейзер не научил их делать бэкапы, медицина бессильна
> Бэкапы это замечательно, но все-таки fsck добивающий том вместо починки, при том
> что авторы оного даже знают что именно может это вызвать но
> не чинят - это как-то не всем нравится.nagual, залогинься.
> nagual, залогинься.Это 294 был. Да, я гуглил по теме и нашел непропорционально много факапов рейзера, предъяв к fsck и объяснение оных факапов от собственно рейзеровских авторов, рассказавших что мол, положение дерева - не фиксировано, так что тулза ищет деревья и если тулза набредет не на то дерево - том будет раздолбан в хлам. Потому что это было не его дерево и оно совсем не стыкуется с тем что фактически есть, откуда и полный self-destruct ФС. Как я понял, с тех пор никто ничего по этому поводу не предпринимал. Ну, пометили как known issue и угомонились :)
> Куда уж greater, если у третьего рейзера fsck может найти неправильное дерево
> и в результате рахъ....ть том нафиг? При том это не баг,
> это known issue дизайна. Ха.Та же херня с LVM - не храните LVM на LVM :))
> Та же херня с LVM - не храните LVM на LVM :))Пруф?
>> Та же херня с LVM - не храните LVM на LVM :))
> Пруф?лор
> лорОн большой и срача там много. Конкретнее и с пруфами нельзя ли? А то для начала, для fsck lvm - вообще никто. Он оперирует файловой системой, а кто и как ее разложил - не его дело.
>> лор
> Он большой и срача там много. Конкретнее и с пруфами нельзя ли?
> А то для начала, для fsck lvm - вообще никто. Он
> оперирует файловой системой, а кто и как ее разложил - не
> его дело.На тот топик уже раз 5 линк кидали, у вас память глючит ?
Вы я вижу эксперт по архитектуре файловых систем.
Не взять Reiser4 потому что его даже поддерживать некому.
Не взять Reiser4 потому что не нужна модульная fs.
Прям все дураки в Kernel Team и не берут чудесную fs.
> Прям все дураки в Kernel Team и не берут чудесную fs.Ну разумеется! Ведь намного считать что "все пи...сы, а вот %s - ДАртаньян".
> Ну разумеется! Ведь намного считать что "все пи...сы, а вот %s - ДАртаньян".printf("все пи...сы, а вот %s - ДАртаньян", "Эдуард Шишкин")?
> printf("все пи...сы, а вот %s - ДАртаньян", "Эдуард Шишкин")?Вместо Эдуард Шишкин должна быть переменная, т.к. данным шаблоном оперирует не только он к сожалению :)
> Вместо Эдуард Шишкин должна быть переменная, т.к. данным шаблоном оперирует не только он к сожалению :)Тео Цо и Крис Мейсон вроде в таких высказываниях не замечены.
> Тео Цо и Крис Мейсон вроде в таких высказываниях не замечены.Зато на опеннете например этот шаблон крайне популярен. У упомянутых то хватит ума не выставляться дураками. Но не все же такие умные :)
Одна лишь здесь достойная причина, не кому поддерживаеть, а все остальные просто не оправдание...
Вот некому не вперся Reiser4, не freebsd не minix да вообще некому.
> Вот некому не вперся Reiser4, не freebsd не minix да вообще некому.Так у этих сроду ресурсов ни на что нет. Учтя что доделывать это серьезно напрягает даже линуксоидов, упомянутые уж точно смогут что-то такое не в этой жизни и не в этой галактике.
> Вот некому не вперся Reiser4, не freebsd не minix да вообще некому.freebsd, minix и прочие подобные проекты не смогут допилить даже то, что им жизненно необходимо. Так что не показатель.
>> Вот некому не вперся Reiser4, не freebsd не minix да вообще некому.
> freebsd, minix и прочие подобные проекты не смогут допилить даже то, что
> им жизненно необходимо. Так что не показатель.Разработчики freebsd неграмотные и не читают всяких анонимусов а потому не знают что такие фичи как Reiser4 жизненно необходимы в bsd :)))
> Разработчики freebsd неграмотные и не читают всяких анонимусов а потому не знают что такие фичи как Reiser4 жизненно необходимы в bsd :)))При чем здесь Reiser4? Вот отсутствие полноценной виртуализации - really makes freebsd sucks. Но - не могут. Ни из солярки зоны, ни из линукса KVM.
>> Разработчики freebsd неграмотные и не читают всяких анонимусов а потому не знают что такие фичи как Reiser4 жизненно необходимы в bsd :)))
> При чем здесь Reiser4? Вот отсутствие полноценной виртуализации - really makes freebsd
> sucks. Но - не могут. Ни из солярки зоны, ни из
> линукса KVM.Было бы нужно - сделали бы.
> Было бы нужно - сделали бы.Ну так о чем и речь. В серьезных применениях платформа мало кому интересна.
> Было бы нужно - сделали бы.Ну дык, ресурсов на разработку - нет, скопировать готовенькое со всеми потрохами - неоткуда. Вот и остается вопить на форумах, стуча себя пяткой в грудь что виртуализация не нyжна. Ну а энтерпрайзы повертели пальцем у виска да свалили на пингвины.
>> Было бы нужно - сделали бы.
> Ну а энтерпрайзы повертели пальцем
> у виска да свалили на пингвины.Кому нужно стабильно то vmware. Видал я как с kvm работают на дебиане - колются давятся плачут но жрут :))))
> Кому нужно стабильно то vmware.Спасибо, конечно, но он стоит денег. При том что у меня KVM нахаляву в системе есть - я что, дурак чтоли - платить вмварщикам за их блобье?
> Видал я как с kvm работают на дебиане - колются давятся плачут но жрут :))))
На дебиане с их древними ядрами и неизвестной квалификацией админов - хз, а я на регулярной основе гоняю пачки KVMных виртуалок в не сильно древних убунтах. Нормально работает. Если что, я видел туеву хучу гипервизоров и контейнеров всех мастей - могу сравнивать. Вполне нормальный гипервизор.
> Спасибо, конечно, но он стоит денег.не только это. вот ещё забавка:
http://www.intelliadmin.com/index.php/2008/07/vmwares-insane.../
для пруфа, что не протухло:
http://www.vmware.com/download/eula/player_download.html
http://www.vmware.com/download/eula/esx_server.html
дальше интересующиеся найдут сами.чо, как, есть желающие ещё в это вляпываться?
>> Спасибо, конечно, но он стоит денег.
> не только это. вот ещё забавка:
> http://www.intelliadmin.com/index.php/2008/07/vmwares-insane.../
> для пруфа, что не протухло:
> http://www.vmware.com/download/eula/player_download.html
> http://www.vmware.com/download/eula/esx_server.html
> дальше интересующиеся найдут сами.
> чо, как, есть желающие ещё в это вляпываться?А что там не так в двух словах ?
> А что там не так в двух словах ?ты обязан хранить данные по тому, как используешь продукты vmware как минимум за два года, и ребята из вмвари в любой момент по желанию левой пятки могут к тебе прийти и сделать полный аудит твоей техники и использования их продуктов — на предмет «а вдруг ты что-то не так сделал, гад?!» и отказаться нельзя, потому что ты по лицензии согласился, когда ставил/покупал.
>> Спасибо, конечно, но он стоит денег.
> не только это. вот ещё забавка:
> http://www.intelliadmin.com/index.php/2008/07/vmwares-insane.../
> для пруфа, что не протухло:
> http://www.vmware.com/download/eula/player_download.html
> http://www.vmware.com/download/eula/esx_server.html
> дальше интересующиеся найдут сами.
> чо, как, есть желающие ещё в это вляпываться?Срочная новость - яша сдох !!!
> не только это. вот ещё забавка:Кэпу присуждается однозначный EPIC WIN за внимательность и дотошность. Крутота! :)
> чо, как, есть желающие ещё в это вляпываться?
Вот nagual пусть и хранит данные для аудитчиков из вмвари. Знаешь, после таких копирастических лицензий визги о несвободе GPL выглядят особенно умильно :). Не хочу ничего сказать но мне намного проще выложить сорц и даже состав материала моих трусов, если надо, чем страдать настолько эпическим копирастическим маразмом.
> Кэпу присуждается однозначный EPIC WIN за внимательность и дотошность. Крутота! :)справедливости ради — это ребята на maemo.org дотошные. а я, как нормальный кэп, просто принёс это сюда.
> справедливости ради — это ребята на maemo.org дотошные. а я, как нормальный
> кэп, просто принёс это сюда.Справедливости ради, ты это там нашел хотя-бы. В любом случае, очень полезное наблюдение :)
> Разработчики freebsd неграмотные и не читают всяких анонимусов а потому не знают
> что такие фичи как Reiser4 жизненно необходимы в bsd :)))Так я и говорю - им бы свои проблемы разгрести, не то что чужие.
> Вы я вижу эксперт по архитектуре файловых систем.
> Не взять Reiser4 потому что его даже поддерживать некому.
> Не взять Reiser4 потому что не нужна модульная fs.
> Прям все дураки в Kernel Team и не берут чудесную fs.Вопрос к Ыксперту - подскажите библиотеку - функцию которая позволит например удалить блок в середине файла не перечитывая перезаписывая хвост ? :))
> Вопрос к Ыксперту - подскажите библиотеку - функцию которая позволит например удалить
> блок в середине файла не перечитывая перезаписывая хвост ? :))В Linux hole punching делается как-то так: http://lwn.net/Articles/415889/
Ну а найти в какой либе живет fallocate() будет твоим домашним заданием :)
>> Вопрос к Ыксперту - подскажите библиотеку - функцию которая позволит например удалить
>> блок в середине файла не перечитывая перезаписывая хвост ? :))
> В Linux hole punching делается как-то так: http://lwn.net/Articles/415889/
> Ну а найти в какой либе живет fallocate() будет твоим домашним заданием
> :)fallocate этож не то :)
> fallocate этож не то :)Я по-моему предельно ясно ткнул на сообщение в LWN где показано что добавили новые флаги к этому сисколу и стало как раз то: освобождение блоков в середине файла без какой либо перетряски всего остального. Как заказывали. Оно в принципе и блочному сторажу потом еще и TRIM может скинуть по этому поводу на другом уровне, чтоб накопитель мог почистить неиспользуемые блоки. Называется эта технология "hole punching", в пингвине данное расширение сискола - точно есть. Понимается довольно большим списком ФСов на данные момент, а в 3.7 ядре это расширение запилили и в btrfs до кучи. Как подобные финты ушами в *BSD делать - а это вы сами разбирайтесь. Вот и посмотрим заодно у кого мозгов больше: у убунтушников или у пользователей BSD :)
//Да, если что я хоть и убунтуец, но подергать сисколы совсем не против :)
>[оверквотинг удален]
> Как заказывали. Оно в принципе и блочному сторажу потом еще и
> TRIM может скинуть по этому поводу на другом уровне, чтоб накопитель
> мог почистить неиспользуемые блоки. Называется эта технология "hole punching", в пингвине
> данное расширение сискола - точно есть. Понимается довольно большим списком ФСов
> на данные момент, а в 3.7 ядре это расширение запилили и
> в btrfs до кучи. Как подобные финты ушами в *BSD делать
> - а это вы сами разбирайтесь. Вот и посмотрим заодно у
> кого мозгов больше: у убунтушников или у пользователей BSD :)
> //Да, если что я хоть и убунтуец, но подергать сисколы совсем не
> против :)posix_fallocate точно не оно но ладно. А выделяет блок любой длины или по размеру блока фс ? ;)
Кстати а как обратная функция называется - вырезать из середины файла блок произвольной длины в другой файл ?
> posix_fallocate точно не оно но ладно.Это расширение сискола под новую фичу. Да, это не совсем стандартно. Но собственно стандартная семантика доступа и не подразумевает никакого выгрызания дырок посреди файлов. В общем то это сильно нишевая штука нужная сильно местами. Но если вы этого хотите - нате.
> А выделяет блок любой длины или по размеру блока фс ? ;)
А это уже программер сам как-нибудь должен в апликухе, если оно ему надо.
> Кстати а как обратная функция называется - вырезать из середины файла блок
> произвольной длины в другой файл ?А тут уже одним сисколом не отвертишься, понадобится программа которая их дернет в произвольном порядке. В первом приближении таковым можно посчитать обычный dd которым вы так козыряли ;). Если за каким-то надо еще и дестроить то что он скопировал - ну, придется допатчить. Правда я не понимаю нафиг это надо, но...
>> А выделяет блок любой длины или по размеру блока фс ? ;)
> А это уже программер сам как-нибудь должен в апликухе, если оно ему
> надо.Разве это не зависит от архитектуры конкретной фс ?
> А тут уже одним сисколом не отвертишься, понадобится программа которая их дернет
> в произвольном порядке. В первом приближении таковым можно посчитать обычный dd
> которым вы так козыряли ;). Если за каким-то надо еще и
> дестроить то что он скопировал - ну, придется допатчить. Правда я
> не понимаю нафиг это надо, но...Нужно например удалить блок в середине файла, не удаляя сам файл.
> Разве это не зависит от архитектуры конкретной фс ?А вот это и будет головняком программера апликухи - определить что и как в фиг знает какой ФС. Стандартных вызовов для этого вроде как нет. Я о таковых не в курсе во всяком случае.
>> не понимаю нафиг это надо, но...
> Нужно например удалить блок в середине файла, не удаляя сам файл.Смотря что понимать под удалить.
1) Заменить содержимое другим, бесполезным для недругов: делается через seek в нужную позицию + write по размеру блока.
2) Если же хочется просто отдать место в файловую систему а там она пусть сама протирает это когда захочет - это и есть hole punching. Де-аллокация блока в середине файла. ФС может считать это незанятым местом и юзать как хочет.
> Смотря что понимать под удалить.
> 1) Заменить содержимое другим, бесполезным для недругов: делается через seek в нужную
> позицию + write по размеру блока.
> 2) Если же хочется просто отдать место в файловую систему а там
> она пусть сама протирает это когда захочет - это и есть
> hole punching. Де-аллокация блока в середине файла. ФС может считать это
> незанятым местом и юзать как хочет.Нужно уменьшить размер файла на длину удаляемого блока.
> Нужно уменьшить размер файла на длину удаляемого блока.Поскольку это пересекается с sparse файлами, надеюсь что мсье в курсе что есть sparse и как получается что 100500Гб файл может занимать всего 10Мб на диске. Ну вот hole punch это инверсное действие. Занимаемое место сокращается, т.к. блоки отдаются ФС. А логический размер остается как и был. То-есть, если выкусили 5Мб, файловая система получит их назад и файл будет занимать по факту лишь 5Мб. Хотя логический размер в 100500Гб у него останется. Файл делается "более sparse".
Кстати posix_fallocate() так не умеет. Линевый fallocate() - расширенная версия, через которую можно posix_fallocate() забабахать в 2 счета, но у него есть как аллокация так и деаллокация. Что довольно логично. Просто POSIX ничего не знает о sparse файлах и сами по себе sparse являются следствием того что стандарт никак не обязывает ФС что-либо реально выделять под некий файл просто на основании того что его создали и возжелали чтобы это было нечто размером в 100500Гб. Файловая система имеет полное право выделять фактическое место как-нибудь потом и это ее внутренее дело. Если в сторону создания sparse-ов можно считерить не выехав за рамки posix, то вот с деаллокацией и разреживанием файлов так уже не получится. В posix тупо нет сисколлов через которые так можно сделать, ни с читерством ни без.
Если же речь была о том чтобы урезать и логический размер файла (при наличии sparse это довольно декларативная цифра и оно не так уж и актуально) - тогда да, придется вырубить блок и присобачить хвост файла его фактическим перемещением. Не потому что иначе запрещают законы физики и логики, а потому что в posix опять же IIRC нет каких либо сисколов для того чтобы внятно запросить данную операцию. Хотя чисто технически я вполне могу себе представить как какой-нибудь CoW вообще не будет кантовать при этом данные и оформит это как просто измененный вариант метаданных, описывающих размещение файла с поправкой на "выпавший" или "урезанный" блок. Да и обычный дизайн в принципе мог бы. Просто метаданные описывающие размещение придется перестраивать. Основная проблема в том что для такого нет рукояток. Видимо не столь частая операция чтобы кому-то понадобилось.
>[оверквотинг удален]
> хвост файла его фактическим перемещением. Не потому что иначе запрещают законы
> физики и логики, а потому что в posix опять же IIRC
> нет каких либо сисколов для того чтобы внятно запросить данную операцию.
> Хотя чисто технически я вполне могу себе представить как какой-нибудь CoW
> вообще не будет кантовать при этом данные и оформит это как
> просто измененный вариант метаданных, описывающих размещение файла с поправкой на "выпавший"
> или "урезанный" блок. Да и обычный дизайн в принципе мог бы.
> Просто метаданные описывающие размещение придется перестраивать. Основная проблема в
> том что для такого нет рукояток. Видимо не столь частая операция
> чтобы кому-то понадобилось.Для быстрого создания условий тестирования быстродейтсвия файловой системы в условиях максимальной фрагментации возможны два варианта - с одним файлом большим файлом и множеством мелких. Итак если с одним большим - осуществляем операции записи и чтения на тестируемый диск от 0% заполненности файлами до 100% и вычисляем средние скорости чтения и записи. Как только скорости чтения и записи перестануть падать, считаем фрагментацию максимальной а скорости результирующими для данной фс. На самом деле сложнее: Если пишем то пишем вставляя в середину файла с произвольным смещением от начала и произвольной длины блок. Если удаляем блок то не удаляем его совсем а вырезаем из середины с произвольным смещением и произвольной длиной и потом добавляем ео в конец. Назовите функции которые позволят это реализовать ?
Это нужно как минимум в бд и торрентах ...
> Для быстрого создания условий тестирования быстродейтсвия файловой системы в условиях
> максимальной фрагментации возможны два варианта -Не вижу, как это напрямую к sparse файлам и аллокации-деаллокации относится.
> с одним файлом большим файлом и множеством мелких.
Это весьма разные варианты. В первом случае основная нагрузка - на поведение аллокатора и его способность выруливать в сложных ситуациях. Во втором - нагрузка на способности ФС интенсивно работать с метаданными, тогда как аллокатору особо не на чем надрываться.
> Итак если с одним большим - осуществляем операции записи и чтения на тестируемый
> диск от 0% заполненности файлами до 100% и вычисляем средние скорости чтения и записи.В принципе это - вполне валидный бенч. Хоть и сферический в вакууме, но он может показать умения аллокатора ФС работать в сложных условиях. Кроме этого однако есть еще разница какими порциями и как файл дописывался. Влияет на объем метаданных описывающих размещение файла, etc.
И стоит учесть что разные ФС имеют разные свойства и CoW - based будут себя вести
> Как только скорости чтения и записи перестануть падать, считаем фрагментацию
> максимальной а скорости результирующими для данной фс.ИМХО логичнее скармливать ФС одинаковый набор операций. И посмотреть как ФС с ним справится. А то сравнивать неодинаковый набор операций - это сравнение ежа с ужом. Из такого результата никаких особых выводов сделать не получится. Потому что в этом случае никак не учитывается способность ФС бороться с фрагментацией. Может, одна ФС чертовски фрагментируется за 5 минут, а другая за 2 дня издевательств. В реальном мире фрагментация ФС редко достигает максимума когда "хуже уже не будет", т.к. для этого нужны совсем запредельные условия и безбашенный админ. Бенч все-таки должен иметь какую-то практическую ценность.
> На самом деле сложнее: Если пишем то пишем вставляя в середину файла
> с произвольным смещением от начала и произвольной длины блок.IIRC, в семантике POSIX )и большинстве иных похожих по смыслу), файлы умеют расти только с хвоста. Запись в середину перезаписывает то что там было, не раздвигая файл а переписывая содержимое. Увеличить размер можно лишь дописав в хвост. Просто потому что как обычным файловым системам было бы очень напряжно как-либо оформить "раздвигание" файла.
Для классики перезапись файла в середине - вообще ни о чем: оно от этого фрашментироваться не станет. Для CoW это может заставить ФС сорить фрагментами-выносками. В том числе и по этой причине CoW в чистом виде не ахти для баз данных. По поводу чего можно предсказать что на подобном тесте классики будут лучше себя ощущать. В этом месте приходит понимание нафига оракловый архитект предусмотрел возможное отключение CoW в btrfs. Оно сможет стать "как бы классикой" если это реально приспичило ;). Да, это лишает плюшек CoW но базам данных эти плюшки скорее вредны чем полезны, т.к. активно клещатся с их журналом и идеей атомарных транзакций.
> Если удаляем блок то не удаляем его совсем а вырезаем из середины с произвольным
> смещением и произвольной длиной и потом добавляем ео в конец.Мсье, в posix-овской семантике (как и в большинстве иных) такое не предусмотрено. Там урезать размер файла можно только отбрасыванием его хвоста. Потому что операция "сдвигания" файлов не особо проста в реализации. Особенно в ФС эпохи когда POSIX только формировался.
> Назовите функции которые позволят это реализовать ?
Ой, до мсье кажется начинает доходить что в posix нет таких сисколлов.
> Это нужно как минимум в бд и торрентах ...Там это делается не совсем так как вы описали. И кстати по этому поводу есть ряд ограничений. Например, файл базы данных при активной работе с БД растет со временем (если не преаллоцирован заранее с запасом, конечно). И даже если удалить половину записей в таблице - это еще совсем не означает что файл можно будет взять и уменьшить.
...в этом месте мы до кучи начинаем догадываться нафига в базах данных есть операция дефрагментации/vacuum/кто там как еще это действо у себя обзывает и почему БД уменьшаются только после этой операции как правило :). А торренты - они предмет простой. Получили блок - запись в файл по нужному смещению. А преаллокация - по сути выбор между тем что хвост будет отрастать "как получится" или файл заранее будет заказан на полный размер. при том quick преаллокация - это мягкий хинт для ФС что "а вот мы собираемся сделать файл такого размера", а full - фактическая запись файла и потом перезапись блоков по мере скачки. Для классики так лучше. CoW - скорее даже ухучшит картину.
>> Для быстрого создания условий тестирования быстродейтсвия файловой системы в условиях
>> максимальной фрагментации возможны два варианта -
> Не вижу, как это напрямую к sparse файлам и аллокации-деаллокации относится.Мы не обсуждаем сферических коней в вакууме - пофиг как оно там внутри работает ...
>> с одним файлом большим файлом и множеством мелких.
> Это весьма разные варианты. В первом случае основная нагрузка - на поведение
> аллокатора и его способность выруливать в сложных ситуациях. Во втором -
> нагрузка на способности ФС интенсивно работать с метаданными, тогда как аллокатору
> особо не на чем надрываться.Да и интересны оба.
>> Итак если с одним большим - осуществляем операции записи и чтения на тестируемый
>> диск от 0% заполненности файлами до 100% и вычисляем средние скорости чтения и записи.
> В принципе это - вполне валидный бенч. Хоть и сферический в вакууме,
> но он может показать умения аллокатора ФС работать в сложных условиях.
> Кроме этого однако есть еще разница какими порциями и как файл
> дописывался. Влияет на объем метаданных описывающих размещение файла, etc.Реальный бенч, реальные файлы ничего в вакууме ...
> И стоит учесть что разные ФС имеют разные свойства и CoW -
> based будут себя вестиПроблемы индейцев нас не волнуют.
>> Как только скорости чтения и записи перестануть падать, считаем фрагментацию
>> максимальной а скорости результирующими для данной фс.
> ИМХО логичнее скармливать ФС одинаковый набор операций. И посмотреть как ФС с
> ним справится. А то сравнивать неодинаковый набор операций - это сравнение
> ежа с ужом. Из такого результата никаких особых выводов сделать не
> получится.Месье не на выборах, подтасовать результаты на этапе поставновки задачи не получится.
>Потому что в этом случае никак не учитывается способность ФС
> бороться с фрагментацией. Может, одна ФС чертовски фрагментируется за 5 минут,
> а другая за 2 дня издевательств.Проблемы индейцев.
> В реальном мире фрагментация ФС
> редко достигает максимума когда "хуже уже не будет", т.к. для этого
> нужны совсем запредельные условия и безбашенный админ. Бенч все-таки должен иметь
> какую-то практическую ценность.Ну мы та после изучения форумов знаем что для правильной эксплуотации ZFS нужно не первышать 65% заполнения. Имеет ли смысл тестировать вариант безбашенного админа ... сомневаюсь.
>> На самом деле сложнее: Если пишем то пишем вставляя в середину файла
>> с произвольным смещением от начала и произвольной длины блок.
> IIRC, в семантике POSIX )и большинстве иных похожих по смыслу), файлы умеют
> расти только с хвоста. Запись в середину перезаписывает то что там
> было, не раздвигая файл а переписывая содержимое. Увеличить размер можно лишь
> дописав в хвост. Просто потому что как обычным файловым системам было
> бы очень напряжно как-либо оформить "раздвигание" файла.Шел 2012 год, большинство фс по прежнему неумело "раздвигание" файла. Из за этого реализовать вариант с фрагментацией одного файла можно только следующим путем - забить диск множеством мелких файлов и начать писать большой файл освобождая место путем стирания произвольного колличества мелких файлов. В результате большой файл будет фрагментирован и на его чтении можно будет хоть что то измерить ...
>> Если удаляем блок то не удаляем его совсем а вырезаем из середины с произвольным
>> смещением и произвольной длиной и потом добавляем ео в конец.
> Мсье, в posix-овской семантике (как и в большинстве иных) такое не предусмотрено.
> Там урезать размер файла можно только отбрасыванием его хвоста. Потому что
> операция "сдвигания" файлов не особо проста в реализации. Особенно в ФС
> эпохи когда POSIX только формировался.Красота реализации POSIX удручает.
>> Назовите функции которые позволят это реализовать ?
> Ой, до мсье кажется начинает доходить что в posix нет таких сисколлов.В Linux fallocate() и splice() насчет второго неуверен ... тоже самое насчет sendfile() будет время опробую.
>> Это нужно как минимум в бд и торрентах ...
> Там это делается не совсем так как вы описали. И кстати по
> этому поводу есть ряд ограничений. Например, файл базы данных при активной
> работе с БД растет со временем (если не преаллоцирован заранее с
> запасом, конечно). И даже если удалить половину записей в таблице -
> это еще совсем не означает что файл можно будет взять и
> уменьшить.Оптимизация таблиц блокирует эти самые таблицы ? На плохо предсказуемое время ?
>[оверквотинг удален]
> есть операция дефрагментации/vacuum/кто там как еще это действо у себя обзывает
> и почему БД уменьшаются только после этой операции как правило :).
> А торренты - они предмет простой. Получили блок - запись в
> файл по нужному смещению. А преаллокация - по сути выбор между
> тем что хвост будет отрастать "как получится" или файл заранее будет
> заказан на полный размер. при том quick преаллокация - это мягкий
> хинт для ФС что "а вот мы собираемся сделать файл такого
> размера", а full - фактическая запись файла и потом перезапись блоков
> по мере скачки. Для классики так лучше. CoW - скорее даже
> ухучшит картину.В винде торрент так и делает - выделяет место на порлный размер. Голь на выдумки хитра.
>> Не вижу, как это напрямую к sparse файлам и аллокации-деаллокации относится.
> Мы не обсуждаем сферических коней в вакууме - пофиг как оно там внутри работает ...В данном случае не пофиг, имхо. Одно дело если 100500Мб файл занимает по факту 10Мб потому что в него только 10Мб записали и совсем другая картина если под него честно выкроены 100500Мб. Очень разные ситуации получатся.
>> нагрузка на способности ФС интенсивно работать с метаданными, тогда как аллокатору
>> особо не на чем надрываться.
> Да и интересны оба.Да. Только это совершенно отдельные бенчи по логике вещей. Один - "скорость операций с большим файлом". Второе - скорость работы с метаданными на мелочи. Еще возможен вариант "фантомас в очках на аэроплане" - когда большой файл специально состоит из кучи фрагментов. Как большой торрент (много больше дисковых буфферов ОС) без преаллокации, например. В этом случае ФС как правило не сможет очень уж сильно линеаризовать запись и поневоле сгенерит дофига метаданных описывающих размещение файла. Так можно создать ощутимые проблемы даже XFS, который на более простые методы фрагментации не особо то и покупается.
> Реальный бенч, реальные файлы ничего в вакууме ...
Реальный бенч пытается быть похожим на какие-то нагрузки встречающиеся в реальном мире. Случай когда скорость ФС упала до минимально возможной мало кого устраивает и в таком виде ФС мало кто эксплуатирует. Ну то-есть я знаю пока целого 1 кадра которого устраивает 6Мб/сек со шпинделя. Это наверное еще не минимум. Но вполне удачная попытка к нему приблизиться :)
>> И стоит учесть что разные ФС имеют разные свойства и CoW - based будут себя вести
> Проблемы индейцев нас не волнуют.Просто у разных дизайнов заведомо разные свойства. У самолетов одни проблемы, у автомобилей другие. Недостатком автомобилей и самолетов это не является.
>> ИМХО логичнее скармливать ФС одинаковый набор операций. И посмотреть как ФС с
>> ним справится. А то сравнивать неодинаковый набор операций - это сравнение
>> ежа с ужом. Из такого результата никаких особых выводов сделать не получится.
> Месье не на выборах, подтасовать результаты на этапе поставновки задачи не получится.Так это не подтасовка. Это попытка имитировать реальную эксплуатацию. Чудаков типа изена в природе немного, остальные предпочитают получать от ФСов более разумные параметры по ходу эксплуатации ;). Краевые ситуации в принципе тоже могут представлять интерес, но как некий отдельный случай. С изучением насколько сложно в него попасть и прочая.
>> а другая за 2 дня издевательств.
> Проблемы индейцев.Не индейцев а пользователей ФС. Задача бенча - не полить кого-то грязью или выпятить вперед/назад, а смоделировать типовые варианты эксплуатации, чтобы по результатам бенча можно было хотя-бы грубо прикинуть как ФС себя поведет в вот этом вот случае и надо ли ее такую хорошую брать под эту задачу или лучше обойти сторонкой в пользу чего-нибудь еще.
> Ну мы та после изучения форумов знаем что для правильной эксплуотации ZFS
> нужно не первышать 65% заполнения. Имеет ли смысл тестировать вариант безбашенного
> админа ... сомневаюсь.То только что утверждал что это проблемы индейцев, то теперь вдруг сам согласен что случай безбашенной эксплуатации рассматривать странно. Неплохо бы определиться :)
>> дописав в хвост. Просто потому что как обычным файловым системам было
>> бы очень напряжно как-либо оформить "раздвигание" файла.
> Шел 2012 год, большинство фс по прежнему неумело "раздвигание" файла.Како-то так вышло что почти все легковые автомобили как правило 4-колесные. Хотя могли бы быть и с другим количеством колес. Ну вот такой вот дизайн устоялся. А могли бы и турбореактивный двигатель привинтить. И крылья. Было бы круче. Но видимо столько счастья ALLу не надо было и спрос на фичу не сформировался.
> Из за этого реализовать вариант с фрагментацией одного файла можно только
> следующим путем - забить диск множеством мелких файлов и начать писать большой файлМсье как обычно забыл что для CoW и обычных ФС все будет по разному.
Hint1: на очень сильно фрагментированной ФС скорость доступа будет близка к тому что дает "random seeking" с мелкими блоками. Результат будет сильнее всего зависеть от seek time накопителя и размера запрашиваемого блока: чем хуже соотношение чтения блока к перемещению голов, тем хреновее результат. Этот эффект можно понаблюдать вообще без ФС - просто доступ к накопителю как RAW девайсу и чтение секторов там и тут даст то же самое. По поводу чего не очень понятно что даст указанный тест. Он будет не столько параметры ФС тестировать сколько свойства накопителя. Вот у изена с его ноутбучным винчом все особенно плохо: seek time у ноутбучных накопителей паршивый. На десктопном и шустром - было бы порезвее немного.
Хинт2: для "классики" совершенно нормально прилагать максимум усилий для раскладывания файла как можно более линейно (успешность этого начинания зависит от реализации аллокатора). CoW так не может из-за принципа работы. Если запись в середину файла в классике не создаст новый фрагмент и дозапись по возможности будет отращивать хвост дальше без фрагментации (покуда там свободное место есть) то CoW при записи в середину файла неизбежно сделает выносок-фрагмент в сторону.
> освобождая место путем стирания произвольного колличества мелких файлов. В результате
> большой файл будет фрагментирован и на его чтении можно будет хоть что то измерить ...Что-то мы конечно измерим, но в основном это будет определяться соотношением размера потертых файлов к расстоянию полета голов и seek time накопителя.
>> эпохи когда POSIX только формировался.
> Красота реализации POSIX удручает.Другие API (например WinAPI) похожи в этом плане. Ну как почти все автомобили с 4 колесами, рулем и так далее, так и эти API все более-менее похожи.
>>> Назовите функции которые позволят это реализовать ?
>> Ой, до мсье кажется начинает доходить что в posix нет таких сисколлов.
> В Linux fallocate() и splice() насчет второго неуверен ... тоже самое насчет
> sendfile() будет время опробую.Не совсем понял при чем тут splice и sendfile. Они конечно хороши тем что меньше грузят систему т.к. нет копирования памяти между юзермодом и ядром, но принципы работы с файлами они не меняют. А fallocate интересен только тем что там сделали операцию обратную превращению sparse файла в обычный. Хоть это и не входит в posix (который о sparse файлах вообще не в курсе) и довольно нишевая хрень.
>> это еще совсем не означает что файл можно будет взять и уменьшить.
> Оптимизация таблиц блокирует эти самые таблицы ? На плохо предсказуемое время ?Я не о том. Чтобы уменьшить размер файла базы мне известна буквально пара вариантов. Первый - это расчистить хвост, затолкав данные оттуда в свободные страницы в начале файла. Т.е. обычная дефрагментация "объединение свободного места в хвост" + стандартное откусывание хвоста. Второй вариант - полная перестройка нового файла на основе старого но без прорех + стирание старого файла с прорехами. По смыслу одно и то же, только по разному. В случае fallocate() с возможностью разреживания - сделали хитрый финт ушами и прикрутили возможность метить регионы файла как "опять пустые".
>> по мере скачки. Для классики так лучше. CoW - скорее даже ухучшит картину.
> В винде торрент так и делает - выделяет место на порлный размер.Внезапно, торрент-клиенты так делают не только в винде. Например у того же transmission (который сложно отнести к виндовым) есть 2 режима преаллокации файлов, быстрый и полный. Первый лишь декларирует в сторону ФС что у нас дескать есть намерения получить файл такого размера (sparse как раз об этом). Дальше ФС сама по мере возможности пхает скачанные блоки как получится и как позволяет ситуация. В идеальном случае - может разложить хорошо. Но если качается 100500 файлов параллельно и прочая - может выйти и не совсем оптимально. Второй режим реально заполняет файл по всему объему при его создании и потом по мере скачки блоков просто переписывает регионы файла. На классике это приводит к тому что блоки кладутся в заранее подготовленное "русло" и лежат так, по поводу чего оно максимально линейно насколько ФС в принципе могла это сделать в той ситуации. На CoW такое однако имхо ни к чему хорошему не приведет. Это оптимизация которая хороша для классических дизайнов.
> Голь на выдумки хитра.
Да в общем то общеизвестные техники и каждый первый уважающий себя торрент клиент это так или иначе умеет, кроме совсем уж простейших. Просто в некоторых надо ман почитать еще.
> даже XFS, который на более простые методы фрагментации не особо то
> и покупается.Проблемы индейцев.
>> Реальный бенч, реальные файлы ничего в вакууме ...
> Реальный бенч пытается быть похожим на какие-то нагрузки встречающиеся в реальном мире.
> Случай когда скорость ФС упала до минимально возможной мало кого устраивает
> и в таком виде ФС мало кто эксплуатирует. Ну то-есть я
> знаю пока целого 1 кадра которого устраивает 6Мб/сек со шпинделя. Это
> наверное еще не минимум. Но вполне удачная попытка к нему приблизиться
> :)Вам же сказали "Реальный бенч, реальные файлы" а вы опять со своимы конями в вакуме.
> Просто у разных дизайнов заведомо разные свойства. У самолетов одни проблемы, у
> автомобилей другие. Недостатком автомобилей и самолетов это не является.Тесты покажут у кого какие проблемы.
> Так это не подтасовка. Это попытка имитировать реальную эксплуатацию. Чудаков типа изена
> в природе немного, остальные предпочитают получать от ФСов более разумные параметры
> по ходу эксплуатации ;). Краевые ситуации в принципе тоже могут представлять
> интерес, но как некий отдельный случай. С изучением насколько сложно в
> него попасть и прочая.Друг мой вы случайно не из партіi ВО "Батьківщина" ? Еще раз - вы не на выборах подтасовать условия тестирования не получится.
> Не индейцев а пользователей ФС. Задача бенча - не полить кого-то грязью
> или выпятить вперед/назад, а смоделировать типовые варианты эксплуатации, чтобы по результатам
> бенча можно было хотя-бы грубо прикинуть как ФС себя поведет в
> вот этом вот случае и надо ли ее такую хорошую брать
> под эту задачу или лучше обойти сторонкой в пользу чего-нибудь еще.В двух словах индейцы в панике.
> То только что утверждал что это проблемы индейцев, то теперь вдруг сам
> согласен что случай безбашенной эксплуатации рассматривать странно. Неплохо бы определиться
> :)Наш большой файл в сумме с мелкими не будет занимать более 65% фс.
> Како-то так вышло что почти все легковые автомобили как правило 4-колесные. Хотя
> могли бы быть и с другим количеством колес. Ну вот такой
> вот дизайн устоялся. А могли бы и турбореактивный двигатель привинтить. И
> крылья. Было бы круче. Но видимо столько счастья ALLу не надо
> было и спрос на фичу не сформировался.Вы явно не в теме, если бы не сомнительные личности из нефтегазового сектора мы бы на стат поясах летали бы ...
> Hint1: на очень сильно фрагментированной ФС скорость доступа будет близка к тому
> что дает "random seeking" с мелкими блоками. Результат будет сильнее всего
> зависеть от seek time накопителя и размера запрашиваемого блока: чем хуже
> соотношение чтения блока к перемещению голов, тем хреновее результат.Вот имеено этот тест хочется проделать на диске в памяти :))
>Этот эффект
> можно понаблюдать вообще без ФС - просто доступ к накопителю как
> RAW девайсу и чтение секторов там и тут даст то же
> самое. По поводу чего не очень понятно что даст указанный тест.
> Он будет не столько параметры ФС тестировать сколько свойства накопителя. Вот
> у изена с его ноутбучным винчом все особенно плохо: seek time
> у ноутбучных накопителей паршивый. На десктопном и шустром - было бы
> порезвее немного.Я вижу вы неравнодушны к Изену :))
> Что-то мы конечно измерим, но в основном это будет определяться соотношением размера
> потертых файлов к расстоянию полета голов и seek time накопителя.Прежде всего я ожидаю увидеть как не все участники тестирования придут к финишу :)) вероятно завалит тест btrfs :))
> Другие API (например WinAPI) похожи в этом плане. Ну как почти все
> автомобили с 4 колесами, рулем и так далее, так и эти
> API все более-менее похожи.Копипаст во всей красе :)) Последствия bsd лицензии :)))
> Не совсем понял при чем тут splice и sendfile. Они конечно хороши
> тем что меньше грузят систему т.к. нет копирования памяти между юзермодом
> и ядром, но принципы работы с файлами они не меняют. А
> fallocate интересен только тем что там сделали операцию обратную превращению sparse
> файла в обычный. Хоть это и не входит в posix (который
> о sparse файлах вообще не в курсе) и довольно нишевая хрень.Так есть возможность реализовать или таки нет :))) Напоминаю шел 2012 год ...
> Я не о том. Чтобы уменьшить размер файла базы мне известна буквально
> пара вариантов. Первый - это расчистить хвост, затолкав данные оттуда в
> свободные страницы в начале файла. Т.е. обычная дефрагментация "объединение свободного
> места в хвост" + стандартное откусывание хвоста. Второй вариант - полная
> перестройка нового файла на основе старого но без прорех + стирание
> старого файла с прорехами. По смыслу одно и то же, только
> по разному. В случае fallocate() с возможностью разреживания - сделали хитрый
> финт ушами и прикрутили возможность метить регионы файла как "опять пустые".И какой из этих вариантов рабочий при условии что начальный и конечный файлы занимают больше чем 50% диска ? :)))
>> Просто у разных дизайнов заведомо разные свойства. У самолетов одни проблемы, у
>> автомобилей другие. Недостатком автомобилей и самолетов это не является.
> Тесты покажут у кого какие проблемы.Тесты Lamborghini на проселочной дороге или Запорожца на автобане? xD
> Друг мой вы случайно не из партіi ВО "Батьківщина" ? Еще раз
> - вы не на выборах подтасовать условия тестирования не получится.Переклинило на выборах?
> Наш большой файл в сумме с мелкими не будет занимать более 65%
> фс."> Вам же сказали "Реальный бенч, реальные файлы" а вы опять со своимы
> конями в вакуме."
> Вы явно не в теме, если бы не сомнительные личности из нефтегазового
> сектора мы бы на стат поясах летали бы ...И на мётлах.
> Вот имеено этот тест хочется проделать на диске в памяти :))
Странная эротическая фантазия. Вам же сказали - реальный бенч...
> Прежде всего я ожидаю увидеть как не все участники тестирования придут к
> финишу :)) вероятно завалит тест btrfs :))Цели "теста" уже ясны, далее можно не продолжать.
> И какой из этих вариантов рабочий при условии что начальный и конечный
> файлы занимают больше чем 50% диска ? :)))"> Вам же сказали "Реальный бенч, реальные файлы" а вы опять со своимы
> конями в вакуме."
> Тесты Lamborghini на проселочной дороге или Запорожца на автобане? xDЕсли вытак уверены в победе зачем так беспокоиться ? :)))
> Переклинило на выборах?
Не, задолбали упоротые фанатики.
> И на мётлах.
Может быть ...
> Странная эротическая фантазия. Вам же сказали - реальный бенч...
И вы тоже в темноте под одеялом ? Свободнаю рукою ? :))
> Цели "теста" уже ясны, далее можно не продолжать.
Да не волуйтесь вы так, вдруг я ошибаюсь...
А в это время в деревне индейцев тихо началась эпидемия медвежьей болезни ...
А что, reiser уже настолько же предсказуема, насколько ext'ы?
Со слов разработчиков - очень предсказуемая, и легко расширяемая FS.
Одна проблема работать с VM хочет немного не так как это удобно ext[2-4], поэтому ее и не примут.
Ибо удобство RedHat и ext[2-4] на первом месте.
> Со слов разработчиков - очень предсказуемая, и легко расширяемая FS.Со слов разработчиков, любая программа - это такая серебряная пуля которая мигом решит все проблемы человечества. Aka синдром "свое не пахнет". Потому что сложно это - самого себя ругать :). Проблема лишь в том что для всех остальных программа имеет гораздо менее волшебные свойства т.к. синдром "свое не пахнет" наблюдателя не кусает :)
А если называть вещи своими именами, reiser4 - это нечто сильно недопиленное, авторы которого при всех теоретических достоинствах дизайна не смогли на практике нормально взаимодействовать с разработчиками ядра, испытывают недостаток разработчиков и потому перспективы всего этого - довольно туманные.
> Ибо удобство RedHat и ext[2-4] на первом месте.
Ваши данные протухли: IIRC разработчик ext4 слинял в гугль. А разработчик btrfs - свалил из из оракла в FusionIO.
> Со слов разработчиков - очень предсказуемая, и легко расширяемая FS.
> Одна проблема работать с VM хочет немного не так как это удобно
> ext[2-4], поэтому ее и не примут.
> Ибо удобство RedHat и ext[2-4] на первом месте.Со слов разработчиков винды - это идеальная операционная система для всего на свете.
>> Со слов разработчиков винды - это идеальная операционная система для всего на свете.Со слов маркетологов. Хотя, возможно, это одни и те же люди...
>> Со слов разработчиков - очень предсказуемая, и легко расширяемая FS.
>> Одна проблема работать с VM хочет немного не так как это удобно
>> ext[2-4], поэтому ее и не примут.
>> Ибо удобство RedHat и ext[2-4] на первом месте.
> Со слов разработчиков винды - это идеальная операционная система для всего на
> свете.Со слов апологетов Линя - линь - в точности это самое.
>> Со слов разработчиков винды - это идеальная операционная система для всего на
>> свете.
> Со слов апологетов Линя - линь - в точности это самое."Ветку не читал, но осуждаю"
А смысл то в ext5? Пока его доделают, btrfs будет рулить и педалить. А ext5 чем таким будет фундаментально отличаться от ext4?
Проблема в том, что люди слишком доверяют своим жёстким дискам. Не надо!
> А то. Поэтому все вменяемые пользуются ФС со встроенным менеджером томов, избыточностью
> и контрольными суммами. Например, ZFS."Вменяемость" и "ездить по городу на комбайне" - несколько конфликтуют.
Вменяемые люди используют подходящую для каждой конкретной задачи комбинацию из независимых компонентов (ФС, менеджера томов и RAID).
Вменяемые люди не делают глупых предположений. Связка из 3х слоев чревата проблемами и не работающими возможностями. К тому же lvm это и менеджер томов и raid при том последнее там убого
> Вменяемые люди не делают глупых предположений. Связка из 3х слоев чревата проблемами и не работающими возможностями.А в комбайне, где эти слои слеплены в один жеваный ком, количество проблем и ограничений возрастает на порядок.
>> Вменяемые люди не делают глупых предположений. Связка из 3х слоев чревата проблемами и не работающими возможностями.
> А в комбайне, где эти слои слеплены в один жеваный ком, количество
> проблем и ограничений возрастает на порядок.Покажи мне эти проблемы в ZFS? Только не в порядке теории - а на практике и с пруфами, разумеется?
> Покажи мне эти проблемы в ZFS? Только не в порядке теории -
> а на практике и с пруфами, разумеется?Да чего их показывать. ARC память жрёт? Жрёт. Системе отдаёт плохо? Плохо. В корку при нехватке валится? Валится. Нарушение уровневого подхода со структурами ядра и памятью - это самое худшее, что можно было придумать.
>> Покажи мне эти проблемы в ZFS? Только не в порядке теории -
>> а на практике и с пруфами, разумеется?
> Да чего их показывать. ARC память жрёт? Жрёт. Системе отдаёт плохо? Плохо.
> В корку при нехватке валится? Валится. Нарушение уровневого подхода со структурами
> ядра и памятью - это самое худшее, что можно было придумать.Давно он в корку падал ? А вот линь в таких случаях в корку не падает ... просто замирает :))
> Давно он в корку падал ? А вот линь в таких случаях в корку не падает ... просто замирает :))А там таких случаев тупо быть не может - BTRFS юзает системный кеш. И давление на кеш зависит от нагруженности памяти - состояние OOM может случиться только если кеш почти пустой к тому моменту. В случае ARC всё хуже - система на него нормальным способом не давит. Т.е. реально может быть OOM при вагоне памяти в ARC, и это самое хреновое.
>> Давно он в корку падал ? А вот линь в таких случаях в корку не падает ... просто замирает :))
> А там таких случаев тупо быть не может - BTRFS юзает системный
> кеш. И давление на кеш зависит от нагруженности памяти - состояние
> OOM может случиться только если кеш почти пустой к тому моменту.
> В случае ARC всё хуже - система на него нормальным способом
> не давит. Т.е. реально может быть OOM при вагоне памяти в
> ARC, и это самое хреновое.Вобще то линь замирает когда ядру памяти нехватает ... и случиться это может не только из за эксперементальных фс.
> Вобще то линь замирает когда ядру памяти нехватает ... и случиться это
> может не только из за эксперементальных фс.Вообще-то сначала происходит событие OOM. Если что. Убиваются процессы.
Но довести систему до OOM - это надо совсем башни не иметь.
А вот с ARC всё хреново - под него советуют выделять вагон памяти, а отдавать под нагрузкой он ее не особо хочет. Т.е. шансы на OOM увеличиваются.
> Вобще то линь замирает когда ядру памяти нехватает ...Когда ядру памяти не хватает - он жестоко гасит все что гасится по OOM. Ничего там не замирает, расстрел лишних программ очень бойкий получается :).
> Покажи мне эти проблемы в ZFS? Только не в порядке теории -
> а на практике и с пруфами, разумеется?
>> Покажи мне эти проблемы в ZFS? Только не в порядке теории -
>> а на практике и с пруфами, разумеется?
> http://discuss.joyent.com/viewtopic.php?id=19430Зачет зачет, год видели ? 2008-01-16 00:05:12 :))
>>> Покажи мне эти проблемы в ZFS? Только не в порядке теории -
>>> а на практике и с пруфами, разумеется?
>> http://discuss.joyent.com/viewtopic.php?id=19430
> Зачет зачет, год видели ? 2008-01-16 00:05:12 :))Я-то видел, а некоторые тут щёки дуют про семь лет и всё такое, когда бывший кастомер ещё тёпленький от попадалова на именно что обещалове.
Прикольно: по ссылке на багрепорт оракл недвусмысленно посылает всех в сад :)
> Зачет зачет, год видели ? 2008-01-16 00:05:12 :))http://blog.lastinfirstout.net/2010/04/bit-by-bug-data-loss-...
Посвежее - 04.2010. Причем баг - следствие грубейшего нарушения уровневого подхода. И таких, думается, еще вылезет предостаточно.И более-менее свеженькое:
http://christopher-technicalmusings.blogspot.ru/2011/02/zfs-..."Довольный" клиент, уходящий со "стабильной" солярки за 100500 тонн нефти на Linux:
https://groups.google.com/forum/?fromgroups=#!topic/comp.uni...
Явная ошибка позиционирования - "непротиворечивая" файловая система легко рассыпалась - как уже я раньше твердил изену - из-за ошибок CPU/памяти. Потому что вся эта "непротиворечивать" зиждется на исправности H/W. Если H/W сбоит (а не умирает сразу) - вся "непротиворечивость" идёт лесом.Нельзя позиционировать что-то, как абсолютно надёжное... клиент из-за этого положился целиком на ZFS, и не делал регулярных бэкапов. Ведь оно же "непротиворечивое". А теперь кусает локти.
>> Зачет зачет, год видели ? 2008-01-16 00:05:12 :))
> http://blog.lastinfirstout.net/2010/04/bit-by-bug-data-loss-...
> Посвежее - 04.2010. Причем баг - следствие грубейшего нарушения уровневого подхода. И
> таких, думается, еще вылезет предостаточно.
> И более-менее свеженькое:
> http://christopher-technicalmusings.blogspot.ru/2011/02/zfs-...
> "Довольный" клиент, уходящий со "стабильной" солярки за 100500 тонн нефти на Linux:
> https://groups.google.com/forum/?fromgroups=#!topic/comp.uni...Эти баги как то проявляются в реальной жизни или так и являются грубейшим нарушением уровнего подхода в сознании отдельно взятых линуксоидов ниасиливших исходинки zfs ?
> Явная ошибка позиционирования - "непротиворечивая" файловая система легко рассыпалась
> - как уже я раньше твердил изену - из-за ошибок CPU/памяти.
> Потому что вся эта "непротиворечивать" зиждется на исправности H/W. Если H/W
> сбоит (а не умирает сразу) - вся "непротиворечивость" идёт лесом.Если клиент после трех ребутов в течении трех часов не понял своим умом, что то с железом ...
> Нельзя позиционировать что-то, как абсолютно надёжное... клиент из-за этого положился
> целиком на ZFS, и не делал регулярных бэкапов. Ведь оно же
> "непротиворечивое". А теперь кусает локти.Клиент делал бакапы на тот же диск ? Клиент ССЗБ ?
> Эти баги как то проявляются в реальной жизни или так и являются
> грубейшим нарушением уровнего подхода в сознании отдельно взятых линуксоидов ниасиливших > исходинки zfs ?Чукча не читатель? Data loss.
> Если клиент после трех ребутов в течении трех часов не понял своим
> умом, что то с железом ...Если бы, да кабы, да росли бы во рту грибы. Завалилось? Завалилось. Тчк. О "непротиворечивости" речи дальше и быть не может. Хотя - можете слушать маркетолухов дальше.
> Клиент делал бакапы на тот же диск ? Клиент ССЗБ ?
Не делал он оперативных бэкапов - только широкоинтервальные и инкремент по входным данным, потому что маркетолухи пообещали "непротиворечивую" FS. Короче - сидеть и ждать, пока распарсится поток.
> Если бы, да кабы, да росли бы во рту грибы. Завалилось? Завалилось.И вот такие люди работают в половине наших организаций ... :)))
>> http://christopher-technicalmusings.blogspot.ru/2011/02/zfs-...
> Эти баги как то проявляются в реальной жизниНасколько понимаю, для опубликовавших они проявились именно в реальной жизни, а не в воображаемом продакшене в шухлядке. И спасибо им, что потрудились вместо инженегров покойных санов и всё-таки выяснили, при каких условиях пул идёт в хлам.
> или так и являются грубейшим нарушением уровнего подхода в сознании
> отдельно взятых линуксоидов ниасиливших исходинки zfs ?Перед тем, как хамить, хотя бы почитали по диагонали предложенное... Извольте:
---
My first day was spent in a light daze (shock maybe) as I researched more about the inner workings of ZFS. Luckily I had already spent a few weekends messing around with trying to port PJD's v28 ZFS patch on FreeBSD to a newer build of FreeBSD, so I had some idea of the code, the vdevs, uberblocks, etc.
---Перевести или всё-таки понятно, что это был отдельно взятый человек, ковырявшийся в кишках zfs при попытке форвард-порта v28 на более новую фрю?
>[оверквотинг удален]
> ---
> My first day was spent in a light daze (shock maybe) as
> I researched more about the inner workings of ZFS. Luckily I
> had already spent a few weekends messing around with trying to
> port PJD's v28 ZFS patch on FreeBSD to a newer build
> of FreeBSD, so I had some idea of the code, the
> vdevs, uberblocks, etc.
> ---
> Перевести или всё-таки понятно, что это был отдельно взятый человек, ковырявшийся в
> кишках zfs при попытке форвард-порта v28 на более новую фрю?А зачем ему понадобилось портироваь v28 на новую версию FreeBSD ? Он что случайно обновил фрю на боевом сервере до 10 ? :)) Суровый малый :))) Вот что бывает когда линуксоида допускают с серверам с фрей :)))
Да кстати достаточно вместо *default tag=RELENG_9 написать *default tag=RELENG-9 и накотит самое последнее :)))
> А зачем ему понадобилось портироваь v28 на новую версию FreeBSD ?Сами спросите. Вряд ли затем, чтоб какому оголтелому новобранцу потом пальцЫ по форумам растопыривать, впрочем -- "у меня и на новой фре zfs работает уже три дня".
> Вот что бывает когда линуксоида допускают с серверам с фрей :)))
Да кому они сдались, эти "сервера с фрёй", чтоб к ним "допускаться".
Впрочем, фантазируйте на здоровье. Так понимаю, что читать и тем более расспрашивать коллегу о действительном состоянии вещей, как положено специалисту при виде серьёзной проблемы, всё равно не будете.
>> А зачем ему понадобилось портироваь v28 на новую версию FreeBSD ?
> Сами спросите. Вряд ли затем, чтоб какому оголтелому новобранцу потом пальцЫ
> по форумам растопыривать, впрочем -- "у меня и на новой фре
> zfs работает уже три дня".
>> Вот что бывает когда линуксоида допускают с серверам с фрей :)))
> Да кому они сдались, эти "сервера с фрёй", чтоб к ним "допускаться".
> Впрочем, фантазируйте на здоровье. Так понимаю, что читать и тем более
> расспрашивать коллегу о действительном состоянии вещей, как положено специалисту при виде
> серьёзной проблемы, всё равно не будете.Вы предлагаете написать ему ответ ? На ом форуме ? И ничего что прошло 2-ва года ?
Ну давайте пишите :))) почитаем :)))
Я одного не пойму, где вообще фикс и какого хрена до сих пор срочно не выпущено 3.6.4 с ним?
Столько лет баг гулял и ничего, еще немного погуляет. Проявляется при частой перезагрузке.
> Столько лет баг гулял и ничего, еще немного погуляет. Проявляется при частой
> перезагрузке.Не "столько лет", его совсем недавно добавили (начиная с 3.6.1 и 3.5.4, если правильно помню).
> Столько лет баг гулялДа, ноль целых, хрен десятых - ядро 3.6.2 выйти едва успело как баг и нашли. Гулял столько лет предвестник бага - некорректный комментарий в коде, который может обмануть программистов.
Граждане, а сжатие будет, нет?
> Граждане, а сжатие будет, нет?xz (gzip, bzip2, lzo - по вкусу) отменили?
>> Граждане, а сжатие будет, нет?
> xz (gzip, bzip2, lzo - по вкусу) отменили?BTRFS же!
> BTRFS же!О да
WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using
> О да
> WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
> WARNING! - see http://btrfs.wiki.kernel.org before usingОни хотя бы честные. Предупреждают, в отличие от ZFS-индусов.
>> О да
>> WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
>> WARNING! - see http://btrfs.wiki.kernel.org before using
> Они хотя бы честные. Предупреждают, в отличие от ZFS-индусов.Очень ждем такие предупреждения от разработчиков ext4 LVM и рейзера ...
>> О да
>> WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
>> WARNING! - see http://btrfs.wiki.kernel.org before using
> Они хотя бы честные. Предупреждают, в отличие от ZFS-индусов.ZFS так-то в продакшене лет 7 уже как.
> ZFS так-то в продакшене лет 7 уже как.В каком, прости, продакшне? Где хоть одна мало-мальски обширная инсталляция вне академиков и махрового ынтырпрайза?
> WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTALА вы знаете в каком году был btrfs 0.19? :) Это была последняя версия развивавшаяся отдельно от майнлайна. С тех пор btrfs не имеет отдельного номера версии ибо входит в основное ядро. Ну а тем кто видел btrfs только на картинке не заапдейченная вика может позволить красиво зафэйлить на форуме, например :)
ZFS.linux и больше нихера не нужно
Ну вот вы этим и пользуйтесь.
спасибо КЭП, давно юзаемhttp://pthree.org/2012/04/17/install-zfs-on-debian-gnulinux/
> спасибо КЭП, давно юзаемСоболезную, чо.
>> спасибо КЭП, давно юзаем
> Соболезную, чо.Давай спрыгнем с крыши по этому поводу? Что нормальная промышленная ФС, разработанная профи, таки стала доступна в лине?
> Давай спрыгнем с крыши по этому поводу? Что нормальная промышленная ФС, разработанная
> профи, таки стала доступна в лине?И где оно-таки промышлится? Кроме как у академиков на локалхостах, пока ни у кого не видел.
> И где оно-таки промышлится? Кроме как у академиков на локалхостах, пока ни
> у кого не видел.SUN ?
>> И где оно-таки промышлится? Кроме как у академиков на локалхостах, пока ни
>> у кого не видел.
> SUN ?Это хто ? А у них на линухе ? :)
>>> И где оно-таки промышлится? Кроме как у академиков на локалхостах, пока ни
>>> у кого не видел.
>> SUN ?
> Это хто ? А у них на линухе ? :)Раньше дурни носились со ступами теперь с линуксом, рост на лицо ...
> Раньше дурни носились со ступами теперь с линуксом, рост на лицо ...Да, все ынтырпрайзы - бакланы, один вы тут у нас умный. А вам не кажется что если все вокруг дураки, а один вы умный - тут что-то не так? :)
>> И где оно-таки промышлится? Кроме как у академиков на локалхостах, пока ни
>> у кого не видел.
> SUN ?Не хочу вас огорчать, но он... это самое... ку-ку.
>>> И где оно-таки промышлится? Кроме как у академиков на локалхостах, пока ни
>>> у кого не видел.
>> SUN ?
> Не хочу вас огорчать, но он... это самое... ку-ку.http://www.oracle.com/ru/products/servers/overview/index.html
КУ-КУ это диагноз ?
> КУ-КУ это диагноз ?Да, если вы не можете отличить слово "oracle" от слова "sun" - это диагноз.
> SUN ?И где оно ныне? Реально?
Даже Oracle свою DB уже больше предлагает под Linux, нежели под Sun. Да и ZFS под неё какбэ не сертифицирована.
> И где оно ныне? Реально?
> Даже Oracle свою DB уже больше предлагает под Linux, нежели под Sun.
> Да и ZFS под неё какбэ не сертифицирована.Сертифицировано ...
> Сертифицировано ...Да, давай, скажи что оракл сертифицЫрован с ZFS на BSD. Ты можешь, я знаю :)
>> Сертифицировано ...
> Да, давай, скажи что оракл сертифицЫрован с ZFS на BSD. Ты можешь,
> я знаю :)Оракл никогда в жизни не считал BSD платформой и отродясь под нее не существовал.
> Оракл никогда в жизни не считал BSD платформой и отродясь под нее не существовал.Спасибо, Капитан. Я думаю что гражданин понял на что я ему намекал, но вы решили уточнить :)
>> Оракл никогда в жизни не считал BSD платформой и отродясь под нее не существовал.
> Спасибо, Капитан. Я думаю что гражданин понял на что я ему намекал,
> но вы решили уточнить :)Тихо сам с собою ...
> SUN ?Какой SUN? SUN = RIP. ДоZFS'ились.
> И где оно-таки промышлится? Кроме как у академиков на локалхостах, пока ни
> у кого не видел.Вы что-то путаете. Аттестат об окончании 9 классов - это еще далеко не звание академика.
>> Давай спрыгнем с крыши по этому поводу? Что нормальная промышленная ФС, разработанная
>> профи, таки стала доступна в лине?
> И где оно-таки промышлится? Кроме как у академиков на локалхостах, пока ни
> у кого не видел.Если ваш кругозор ограничен localhost - мне вас жаль.
промышлится у авторов порта - одина из машин из TOP10 (не помню текущий номер в списке).
Советую посмотреть презентации с LUG 2012 и LAD 2012 и больше не говорить таких глупостей.
набрать в гуле "llnl zfs cluster" сможете?На секвое помоему 20P на дисках - имеет ли ваш сторадж сравнимый объем?
> набрать в гуле "llnl zfs cluster" сможете?Lawrence Livermore National Laboratory (LLNL)
Академики? Академики. Понятно, что большие. Это единичное применение, не более.
Скорее это заявка на то что TOP100 будет таким и клон ext4 будет вырублен оттуда.теперь подскажите какая еще fs может динамически аллоцировать иноды?
Вот вы изначально сделали одно количество инод - а у вас получилось что хранятся более мелкие файлы и вам не хватает инод, при этом свободного места на диск вагон. Решите эту проблему с ext4, xfs и тп (не знаю как там в новомодной btrfs). Причем это задача из реальной жизни.
> Скорее это заявка на то что TOP100 будет таким и клон ext4
> будет вырублен оттуда.
> теперь подскажите какая еще fs может динамически аллоцировать иноды?
> Вот вы изначально сделали одно количество инод - а у вас получилось
> что хранятся более мелкие файлы и вам не хватает инод, при
> этом свободного места на диск вагон. Решите эту проблему с ext4,
> xfs и тп (не знаю как там в новомодной btrfs). Причем
> это задача из реальной жизни.Да вообще-то все это умеют, кроме древних как говно мамонта ext*, а к чему вопрос?
даже упомянутая вами XFS.
>не знаю как там в новомодной btrfsТам еще хуже чем в ext4 ...
>>не знаю как там в новомодной btrfs
> Там еще хуже чем в ext4 ...Ну да. То ли дело ZFS, где даже дефрагментатора нет, и кеш эксклюзивный, да еще и без zero-copy. Если хочешь сделать из системы тормозилово или купить санку под задачи, где справился бы и десктоп - самое оно.
>>>не знаю как там в новомодной btrfs
>> Там еще хуже чем в ext4 ...
> Ну да. То ли дело ZFS, где даже дефрагментатора нет, и кеш
> эксклюзивный, да еще и без zero-copy. Если хочешь сделать из системы
> тормозилово или купить санку под задачи, где справился бы и десктоп
> - самое оно.У btrfs не в скорости проблема, кроме того COV как бы идейно несовместим с дефрагментацией ... Кроме того наивно сравнивать стабильные сани с десктопом, особенно в последнее время да еще если интел ...
> COV как бы идейно несовместим с дефрагментациейСпасибо, подр^W поржал. Точнее - CoW нежизнеспособен без дефрагментации. Но это другое.
> Кроме того наивно сравнивать стабильные сани с десктопом
А куды еще деваться, если после всех приблуд ака ZFS для того, чтобы решить задачу, с которой стабильно справится и десктоп, надо брать сани за 100500 нефти?
> стабильно справится десктопЛюбые 2 слова правда но 3 лож ...
> Любые 2 слова правда но 3 лож ...К логопеду.
>> COV как бы идейно несовместим с дефрагментацией
> Спасибо, подр^W поржал. Точнее - CoW нежизнеспособен без дефрагментации. Но это другое.
>> Кроме того наивно сравнивать стабильные сани с десктопом
> А куды еще деваться, если после всех приблуд ака ZFS для того,
> чтобы решить задачу, с которой стабильно справится и десктоп, надо брать
> сани за 100500 нефти?Так-то Соляра для x86 существует с 1993 года, если чего. С версии 2.4. Какие там нефти еще?
> Так-то Соляра для x86 существует с 1993 года, если чего. С версии
> 2.4. Какие там нефти еще?Каким боком 1993 год относится к тому, о чем мы говорим?
> У btrfs не в скорости проблема, кроме того COVСначана научись CoW правильно писать, юморист.
> как бы идейно несовместим с дефрагментацией ...
Все там совместимо. Парней из сана заломало делать достаточно сложную плюшку. Поэтому компенсировали маркетинговым буллшитом, как обычно.
> Кроме того наивно сравнивать стабильные сани с десктопом,
Да, вот сейчас все разбежались у оракла покупать железки по их ценам. Это будет делать полтора ынтырпрайза. И те хотят линуксы, а вовсе не.
>> У btrfs не в скорости проблема, кроме того COV
> Сначана научись CoW правильно писать, юморист.
>> как бы идейно несовместим с дефрагментацией ...
> Все там совместимо. Парней из сана заломало делать достаточно сложную плюшку. Поэтому
> компенсировали маркетинговым буллшитом, как обычно.
>> Кроме того наивно сравнивать стабильные сани с десктопом,
> Да, вот сейчас все разбежались у оракла покупать железки по их ценам.
> Это будет делать полтора ынтырпрайза. И те хотят линуксы, а вовсе
> не.root @ hostname / # prtdiag|more
System Configuration: ASUS RS120-E5/PA4
BIOS Configuration: American Megatrends Inc. 0702 07/06/2009
BMC Configuration: IPMI 2.0 (KCS: Keyboard Controller Style)==== Processor Sockets ====================================
Version Location Tag
-------------------------------- --------------------------
Intel(R) Core(TM)2 Quad CPU Q8300 @ 2.50GHz Socket 775==== Memory Device Sockets ================================
Type Status Set Device Locator Bank Locator
------- ------ --- ------------------- --------------------
DDR2 in use 0 DIMM_A1 BANK0
unknown empty 0 DIMM_A2 BANK1
DDR2 in use 0 DIMM_B1 BANK2
unknown empty 0 DIMM_B2 BANK3==== On-Board Devices =====================================
To Be Filled By O.E.M.root @ hostname / # zpool status rpool
pool: rpool
state: ONLINE
scan: scrub repaired 0 in 0h20m with 0 errors on Sat Nov 3 06:20:11 2012
config:NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c1t0d0s0 ONLINE 0 0 0
c1t1d0s0 ONLINE 0 0 0errors: No known data errors
Чо-чо ты там говорил про ынтырпрайз, не подскажешь? Кекеке...
> Чо-чо ты там говорил про ынтырпрайз, не подскажешь? Кекеке...А на нормальный дисковый контроллер денег не нашлось? Или у нас два диска в зеркале - уже ЕНТЫРПРАЙС?
>> Чо-чо ты там говорил про ынтырпрайз, не подскажешь? Кекеке...
> А на нормальный дисковый контроллер денег не нашлось? Или у нас два
> диска в зеркале - уже ЕНТЫРПРАЙС?Благодаря высказыванию одного профана множество юдей покупает гавно-рейд-контроллеры на 2-4 диска которые намного хуже встроенного в мать.
> Благодаря высказыванию одного профана множество юдей покупает гавно-рейд-контроллеры
> на 2-4 диска которые намного хуже встроенного в мать.Хуже встроенного в мать рейд-контроллера на 99% десктопных мамок быть не может. Впрочем, как не может быть и лучше. Просто потому, что в 99% десктопных мамок оного - ТАДА - НЕТ!
>> Благодаря высказыванию одного профана множество юдей покупает гавно-рейд-контроллеры
>> на 2-4 диска которые намного хуже встроенного в мать.
> Хуже встроенного в мать рейд-контроллера на 99% десктопных мамок быть не может.
> Впрочем, как не может быть и лучше. Просто потому, что в
> 99% десктопных мамок оного - ТАДА - НЕТ!ТАДА гдето с ich7 ... :)))))
> ТАДА гдето с ich7 ... :)))))ТАДА! Учи матчасть - это фейкрейд, т.е. софт.
> Хуже встроенного в мать рейд-контроллера на 99% десктопных мамок быть не может.Предлагаю определиться с терминами.
1) насколько понимаю, разговор о FakeRAID и они действительно бывают хуже просто каналов;
2) на вроде бы как серверном tyan (двухсокетная оптеронная мать) однажды видел SiI3114, распаянный на PCI32/33(!) вместе с eth и ещё кучей всякого хлама, т.е. даже не отдельно -- в итоге оно затыкалось на двух скромных дисках и пришлось засунуть простенький (но железный) LSI SAS1068...
>> Хуже встроенного в мать рейд-контроллера на 99% десктопных мамок быть не может.
> Предлагаю определиться с терминами.
> 1) насколько понимаю, разговор о FakeRAID и они действительно бывают хуже просто
> каналов;
> 2) на вроде бы как серверном tyan (двухсокетная оптеронная мать) однажды видел
> SiI3114, распаянный на PCI32/33(!) вместе с eth и ещё кучей всякого
> хлама, т.е. даже не отдельно -- в итоге оно затыкалось на
> двух скромных дисках и пришлось засунуть простенький (но железный) LSI SAS1068...Я работал с SB770-990 и все было ок.
> Я работал с SB770-990 и все было ок.Это не отменяет того, что там НЕТ RAID-контроллера xD
Там софтварная поделка. На уровне BIOS и драйвера для винды. Под Linux'ами все эти недорейды (очередной маркетоидный булшит) мейнтейнятся dm.Иногда бывают распаяны JBOD-контроллеры с поддержкой RAID в софте, типа того же Sil3114 (4 порта SATA150) - но это такой же фейк.
Видел давным давно топовую мамку (не вспомню сейчас названия) с распаянным нормальным Adaptec'ом, но это действительно было на тот момент топовое железо, за очень "невкусные" деньги.
>> Я работал с SB770-990 и все было ок.
> Это не отменяет того, что там НЕТ RAID-контроллера xD
> Там софтварная поделка. На уровне BIOS и драйвера для винды. Под Linux'ами
> все эти недорейды (очередной маркетоидный булшит) мейнтейнятся dm.
> Иногда бывают распаяны JBOD-контроллеры с поддержкой RAID в софте, типа того же
> Sil3114 (4 порта SATA150) - но это такой же фейк.
> Видел давным давно топовую мамку (не вспомню сейчас названия) с распаянным нормальным
> Adaptec'ом, но это действительно было на тот момент топовое железо, за
> очень "невкусные" деньги.Из криокамеры виднее :)))
На GA990XA есть даже RAID5 :)))
> Из криокамеры виднее :)))
> На GA990XA есть даже RAID5 :)))LOL :) Когда человек не отличает софт от аппаратуры - ну, флаг в руки, чо.
> LOL :) Когда человек не отличает софт от аппаратуры - ну, флаг
> в руки, чо.Как там в криокамере с флагом ? Удобно ?
>> Хуже встроенного в мать рейд-контроллера на 99% десктопных мамок быть не может.
> Предлагаю определиться с терминами.
> 1) насколько понимаю, разговор о FakeRAID и они действительно бывают хуже просто
> каналов;
> 2) на вроде бы как серверном tyan (двухсокетная оптеронная мать) однажды видел
> SiI3114, распаянный на PCI32/33(!) вместе с eth и ещё кучей всякого
> хлама, т.е. даже не отдельно -- в итоге оно затыкалось на
> двух скромных дисках и пришлось засунуть простенький (но железный) LSI SAS1068...SB990+RAID10+WD5003ABYX
http://s1.ipicture.ru/uploads/20121104/l5hbjRUD.jpg
> SB990+RAID10+WD5003ABYXЕщё думал спросить -- под фрёй эти fakeraid нормально работают?
> http://s1.ipicture.ru/uploads/20121104/l5hbjRUD.jpg
ЧТД. :)
>> SB990+RAID10+WD5003ABYX
> Ещё думал спросить -- под фрёй эти fakeraid нормально работают?
>> http://s1.ipicture.ru/uploads/20121104/l5hbjRUD.jpg
> ЧТД. :)SB770-990 работает ... а учитывая что zfs лучше вопрос - зачем ?
> SB990+RAID10+WD5003ABYX
> http://s1.ipicture.ru/uploads/20121104/l5hbjRUD.jpgSo what? Это фейкрейд. У md/dm/LVM/... производительность будет ровно такой же. А может быть даже и лучше - за счёт более тесной интеграции с ОС.
> So what? Это фейкрейд. У md/dm/LVM/... производительность будет ровно такой же.
> А может быть даже и лучше - за счёт более тесной интеграции с ОС.Всё же необязательно -- насколько помню слова vsu@altlinux, то у некоторых FakeRAID производительность при их задействовании как хоть чего-то поверх каналов бывала выше. Факторы IIRC получались такие:
- вымывание кэша CPU;
- догрузка CPU (+некоторые умели XOR для RAID5 сами[1]);
- догрузка FSB.Противоположный пример -- 16-портовая Areca лет пять тому не успевала даже просто JBOD через себя тащить, пришлось разбивать на две 8-портовки, чтоб хоть как каналы или зеркало заюзать.
Из эксплуатационной разницы ещё бывают жёлтые лямпочки на hdd carrier'ах, но это тоже не про десктоп, да и smartd не отменяет...
[1] http://lists.altlinux.org/pipermail/devel/2003-November/0971...
> Всё же необязательно -- насколько помню слова vsu@altlinux, то у некоторых FakeRAID
> производительность при их задействовании как хоть чего-то поверх каналов бывала выше.Сейчас обкатываются технологии USB 3.0 и SATA Revision 3.0 и с колличеством линий pci там все ок в отличии от серверного Г.
> Сейчас обкатываются технологии USB 3.0 и SATA Revision 3.0 и с
> колличеством линий pci там все ок в отличии от серверного Г./me выпал в осадок
ну чо, ждем от тебя тестов ZFS на USB 3.0
>> Сейчас обкатываются технологии USB 3.0 и SATA Revision 3.0 и с
>> колличеством линий pci там все ок в отличии от серверного Г.
> /me выпал в осадок
> ну чо, ждем от тебя тестов ZFS на USB 3.0Вот кстати внешние HD с usb3 уже в продаже но у меня их нет ...
> Вот кстати внешние HD с usb3 уже в продаже но у меня их нет ...Ну так и к чему приплетать? У меня дежурная флэшка уже USB3, разницы особой не было...
> Сейчас обкатываются технологии USB 3.0 и SATA Revision 3.0Да они-то тут при чём, особенно первое -- флэшкам оно помогает скорее на фоне никакого USB2. SATA6G наблюдаю в дешёвой all-in-one платке на C60 в количестве шести штук.
> в отличии от серверного Г.
А это уж кто что чем выбирал. :)
>> SB990+RAID10+WD5003ABYX
>> http://s1.ipicture.ru/uploads/20121104/l5hbjRUD.jpg
> So what? Это фейкрейд. У md/dm/LVM/... производительность будет ровно такой же. А
> может быть даже и лучше - за счёт более тесной интеграции
> с ОС.В случае md LVM сомневаюсь. Вот в случае хитрых алгоритмов gmirror или zfs очень даже может быть ;-)
> В случае md LVM сомневаюсь. Вот в случае хитрых алгоритмов gmirror или
> zfs очень даже может быть ;-)LOL'd
расскажите это авторам сего опуса"- Do I understand correctly that there are no analogues FreeBSD fallocate() and splice()?
- Why would we need them?"
(c) SirDice, http://forums.freebsd.org/showthread.php?p=195049:))) Шел 2012 год... Zero-Copy в *BSD даже не пахло.
splice - очень удобный механизм для zero-copy.
>> В случае md LVM сомневаюсь. Вот в случае хитрых алгоритмов gmirror или
>> zfs очень даже может быть ;-)
> LOL'd
> расскажите это авторам сего опуса
> "- Do I understand correctly that there are no analogues FreeBSD fallocate()
> and splice()?
> - Why would we need them?"
> (c) SirDice, http://forums.freebsd.org/showthread.php?p=195049
> :))) Шел 2012 год... Zero-Copy в *BSD даже не пахло.
> splice - очень удобный механизм для zero-copy.Там на форуме тоже одни троли :)))
>> Хуже встроенного в мать рейд-контроллера на 99% десктопных мамок быть не может.
> Предлагаю определиться с терминами.
> 1) насколько понимаю, разговор о FakeRAID и они действительно бывают хуже просто
> каналов;
> 2) на вроде бы как серверном tyan (двухсокетная оптеронная мать) однажды видел
> SiI3114, распаянный на PCI32/33(!) вместе с eth и ещё кучей всякого
> хлама, т.е. даже не отдельно -- в итоге оно затыкалось на
> двух скромных дисках и пришлось засунуть простенький (но железный) LSI SAS1068...Вот я и говорю - однажды дебил от маркетологов ляпнул что FakeRAID намного хуже а остальные дружно подхватили ... Учитывая что это высказываение является девизом сторожил криокамер вероятно речь идет о временах до ich7 когда интел был совсем гавно ...
> вероятно речь идет о временах до ich7 когда интел был совсем <beep>Да он с тех пор и LSI купил да за собой утянул. :( Те же SAS1064 -- самый что ни на есть FakeRAID.
> Да он с тех пор и LSI купил да за собой утянул.
> :( Те же SAS1064 -- самый что ни на есть
> FakeRAID.У меня сейчас RS2BL080 (он же LSI 9260-8i) дома стоит, приятная железка.
PCI-E x4. 8 портов SAS 2.0/SATA 600. 512M кэша.
RAID 0/1/10/5/6 (XOR и RSC - аппаратно, на контроллере).
Смена размера и типа LV на ходу поддерживается.Так что хоть интел его и потянул за собой в бюджетке... но уже в энтри-сегменте всё нормально :)
>> Те же SAS1064 -- самый что ни на есть FakeRAID.
> Так что хоть интел его и потянул за собой в бюджетке...Виноват, не уточнил -- эти 1064 они лепили как абортные в некоторые/многие S5000* (e.g. S5000VSA). Отдельных контроллеров, докатившихся до такого, пока у них не припоминаю.
> Вот я и говорю - однажды дебил от маркетологов ляпнул что FakeRAID
> намного хужеFakeRAID во всех случаях, за исключением RAID0:
а) нагружает проц многочисленными обменами с контроллером
б) многократно нагружает шину PCI/PCI-E данными
И тут хоть какой ICH - пока не будет аппаратного акселератора RAID, ничего не изменится.
>> Вот я и говорю - однажды дебил от маркетологов ляпнул что FakeRAID
>> намного хуже
> FakeRAID во всех случаях, за исключением RAID0:
> а) нагружает проц многочисленными обменами с контроллеромГде вы этого бреда набрались ? В даташитах по интелу ? Откройте для себя AMD.
> б) многократно нагружает шину PCI/PCI-E данными
Лол ... ноу коментс ... По сравнению с 4-мя двухголовыми видюхами он нагружает, не он Нагружает нет ваще нихера не нагружает :)))
> И тут хоть какой ICH - пока не будет аппаратного акселератора RAID,
> ничего не изменится.AMD лучше ;-)
Не вижу смысла дальше обсуждать - ты не понимаешь логики обмена с диском...
> Не вижу смысла дальше обсуждать - ты не понимаешь логики обмена с
> диском...Откройте даташит на SB770-990 если проблемы с логикой.
> Откройте даташит на SB770-990 если проблемы с логикой.datashit - у тебя в голове. К сожалению.
>> Откройте даташит на SB770-990 если проблемы с логикой.
> datashit - у тебя в голове. К сожалению.:))) пацталом ...
>> FakeRAID во всех случаях, за исключением RAID0:
>> а) нагружает проц многочисленными обменами с контроллером
> Где вы этого бреда набрались? В даташитах по интелу? Откройте для себя AMD.Сколько лет пользуюсь софтрейдами на том и этом, но такие откровения слышу впервые. Насколько понимаю, HT тут ни при чём.
> Сколько лет пользуюсь софтрейдами на том и этом, но такие откровения слышу
> впервые. Насколько понимаю, HT тут ни при чём.Абсолютно. Двойна-тройная-Nкратная передача данных по шине - абсолютно платформоагностична.
Хуже всего R5/6 - чтобы записать один блок - надо считать в кэш (прогнать по шине, а потом еще и рассчитать, в довесок) весь страйп (Nx), после чего записать два (R5) или три (R6) блока.
В R1 с двумя дисками будет просто двукратная запись... что тоже не гуд.
>>> FakeRAID во всех случаях, за исключением RAID0:
>>> а) нагружает проц многочисленными обменами с контроллером
>> Где вы этого бреда набрались? В даташитах по интелу? Откройте для себя AMD.
> Сколько лет пользуюсь софтрейдами на том и этом, но такие откровения слышу
> впервые. Насколько понимаю, HT тут ни при чём.Вы просто не следите за новостями. АМД несколько последних лет сливает интелу в пиковом быстродействии процессоров и все бы ничего но этот факт старательно подогревается в СМИ. Так как догнать интеловский утюг без перехода на новых техпроцесс невозможно амд старается увеличить быстродействие там где может например в работе системной логики. В частности материнские платы у АМД намного качественнее, не однократно сталкивались, если брать сервак в удаленном дц, то интел будет на матери очень низкого качества если амд всегда нормальная стабильная мать ... Мистика. В конце концев работать с интелом и асусом надоедает ... Что касается шедевров типа писипартнер или эзрок они редко живут дольше гарантийного срока и то если часто не включать :))
> Вы просто не следите за новостями.Мы просто судим не по новостям.
>> Вы просто не следите за новостями.
> Мы просто судим не по новостям.Бабка нагадала ?
Щас месье раскажет какой интел классный и какой амд слив .. ага.Ничего личного просто ссылки:
http://actika.livejournal.com/957.html
Меня особо вот эта ссылка доставляет - можно сразу на цитатник разрывать:
http://actika.livejournal.com/2712.html
> Меня особо вот эта ссылка доставляет - можно сразу на цитатник разрывать:
> http://actika.livejournal.com/2712.htmlОпровергните любое утверждение на выбор :)
> Опровергните любое утверждение на выбор :)Я ж говорю - там надо уже не опровергать, а на цитаты рвать, филиал баша.
>> Опровергните любое утверждение на выбор :)
> Я ж говорю - там надо уже не опровергать, а на цитаты
> рвать, филиал баша.Слив не защитан.
Привет с филиала удава.
> Щас месье раскажет какой интел классный и какой амд сливВообще-то работаю с самыми разными железками на intel/amd x86, arm, ppc, mips и ценю достоинства каждой из этих (микро)архитектур/платформ, при этом не забывая об уже известных их недостатках. Чего и Вам желаю.
BTW в #339 упомянул новую и специально выбранную платку на AMD C60. :)
> BTW в #339 упомянул новую и специально выбранную платку на AMD C60.
> :)Аналогично. Дома сервант как раз тот, который с LSI, на AMD PhII-1090T / AMD 890FX
Zero-copy сейчас туда впиливают. Дефрагментатор вроде как был (или планровался) - если я не забыл лекции архитекторов ZFS.
> Дефрагментатор вроде как был (или планровался) - если
> я не забыл лекции архитекторов ZFS.Главное чтоб дефрагментатор не был автоматическим как в ext4 а то ssd не оценят :))
> Главное чтоб дефрагментатор не был автоматическим как в ext4 а то ssd
> не оценят :))Да, для SSD уже само наличие ZFS - повод повеситься на ближайшем SATA-кабеле...
> Да, для SSD уже само наличие ZFS - повод повеситься на ближайшем
> SATA-кабеле...Ораклу расскажите.
>> Да, для SSD уже само наличие ZFS - повод повеситься на ближайшем
>> SATA-кабеле...
> Ораклу расскажите.А чего рассказывать? Достаточно взглянуть на спецификации железа под ZFS на их сайте, чтобы понять, что дело гиблое.
>>> Да, для SSD уже само наличие ZFS - повод повеситься на ближайшем
>>> SATA-кабеле...
>> Ораклу расскажите.
> А чего рассказывать? Достаточно взглянуть на спецификации железа под ZFS на их
> сайте, чтобы понять, что дело гиблое.Вот это что ли? Проблемз?
root @ hostname / # prtdiag|more
System Configuration: ASUS RS120-E5/PA4
BIOS Configuration: American Megatrends Inc. 0702 07/06/2009
BMC Configuration: IPMI 2.0 (KCS: Keyboard Controller Style)==== Processor Sockets ====================================
Version Location Tag
-------------------------------- --------------------------
Intel(R) Core(TM)2 Quad CPU Q8300 @ 2.50GHz Socket 775==== Memory Device Sockets ================================
Type Status Set Device Locator Bank Locator
------- ------ --- ------------------- --------------------
DDR2 in use 0 DIMM_A1 BANK0
unknown empty 0 DIMM_A2 BANK1
DDR2 in use 0 DIMM_B1 BANK2
unknown empty 0 DIMM_B2 BANK3==== On-Board Devices =====================================
To Be Filled By O.E.M.root @ hostname / # zpool status rpool
pool: rpool
state: ONLINE
scan: scrub repaired 0 in 0h20m with 0 errors on Sat Nov 3 06:20:11 2012
config:NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c1t0d0s0 ONLINE 0 0 0
c1t1d0s0 ONLINE 0 0 0errors: No known data errors
Для инфы - это прокси-сервер здания на сквиде.
> Для инфы - это прокси-сервер здания на сквиде.Да хватит уже показывать свой локалхост с двумя плашками памяти и двумя дисками в софтзеркале. Поставь на него винду с шарингом интернета, для мелкого склада/офиса больше и не надо. И не надо будет флюродросить на ZFS, дополнительным бонусом.
Или Netgear WNR1000 купи за 1000 рублев, зачем тебе такой прокси на маленькую конторку? По электричеству ж влетит в копеечку. И куда руководство смотрит.
> Для инфы - это прокси-сервер здания на сквиде.Вот уж для чего как раз и подходит спул на reiser3 с mkfs и squid -z на загрузке, если не лень, или вообще в tmpfs, если лень и от этого кэша хоть три грамма пользы наблюдается...
вы про технологию TRIM ?
> Главное чтоб дефрагментатор не был автоматическим как в ext4Ах, вы и ext4 только на картинке видели? Бывает.
Hint: в ext4 нет автоматического дефрагментатора. Хотя если хочется тупо зафэйлить на форуме - можно и про него рассказать. А потом народ еще удивляется - чего это я троллю? Ну а что еще делать, если вы порцию лулзов нахаляву предоставляете такими забавными тупняками? :)
>> Главное чтоб дефрагментатор не был автоматическим как в ext4
> Ах, вы и ext4 только на картинке видели? Бывает.
> Hint: в ext4 нет автоматического дефрагментатора. Хотя если хочется тупо зафэйлить на
> форуме - можно и про него рассказать. А потом народ еще
> удивляется - чего это я троллю? Ну а что еще делать,
> если вы порцию лулзов нахаляву предоставляете такими забавными тупняками? :)Ой а тут один пациент прямо с пеной доказывал что в ext4 помимо дефрагмертатора есть еще встроенные автоматические механизсы ... Выходит таки ошибся.
> Ой а тут один пациент прямо с пеной доказывал что в ext4
> помимо дефрагмертатора есть еще встроенные автоматические механизсы ... Выходит таки ошибся.Это про btrfs было ;). Теперь я понимаю почему вы постоянно киваете на проблемы с памятью.
> Zero-copy сейчас туда впиливают. Дефрагментатор вроде как был (или планровался) - если
> я не забыл лекции архитекторов ZFS."Будем считать что сделали, когда заработает". Пока что видно, что в BSD вообще с zero-copy всё плохо. Ну и да - правильная архитектура подразумевает замену ARC системным кешем. Будет?
Дефрагментатора не видел в принципе.
> "Будем считать что btrfs сделали, когда btrfs заработает".Так понятнее ?
Открою страшную тайну - ARC cache и системный кэш - немного разные вещи :)
То что Linux kernel их смешал в кучу - это его головная боль вытекающая из архитектуры ext[2,3,4], и поэтому все другие пожелания не принимаются в mainline.Кроме того одна и таже страница может быть в разных кэшах одновременно.
> То что Linux kernel их смешал в кучу - это его головная
> боль вытекающая из архитектуры ext[2,3,4], и поэтому все другие пожелания не
> принимаются в mainline.Нет смысла дублировать сущности - и это правильный подход, а не головная боль. Головная боль - это когда один кэш thrash'ит другой кэш только потому, что идио^W разработчики комбайна не удосужились реализовать нормальную схему работы.
> Кроме того одна и таже страница может быть в разных кэшах одновременно.
Может. Но в случае ZFS - не будет, ибо не zero-copy. А в Linux, c его "головной болью" кэш вполне может перетекать в приложения, и обратно. Без лишнего расхода памяти.
> Может. Но в случае ZFS - не будет, ибо не zero-copy. А
> в Linux, c его "головной болью" кэш вполне может перетекать в
> приложения, и обратно. Без лишнего расхода памяти.Сани всегда любили компенсировать технические продолбы маркетинговым буллшитом. Как впрочем и любая иная коммерческая компания шкурно заинтересованная в впаривании.
> Нет смысла дублировать сущности - и это правильный подход, а не головная боль.Как бы вам проще объяснить - кэши это таки места хранения и адресации, но данные не обязательно дублировать - достаточно использовать другие струтуры для доступа к данным.
> Головная боль - это когда один кэш thrash'ит другой кэш только потому, что идио^W разработчики комбайна не удосужились реализовать нормальную схему работы.начнем с того - что существуют разные политики для работы с памятью - комбинация оных дает оптимальную производительность с точки зрения данной FS. ARC cache у ZFS завязан на COW (если я правильно помню лекции). Приложение может почистить страницы из своего мапинга, но FS не обязательно закомитит свой ZIL. Остальное лень вспоминать.
а что касается производительности... Вот почему-то на машине выдерживающую нагрузку одного из TOP10 кластеров - все работает нормально. А у вас нет. Так может в чем-то другом проблемы ?
> Может. Но в случае ZFS - не будет, ибо не zero-copy. А в Linux, c его "головной болью" кэш вполне может перетекать в приложения, и обратно. Без лишнего расхода памяти.
Насколько я помню - там нет дублирования, а весь overhead из-за доп структур доступа. При этом в солярке ровно так же. Но это особенность данной FS, я так думаю у BTRFS будут не меньший overhead, не считая проблем при почти заполненом диске, как и у ZFS.
>> Нет смысла дублировать сущности - и это правильный подход, а не головная боль.
> Как бы вам проще объяснить - кэши это таки места хранения и
> адресации, но данные не обязательно дублировать - достаточно использовать другие струтуры для доступа к данным.Как бы вам проще объяснить: ARC дублирует системный кэш. Память ARC используется независимо, в системный кэш не перераспределяется, и операционкой при нехватке памяти для приложений не реюзается. Тчк. Всё остальное объясняйте разработчикам этого поделия.
> начнем с того - что существуют разные политики для работы с памятью
Начнём с того, что нет смысла городить два одинаковых независимых кэша. Можно было юзать логику системного кэша, если бы не мегакомбайновость. Остальное - лирика.
> комбинация оных дает оптимальную производительность с точки зрения данной FS.
Комбинация оных дает совершенно неоптимальный расход памяти.
> ARC cache у ZFS завязан на COW (если я правильно помню
> лекции). Приложение может почистить страницы из своего мапинга, но FS не
> обязательно закомитит свой ZIL. Остальное лень вспоминать.Системный кэш в Linux работает абсолютно так же. Приложение может убрать страницы из маппинга, но они не будут сброшены на диск или почищены сразу. У кого не так - мои соболезнования.
> а что касается производительности... Вот почему-то на машине выдерживающую нагрузку одного из TOP10 кластеров - все работает нормально. А у вас нет.
Оставьте уже академиков в покое - это единичные применения.
> Насколько я помню - там нет дублирования, а весь overhead из-за доп
> структур доступа.А ты не понимай - ты попробуй, и увидишь.
> особенность данной FS, я так думаю у BTRFS будут не меньший
> overhead, не считая проблем при почти заполненом диске, как и у
> ZFS.BTRFS использует системный кэш.
> а что касается производительности... Вот почему-то на машине выдерживающую нагрузку >одного из TOP10 кластеров - все работает нормально. А у вас нет.А что касается производительности btrfs то инстяляция убунты под варей при 1 гиге памяти заняла на btrfs по времени раз в 5 больше чем на ext4 и это при том что хост имел дохрена памяти и кешировал дисковые операции.
> Оставьте уже академиков в покое - это единичные применения.
Оставьте вы уже свое кривое поделие пока оно не станет релизом.
> А ты не понимай - ты попробуй, и увидишь.
Пробовали с btrfs жопа ...
> BTRFS использует системный кэш.
Замечательно - мы заметили как минимум две особенности - во первых оно experimental во вторых журнал имеет свойство расти до бесконечности что на мелких файлах ведет к неоправданному уменьшению доступного пространства ...
>> А ты не понимай - ты попробуй, и увидишь.
> Пробовали с btrfs жопа ...Укатали сивку крутые горки... Лучше вообще к компу подходить не пробуй - поможет.
>> BTRFS использует системный кэш.
> Замечательно - мы заметили как минимум две особенности - во первых оно
> experimental во вторых журнал имеет свойство расти до бесконечности что на
> мелких файлах ведет к неоправданному уменьшению доступного пространства ...Где-то в этой ветке тестировал - сильного уменьшения в зависимости от больших/мелких файлов нет в принципе.
> том что хост имел дохрена памяти и кешировал дисковые операции.Передает приветы тормозной fsync(). Дело в том что виртуализаторы этот вызов любят. Хоть это и настраиваемо (как минимум в quemu/kvm). А в районе 3.7 кернеля fsync() в btrfs изрядно подтянули.
>> Оставьте уже академиков в покое - это единичные применения.
> Оставьте вы уже свое кривое поделие пока оно не станет релизом.Релиз понятие растяжимое. Бсдшники вон релизнули ZFS с висючим sendfile(), нисколько не смущаясь. Если такими критериями оперировать - btrfs уже давно можно релизом считать.
> Пробовали с btrfs жопа ...
Да ладно, если особо извращенные ухищрения не устраивать - оно в общем то уже вполне работает. Хотя для ответственных применений лучше подождать.
>> BTRFS использует системный кэш.
> Замечательно - мы заметили как минимум две особенности - во первых оно
> experimental во вторых журнал имеет свойство расти до бесконечностиЭто общее свойство CoW. Поэтому и реализуется garbage collector. Логично его заодно и дефрагером делать. Почему в ZFS не сделали - а фиг знает.
> что на мелких файлах ведет к неоправданному уменьшению доступного пространства ...
А вот размер файлов при этом более-менее перпендикулярен. А какая разница то?
> Релиз понятие растяжимое. Бсдшники вон релизнули ZFS с висючим sendfile(), нисколько не
> смущаясь.Что то не припомню ...
бред не хочется даже сильно коментировать. Я понимаю что мисье не программист, а Одминистратор - которому напели баек и в которые он поверил. Блин но не удержался решил написать.Системный кэш в Linux kernel - это очень сильно порезаная LRU policy, ZFS требует для своей работы ARC policy (http://en.wikipedia.org/wiki/Adaptive_replacement_cache - при желании почитать и понять).
Там же в Wiki объясняется чем ARC лучше LRU, а тем более то убожество которое реализовано в Linux kernel.
Но это же священная корова которую никто трогать не будет.Еще раз - никакого копирования данных не происходит - просто страницы с данными находятся одновременно в ARC и LRU кэше. А возможно только в ARC - при этом этот алгоритм более совершенный, чем то убожество что есть в linux kernel.
Как пример могу указать на смешной баг - когда вымываются страницы содержащие block bitmap у ext4 при сколько нибудь серьезной нагрузке и система вынуждена повторно читать.А доп расходы по памяти это немного другое, это куча служебных структур - для того что бы держать COW и версионные изменения. И кроме того у него очень затянутый комит изменений на диск - что требует держать кучу всего в памяти, для более оптимальной аллокации блоков.
И это никак не связано с ARC кэшем который там внутри...
PS. я так думаю через пару лет в TO10 ext4 и вообще класических fs не будет, а будут решения на базе ZFS. Я так понимаю что вы считаете себя умнее Cray/SGI/HP ?
> Еще раз - никакого копирования данных не происходит - просто страницы с
> данными находятся одновременно в ARC и LRU кэше.Одни и те же физические или разные страницы с одинаковыми данными?
> бред не хочется даже сильно коментировать. Я понимаю что мисье не программист,
> а Одминистратор - которому напели баек и в которые он поверил.Несдержанность - удел вьюношей. К слову, я как раз-таки системный программист, и прекрасно представляю, о чем идет речь. ARC имеет преимущество только перед ядрами младше 2.6.26, в 2.6.26 (или в 2.6.25 - точно не помню) реализовали механизм Split LRU, который, в общем-то, и есть примерно то же самое, что применяется в ARC, только без изменения самого механизма замены страниц.
У ARC три проблемы:
1. ARC плохо работает (сильно нагружает систему) с малыми объемами кэша. Это проистекает из проблемы (2).
2. Алгоритм замены в ARC таков, что под высоким давлением на кэш работает крайне неэффективно. Это порождает проблему (1). Eviction страниц может занимать очень приличное время.
3. Алгоритм замены страниц покрыт патентом IBM. В связи с чем использовать в приложениях можно только на страх и риск.> Системный кэш в Linux kernel - это очень сильно порезаная LRU policy,
> ZFS требует для своей работы ARC policy (http://en.wikipedia.org/wiki/Adaptive_replacement_cache
> - при желании почитать и понять).
> Еще раз - никакого копирования данных не происходитТочнее - солярка скипает page cache при обращении к ARC, используя page cache только для страниц приложения. Сделано было из-за того, что механизмы солярки не позволяли нормально организовать zero-copy между двумя кэшами. *BSD юзают копирование между кешами - на странице нагуляла на лж четко видно, как падает производительность от отсутствия zero-copy. Linux не рассматриваем, поскольку BTRFS корректно юзает системный кеш, и никаких проблем с этим не имеет.
> просто страницы с данными находятся одновременно в ARC и LRU кэше
Пруф в студию - большинство "пейсателей" этот момент обходят стороной во всех презентациях и статьях. "Забывают", видимо.
> А доп расходы по памяти это немного другое, это куча служебных структур
> - для того что бы держать COW и версионные изменения.Почему этих расходов нет у BTRFS, при сходной (и более высокой) производительности? Архитектура, дружище, архитектура.
> кроме того у него очень затянутый комит изменений на диск -
> И это никак не связано с ARC кэшем который там внутри...Взаимоисключающие параграфы.
> Точнее - солярка скипает page cache при обращении к ARC, используя page
> cache только для страниц приложения. Сделано было из-за того, что механизмы
> солярки не позволяли нормально организовать zero-copy между двумя кэшами. *BSD юзают
> копирование между кешами - на странице нагуляла на лж четко видно,
> как падает производительность от отсутствия zero-copy. Linux не рассматриваем, поскольку
> BTRFS корректно юзает системный кеш, и никаких проблем с этим не
> имеет.Боюсь я вас разочарую но на моей странице четко видно что FreeBSD под варей без vmmemctl и с lsilogic работает похуже чем убунта с vmmemctl и pvscsi. А постестить на реальном железе пока нет времени. Тесты работают так что вперед.
> Боюсь я вас разочарую но на моей странице четко видно что FreeBSD
> под варей без vmmemctl и с lsilogic работает похужеБоюсь, тесты под виртуалкой малоинтересны: виртуализатор сильно искажает картину во всем что касается I/O.
>> Боюсь я вас разочарую но на моей странице четко видно что FreeBSD
>> под варей без vmmemctl и с lsilogic работает похуже
> Боюсь, тесты под виртуалкой малоинтересны: виртуализатор сильно искажает картину во всем
> что касается I/O.Скрипты доступны - тестируйте.
> и прекрасно представляю, о чем идет речь. ARC имеет преимущество только перед ядрами младше 2.6.26, в 2.6.26 (или в 2.6.25 - точно не помню) реализовали механизм Split LRU, который, в общем-то, и есть примерно то же самое, что применяется в ARC, только без изменения самого механизма замены страниц.Мне кажется не представляете. К слову в EL6 (2.6.32+) страницы из ext4 buddy cache вымываются аж в лет под активным чтением - что генерит тонну 4k чтений, по простейшим workload - чтение файла размером больше RAM кусками по 1М в 32 потока. Вот такой он LRU - собственно если это убрать - то это уже не LRU будет.
> Точнее - солярка скипает page cache при обращении к ARC, используя page cache только для страниц приложения. Сделано было из-за того, что механизмы солярки не позволяли нормально организовать zero-copy между двумя кэшами. *BSD юзают копирование между кешами - на странице нагуляла на лж четко видно, как падает производительность от отсутствия zero-copy.
Нету там copy. ссылки на код а не на какие-то тесты в студию.
> 3. Алгоритм замены страниц покрыт патентом IBM. В связи с чем использовать в приложениях можно только на страх и риск.Вас не смущает что RCU в ядре покрыт патентами IBM - при том что исключение сделано только для Linux kernel а остальные открытые проекты должны платить роялити за использование этой технологии? как и многое другое. Раз вас смущает - может вы тогда перестанете использовать Linux kernel?
>> просто страницы с данными находятся одновременно в ARC и LRU Кеше
>Пруф в студию - большинство "пейсателей" этот момент обходят стороной во всех презентациях и статьях. "Забывают", видимо.Пруфа не будет. Это была ~6часовая лекция от архитекторов ZFS которая по определенным причинам не писалась. Там же объяснялось почему ARC лучший алгортим для этого кэша, и почему остальные не подходят.
С математическим обоснованием если что. Математику я не помню - но помню что копирования там не происходит. И не потому что нельзя было сделать zero-copy.
> А доп расходы по памяти это немного другое, это куча служебных структур
> - для того что бы держать COW и версионные изменения.
> Почему этих расходов нет у BTRFS, при сходной (и более высокой) производительности? Архитектура, дружище, архитектура.У BTRFS другие проблемы как вы помните. Не эфективная балансировка дерева, плохое использование свободного места и тп.. напомнить ? Архитектура такая вот кривая у BTRFS....
> кроме того у него очень затянутый комит изменений на диск -
> И это никак не связано с ARC кэшем который там внутри...
> Взаимоисключающие параграфы.это вам так кажется.
> Пруфа не будет. Это была ~6часовая лекция от архитекторов ZFS которая по
> определенным причинам не писалась. Там же объяснялось почему ARC лучший алгортим
> для этого кэша, и почему остальные не подходят.Скорее всего то, что объяснялось - и есть причина, по которой "лекция" не писалась. Т.е. маркетинговый буллшит, который инженеры разнесут в пух и прах.
>> Пруфа не будет. Это была ~6часовая лекция от архитекторов ZFS которая по
>> определенным причинам не писалась. Там же объяснялось почему ARC лучший алгортим
>> для этого кэша, и почему остальные не подходят.
> Скорее всего то, что объяснялось - и есть причина, по которой "лекция"
> не писалась. Т.е. маркетинговый буллшит, который инженеры разнесут в пух и
> прах.Что бы закрыть тему - лекцию читал Bill Moore прилетевший из Штатов в Москву ради этой лекции. Это тоже такой маркетолог?
JFYI, злоупотреблять отзывчивостью человека и впрямь не лучшее дело. А ссылки на "такие приборы" и "определённые причины" -- могут работать при наличии взаимопонимания, но вовсе не для его достижения.
> JFYI, злоупотреблять отзывчивостью человека и впрямь не лучшее дело. А ссылки
> на "такие приборы" и "определённые причины" -- могут работать при наличии
> взаимопонимания, но вовсе не для его достижения.Зато хорошо показали - что человек мыслит шаблонами, не пытаясь задуматься о альтернативах.
Для него все что сделал Sun - это марктенговый булшит..Только боюсь что в Linux world - такого еще больше. Чего только стоит требование шапки не ставить Trial версию RHEL6 на машину с более чем 2 sockets или core (не помню уж точно - но в свое время весьма порадовало).
PS. все таки 2 сокета - поставил на 4 - уже обязан удалить - это у нас теперь такой opensource который требует оплачивать по сокетам с клиентов?
"Thank you for choosing SER0220US - 30-day Unsupported Evaluation Red Hat Enterprise Linux (Up to 2 Sockets)."
> Для него все что сделал Sun - это марктенговый булшит..Именно. Если бы было не так - Sun бы до сих пор существовал. Но... история не терпит сослагательного наклонения, и Sun ныне там, где и должен быть - в могиле.
> удалить - это у нас теперь такой opensource который требует оплачивать
> по сокетам с клиентов?CentOS отменили?
>> Для него все что сделал Sun - это марктенговый булшит..
> Именно. Если бы было не так - Sun бы до сих пор
> существовал. Но... история не терпит сослагательного наклонения, и Sun ныне там,
> где и должен быть - в могиле.Угу. С каких финансовые показатели стали мерилой качества?
Тогда стоит признать что майкрософт и apple это лучшие конторы, ибо их финансовые показатели очень хороши. И сильно лучше всяких там RedHat, не говоря уже о сдохшей SuSe (Novel).>> удалить - это у нас теперь такой opensource который требует оплачивать
>> по сокетам с клиентов?
> CentOS отменили?Не считая их собственных ошибок, CentOS выходит сильно позже, кроме того - почему это RedHat`у можно брать деньги по сокетам, а Oracle за это осуждают. Двойная мораль?
> Угу. С каких финансовые показатели стали мерилой качества?Капитализм, батенька. Кто неконкурентоспособен - тот сдох или продался. Единственное мерило в условиях рынка, однако. Каким бы сферическим конем оно ни было - оно в итоге оказалось нежизнеспособно :)
> Тогда стоит признать что майкрософт и apple это лучшие конторы
А с этим кто-то спорит? Они до сих пор успешно подминают под себя все, до чего в силах дотянуться. Правда, у МС последнее время не всё гладко тоже.
> И сильно лучше всяких там RedHat, не говоря уже о сдохшей SuSe (Novel).
FYI, они находятся в разных сегментах рынка. Показателей RedHat у MS в его сегменте нет, никогда не было, и не будет. Тем паче - у Apple. В своих сегментах это - лучшие компании, и спорить с этим бессмысленно.
> Не считая их собственных ошибок, CentOS выходит сильно позже
Вот за сие и берутся редхатом деньги. Не нравится - берёте исходники, и собираете сами. "Не сильно позже". А вы, видимо, халявщик по жизни, раз хотите задарма скорость коммерческого сервиса. OpenSource гарантирует наличие исходников, но никак не уровень сервиса.
>> Угу. С каких финансовые показатели стали мерилой качества?
> Капитализм, батенька. Кто неконкурентоспособен - тот сдох или продался. Единственное мерило
> в условиях рынка, однако. Каким бы сферическим конем оно ни было
> - оно в итоге оказалось нежизнеспособно :)Еще раз - каким боком капитализм - относится к техническому качеству?
давайте без переводов стрелок.>> Тогда стоит признать что майкрософт и apple это лучшие конторы
> А с этим кто-то спорит? Они до сих пор успешно подминают под
> себя все, до чего в силах дотянуться. Правда, у МС последнее
> время не всё гладко тоже.Да ну - разве софт от MS - это не маркитоидный бред и булшит? В отличии от той же солярки..
>> И сильно лучше всяких там RedHat, не говоря уже о сдохшей SuSe (Novel).
> FYI, они находятся в разных сегментах рынка. Показателей RedHat у MS в
> его сегменте нет, никогда не было, и не будет. Тем паче
> - у Apple. В своих сегментах это - лучшие компании, и
> спорить с этим бессмысленно.Да ну - у MS есть WinServer и у RedHat тоже есть RHEL - так что они в одном сегменте..
>> Не считая их собственных ошибок, CentOS выходит сильно позже
> Вот за сие и берутся редхатом деньги. Не нравится - берёте исходники,
> и собираете сами. "Не сильно позже". А вы, видимо, халявщик по
> жизни, раз хотите задарма скорость коммерческого сервиса. OpenSource гарантирует наличие
> исходников, но никак не уровень сервиса.Я лишь хочу что бы RedHat предоставлял все то что положено по GPL. как исходники - так и derivative work - то есть бинарные пакеты, но все предпочитают закрывать на это нарушение GPL и то что даже доступные бинарники - анально огорожены - запретом в EULA.
Вот у меня есть 4 sockets оптерон - я хочу посмотреть и возможно потом купить туда RedHat EL - но я это не могу сделать, так как стану нарушителем EULA. Но наличие такой EULA - почему-то прощают RedHat, но не прощают Oracle - почему ?
> Я лишь хочу что бы RedHat предоставлял все то что положено по
> GPL. как исходники — так и derivative work — то есть
> бинарные пакетыэ… ЩИТО? с каких грибов выхлоп компилятора стал derivative work? это я что, опубликовав исходник под GPL, должен ещё и по первому требованию каждому предоставлять собраный мной бинарь? сдай дилера.
ну, дальнейшие рассуждения примерно на том же уровне, нет смысла анализировать.
> Еще раз - каким боком капитализм - относится к техническому качеству?Самым прямым. Всё, что не покупается в силу низкого качества или завышенной по отношению к нему цены - умирает.
> Да ну - разве софт от MS - это не маркитоидный бред
> и булшит? В отличии от той же солярки..Бред, булшит, но миллиарды хомячков не могут ошибаться. Так что булшит, но не всё. Для домохозяйки - самое оно.
> Да ну - у MS есть WinServer и у RedHat тоже есть RHEL - так что они в одном сегменте..
Удивляюсь узости понимания сегментации рынка. Покажите мне mass production web на винде, тогда подумаю. Или mass virtualization. Или cloud filesystem. Для начала.
> Я лишь хочу что бы RedHat предоставлял все то что положено по
> GPL. как исходники - так и derivative workПочитайте GPL, для начала. Потом уже хотите. Они исходники обязаны предоставлять только собственным клиентам, вместе с бинарями, а вам - не обязаны. А бинари открыто - вообще никому не обязаны.
> Вот у меня есть 4 sockets оптерон - я хочу посмотреть и возможно потом купить туда RedHat EL - но я это не могу сделать, так как стану нарушителем EULA.
Попросите у RH триалку на 4 сокета - наверняка пойдут навстречу.
> Что бы закрыть тему - лекцию читал Bill Moore прилетевший из Штатов
> в Москву ради этой лекции. Это тоже такой маркетолог?Шишкин тоже хвалит райзер 4 :) - хотя ныне абсолютно неюзабельное поделие... К чему бы сие?
>> Что бы закрыть тему - лекцию читал Bill Moore прилетевший из Штатов
>> в Москву ради этой лекции. Это тоже такой маркетолог?
> Шишкин тоже хвалит райзер 4 :) - хотя ныне абсолютно неюзабельное поделие...И его есть за что хвалить. Многие вещи которые туда заложены - весьма и весьма революционны был для своего времени, и ребята работали там очень грамотные.
И если вы такой серьезный программист - то должны были знать что проблемы с включением в mainstream - лежали больше политические, и то что Linux хотел что бы все прогибались под VM которая нужна ext[2-4], а не другим.
А то что он не развивается - ну так просто.. всю команду которая работала в namesys перекупила одну фирма - и они до сего времени так и работают практически одной командой над новыми задачами :)> К чему бы сие?
К тому что я больше верю квалификацию Bill Moore - чем в вашу. То что вы мыслите шаблонами - мы уже поняли. Все что не по вашему - это булшит и прочая гадость, а то что могут быть проблемы в ваших любимых няшечках - вы не верите.
> Пруфа не будет. Это была ~6часовая лекция от архитекторов ZFS которая по
> определенным причинам не писалась. Там же объяснялось почему ARC лучший алгортим
> для этого кэша, и почему остальные не подходят.
> С математическим обоснованием если что. Математику я не помню - но помню
> что копирования там не происходит. И не потому что нельзя было
> сделать zero-copy.Учитывая реализацию криптования сжатия и дедупликации данные в кеше zfs лежат не всегда в том виде в котором их получит потребитель а потому zero-copy как бы не к месту.
>> Почему этих расходов нет у BTRFS, при сходной (и более высокой) производительности?
Потому что адекватных тестов где BTRFS тупо не сливат из-за разростания журнала еще никто не видел.
> У BTRFS другие проблемы как вы помните.
О да ...
>> Пруфа не будет. Это была ~6часовая лекция от архитекторов ZFS которая по
>> определенным причинам не писалась. Там же объяснялось почему ARC лучший алгортим
>> для этого кэша, и почему остальные не подходят.
>> С математическим обоснованием если что. Математику я не помню - но помню
>> что копирования там не происходит. И не потому что нельзя было
>> сделать zero-copy.
> Учитывая реализацию криптования сжатия и дедупликации данные в кеше zfs лежат не
> всегда в том виде в котором их получит потребитель а потому
> zero-copy как бы не к месту.там все сложнее - насколько я помню эту лекцию, использование ARC cache связан как-то с отложенными транзакциями и переменным размером блока и версионностью - ну и всякие ssd cache на отдельном носителе.
> насколько я помню эту лекциюи то правда: зачем писать было. ведь всё отлично запомнил!
>> насколько я помню эту лекцию
> и то правда: зачем писать было. ведь всё отлично запомнил!зачем писать - когда можно было оформить командировку и прокатиться в силиконовую долину и на месте пообщаться с людьми? Или это так сложно для arisu?
вот, вроде, умный человек — а дурак-дураком, и резко перестаёт понимать, когда упускаешь хотя бы одно очевидное промежуточное звено. общая беда многих людей, кстати: нежелание ворочать мозгами.
>[оверквотинг удален]
>> а Одминистратор - которому напели баек и в которые он поверил.
> Несдержанность - удел вьюношей. К слову, я как раз-таки системный программист, и
> прекрасно представляю, о чем идет речь. ARC имеет преимущество только перед
> ядрами младше 2.6.26, в 2.6.26 (или в 2.6.25 - точно не
> помню) реализовали механизм Split LRU, который, в общем-то, и есть примерно
> то же самое, что применяется в ARC, только без изменения самого
> механизма замены страниц.
> У ARC три проблемы:
> 1. ARC плохо работает (сильно нагружает систему) с малыми объемами кэша. Это
> проистекает из проблемы (2).Свист. Вот конфига со специально ограниченным объемом ARC (ибо нефиг дважды кэшировать кэширующее приложение):
root @ hostname / # arc_summary.pl
System Memory:
Physical RAM: 4087 MB
Free Memory : 421 MB
LotsFree: 63 MBZFS Tunables (/etc/system):
set zfs:zfs_arc_max=1073741824
set zfs:zfs_immediate_write_sz=1000000000
set zfs:zvol_immediate_write_sz=1000000000ARC Size:
Current Size: 549 MB (arcsize)
Target Size (Adaptive): 550 MB (c)
Min Size (Hard Limit): 128 MB (zfs_arc_min)
Max Size (Hard Limit): 1024 MB (zfs_arc_max)ARC Size Breakdown:
Most Recently Used Cache Size: 25% 138 MB (p)
Most Frequently Used Cache Size: 74% 412 MB (c-p)ARC Efficency:
Cache Access Total: 280931200
Cache Hit Ratio: 60% 169987501 [Defined State for buffer]
Cache Miss Ratio: 39% 110943699 [Undefined State for Buffer]
REAL Hit Ratio: 55% 155276719 [MRU/MFU Hits Only]Data Demand Efficiency: 78%
Data Prefetch Efficiency: 8%CACHE HITS BY CACHE LIST:
Anon: 0% 551949 [ New Customer, First Cache Hit ]
Most Recently Used: 56% 96231400 (mru) [ Return Customer ]
Most Frequently Used: 34% 59045319 (mfu) [ Frequent Customer ]
Most Recently Used Ghost: 4% 7615752 (mru_ghost) [ Return Customer Evicted, Now Back ]
Most Frequently Used Ghost: 3% 6543081 (mfu_ghost) [ Frequent Customer Evicted, Now Back ]
CACHE HITS BY DATA TYPE:
Demand Data: 56% 95663016
Prefetch Data: 3% 6607943
Demand Metadata: 35% 59611727
Prefetch Metadata: 4% 8104815
CACHE MISSES BY DATA TYPE:
Demand Data: 23% 26362489
Prefetch Data: 60% 67203256
Demand Metadata: 10% 11923431
Prefetch Metadata: 4% 5454523
---------------------------------------------Top:
====
load averages: 0.00, 0.01, 0.01; up 25+14:24:52 00:26:05
242 processes: 241 sleeping, 1 on cpu
CPU states: 99.8% idle, 0.0% user, 0.2% kernel, 0.0% iowait, 0.0% swap
Kernel: 460 ctxsw, 22 trap, 667 intr, 1299 syscall, 22 flt
Memory: 4095M phys mem, 422M free mem, 4096M total swap, 4069M free swapPID USERNAME LWP PRI NICE SIZE RES STATE TIME CPU COMMAND
19933 root 1 54 0 2528K 1664K cpu/0 0:00 0.07% top
11560 root 1 59 0 734M 726M sleep 33:06 0.03% squid
10 root 13 59 0 12M 7324K sleep 0:12 0.00% svc.startd
11756 squid 1 59 0 2904K 1284K sleep 0:59 0.00% diskd-daemon
953 root 1 100 -20 2608K 1328K sleep 1:02 0.00% xntpd
11754 squid 1 59 0 2904K 1292K sleep 0:57 0.00% diskd-daemon
11757 squid 1 59 0 2904K 1300K sleep 0:55 0.00% diskd-daemon
11755 squid 1 59 0 2904K 1304K sleep 0:58 0.00% diskd-daemon
33310 squid 1 59 0 9608K 2732K sleep 0:40 0.00% httpd
773 root 1 59 0 1468K 720K sleep 0:03 0.00% utmpd
441 root 1 59 0 0K 0K sleep 0:22 0.00% ipmon
52753 clamav 2 59 0 422M 288M sleep 222:00 0.00% clamd
12 root 14 59 0 11M 9144K sleep 0:19 0.00% svc.configd
97 root 9 59 0 3896K 1624K sleep 0:12 0.00% devfsadm
779 root 19 59 0 19M 7004K sleep 0:10 0.00% fmdПокажь, плз, сильную нагрузку как следствие урезанного ARC?
> 2. Алгоритм замены в ARC таков, что под высоким давлением на кэш
> работает крайне неэффективно. Это порождает проблему (1). Eviction страниц может занимать
> очень приличное время.Выше - покажь? Кэш уменьшен и на него сильное давление. Это так-то весьма нагруженный прокси.
> 3. Алгоритм замены страниц покрыт патентом IBM. В связи с чем использовать
> в приложениях можно только на страх и риск.Пруфа, как я понимаю, не будет?
>[оверквотинг удален]
>> просто страницы с данными находятся одновременно в ARC и LRU кэше
> Пруф в студию - большинство "пейсателей" этот момент обходят стороной во всех
> презентациях и статьях. "Забывают", видимо.
>> А доп расходы по памяти это немного другое, это куча служебных структур
>> - для того что бы держать COW и версионные изменения.
> Почему этих расходов нет у BTRFS, при сходной (и более высокой) производительности?
> Архитектура, дружище, архитектура.
>> кроме того у него очень затянутый комит изменений на диск -
>> И это никак не связано с ARC кэшем который там внутри...
> Взаимоисключающие параграфы.У тебя заявления с практикой как-то не вяжутся. И, да - система, с которой я приводил данные - Солярис:
root @ hostname / # uname -a
SunOS hostname 5.10 Generic_147441-15 i86pc i386 i86pc Solaris
>> 3. Алгоритм замены страниц покрыт патентом IBM. В связи с чем использовать
>> в приложениях можно только на страх и риск.
> Пруфа, как я понимаю, не будет?на то, что ARC запатентован? если ты не можешь в этом убедиться максимум за пол-минуты, то ты или очень медленно печатаешь, или у тебя интернеты на 300 бод, или ты альтернативно одарённый.
>>> 3. Алгоритм замены страниц покрыт патентом IBM. В связи с чем использовать
>>> в приложениях можно только на страх и риск.
>> Пруфа, как я понимаю, не будет?
> на то, что ARC запатентован? если ты не можешь в этом убедиться
> максимум за пол-минуты, то ты или очень медленно печатаешь, или у
> тебя интернеты на 300 бод, или ты альтернативно одарённый.Вот десвительно пруф ф студию :))
И что собственно портянка выше должна пруфнуть?
> Несдержанность - удел вьюношей. К слову, я как раз-таки системный программист, и
> прекрасно представляю, о чем идет речь. ARC имеет преимущество только перед
> ядрами младше 2.6.26, в 2.6.26 (или в 2.6.25 - точно не
> помню) реализовали механизм Split LRU, который, в общем-то, и есть примерно
> то же самое, что применяется в ARC, только без изменения самого
> механизма замены страниц.Хорошо приложил очередного адепта маркетингового буллшита :)
> У ARC три проблемы:
Приятно читать гражданина который шарит и может кондово так приложить.
> как падает производительность от отсутствия zero-copy. Linux не рассматриваем, поскольку
> BTRFS корректно юзает системный кеш, и никаких проблем с этим не имеет.Что не мешает гражданам от соляриев и бсд выступать. Хотя по бенчам даже древних версий все прекрасно видно.
> Почему этих расходов нет у BTRFS, при сходной (и более высокой) производительности?
> Архитектура, дружище, архитектура.Потому что в отличие от саней в линуксах маркетинговый буллшит не очень срабатывает. Их юзают не за то что крЮтой производитель с железками за кучу бабла, а за то что работает и работает прилично. Вот и приходится делать так чтобы работало прилично :)
все они хороши, и вызвает попоболь у линуксоидов
> все они хороши, и вызвает попоболь у линуксоидовДа, потому что хотя у них ZFS тоже есть, такое они терпеть они не собираются.
> Скорее это заявка на то что TOP100 будет таким и клон ext4
> будет вырублен оттуда.
> теперь подскажите какая еще fs может динамически аллоцировать иноды?reiserfs (сколько там ей лет? 12-13?), jfs (сколько там ей лет? 15? 17?), ext4.
> Вот вы изначально сделали одно количество инод - а у вас получилось
> что хранятся более мелкие файлы и вам не хватает инод, при
> этом свободного места на диск вагон. Решите эту проблему с ext4,
> xfs и тп (не знаю как там в новомодной btrfs). Причем
> это задача из реальной жизни.Сколько тебе лет? 11? 12?
> Сколько тебе лет? 11? 12?В годик всё-таки с tty disciplines не ковыряются обычно...
>> Скорее это заявка на то что TOP100 будет таким и клон ext4
>> будет вырублен оттуда.
>> теперь подскажите какая еще fs может динамически аллоцировать иноды?
> reiserfs (сколько там ей лет? 12-13?), jfs (сколько там ей лет? 15?
> 17?), ext4.рейсер - можно сказать умер давно. Все его разработчики заняты более другими задачами.
jfs - так и не родился
ext4 - не умел, не умеет и не будет иметь.
xfs - да, что-то такое имеет - но похоже только в версии для IRIX.хватит писать бред в чем не разбираетесь.
> рейсер - можно сказать умер давно. Все его разработчики заняты более другими
> задачами.
> jfs - так и не родился
> ext4 - не умел, не умеет и не будет иметь.
> xfs - да, что-то такое имеет - но похоже только в версии
> для IRIX.
> хватит писать бред в чем не разбираетесь.Шел 2012 год. Мы развлекались как могли. Ниодна из файловых систем unix а тем более win не могда вписать а не перезаписать блок в середину файла или вырезать из середины и не с конца. Без перезаписи всего хвоста файла. Хотябы блок кратный блоку фс. О передаче блоков между файлами даже не стоит вспоминать ... ППЦ
ЗЫ Дармаеды...:)))
> Шел 2012 год. Мы развлекались как могли. Ниодна из файловых систем unix
> а тем более win не могда вписать а не перезаписать блок
> в середину файла или вырезать из середины и не с конца.
> Без перезаписи всего хвоста файла. Хотябы блок кратный блоку фс. О
> передаче блоков между файлами даже не стоит вспоминать ... ППЦШел 2012 год. Неуловимый Джо так и не был пойман... ибо нахрен никому не спёрся.
> Шел 2012 год. Неуловимый Джо так и не был пойман... ибо нахрен
> никому не спёрся.Примерно такие же отмазки лепяп на форуме. Судя по
http://www.mail-archive.com/freebsd-hackers@freebsd.org...
неуловимого Джо ищут более 4-х лет ...
> Примерно такие же отмазки лепяп на форуме. Судя по
> http://www.mail-archive.com/freebsd-hackers@freebsd.org...
> неуловимого Джо ищут более 4-х лет ...Ну зачем же так путать preallocate с "TRIM" (в кавычках потому, что адекватного термина даже нет пока... sparse-trim? хз)?
preallocate в линухах был уже давно, еще до 2008 года.
> Шел 2012 год. Мы развлекались как могли. Ниодна из файловых систем unix
> а тем более win не могда вписать а не перезаписать блок
> в середину файла или вырезать из середины и не с конца.Шел 2012 год. А автомобили так и ездили по дорогам. Хотя технически ничто не мешало ставить крылья и турбореактивный двигатель и нагло штурмовать звуковой барьер.
>> Шел 2012 год. Мы развлекались как могли. Ниодна из файловых систем unix
>> а тем более win не могда вписать а не перезаписать блок
>> в середину файла или вырезать из середины и не с конца.
> Шел 2012 год. А автомобили так и ездили по дорогам. Хотя технически
> ничто не мешало ставить крылья и турбореактивный двигатель и нагло штурмовать
> звуковой барьер.Ничего кроме уродливых образований под названием - государства...
> jfs - так и не родился
> хватит писать бред в чем не разбираетесь.Ну так не пишите.
>> Давай спрыгнем с крыши по этому поводу? Что нормальная промышленная ФС, разработанная
>> профи, таки стала доступна в лине?
> И где оно-таки промышлится? Кроме как у академиков на локалхостах, пока ни
> у кого не видел.bta.kz
> Давай спрыгнем с крыши по этому поводу? Что нормальная промышленная ФС, разработанная
> профи, таки стала доступна в лине?Глядя на "быструю" работу ZFS и дикий жрач памяти, напрашивается вывод - может, Бонвик со товарищи и профи в какой-нибудь области, но явно не в разработке фс.
// Прыгайте, я разрешаю :)
>> Давай спрыгнем с крыши по этому поводу? Что нормальная промышленная ФС, разработанная
>> профи, таки стала доступна в лине?
> Глядя на "быструю" работу ZFS и дикий жрач памяти, напрашивается вывод -
> может, Бонвик со товарищи и профи в какой-нибудь области, но явно
> не в разработке фс.
> // Прыгайте, я разрешаю :)Ваши инсунуации по поводу жрача ZFS и аскетизма BTRFS не подтвердились в тестах так как BTRFS отказался писать после заполнения 70% диска ...
> Ваши инсунуации по поводу жрача ZFS и аскетизма BTRFS не подтвердились в
> тестах так как BTRFS отказался писать после заполнения 70% диска ...Вам AlexAT уже перечислил все очевидне недостатки: CoW без дефрагера, с дебильно сделанным кешом и странноватым дизайном - нет, для пробного шара - нормально, но в 2012 году можно и получше. В btrfs сие сделали. Там почему-то и кэш работает обычно, а не аляповатые чудеса от саней, и экстенты нормальные реализовали, и дефрагер который для CoW достаточно нужная штука - есть. Да, в линуксах не принято маркетинговый буллшит впаривать. А какой смысл обманывать самих себя?
> Вам AlexAT уже перечислил все очевидне недостатки: CoW без дефрагера, с дебильно
> сделанным кешом и странноватым дизайном - нет, для пробного шара -
> нормально, но в 2012 году можно и получше. В btrfs сие
> сделали.Будем считать что сделали когда заработает.
> Да, в линуксах не принято маркетинговый
> буллшит впаривать.Это привет из криокамеры ? Линукс сплошной маркетинг ...
>А какой смысл обманывать самих себя?
Смысл срубить бабла.
> Будем считать что сделали когда заработает.У вас оно же заработает позднее, если вообще.
> Это привет из криокамеры ? Линукс сплошной маркетинг ...
Имелся в виду линукс который кернель. Это и есть линукс. Маркетинга там около нуля.
> Смысл срубить бабла.
На линуксном ядре без нифига? Ололо.
>> Будем считать что сделали когда заработает.
> У вас оно же заработает позднее, если вообще.У нас оно заработает когда тест перестанет падать. Так сколько мелких файлов можно записать на 6-ти гиговый раздел с btrfs ? 4 гига ? Похоже там не все ок с архитектурой ...
> ? Похоже там не все ок с архитектурой ...По-моему не все ок с головой у тех кто такие тесты проводит. У меня диск на 6Гб был... давно. У меня флеха и то на 8. При том чтобы на флеху btrfs пихать - надо не очень дружить с головой.
> У нас оно заработает когда тест перестанет падать. Так сколько мелких файлов
> можно записать на 6-ти гиговый раздел с btrfs ? 4 гига
> ? Похоже там не все ок с архитектурой ...# mount
/dev/sdh1 on /data/btrfs type btrfs (rw)# df -h /dev/sdh1
Файловая система Разм Исп Дост Исп% смонтирована на
/dev/sdh1 16G 14G 13M 100% /data/btrfs# du -h
2,4G ./Hyakko
5,4G ./Kamisama no Memochou
14G .14G/16G - вполне нормально, 2G вероятно зарезервировано.
Теперь мелким файлом...
# i=1; while [ $i -le 16000 ] ; do echo $i ; dd if=/dev/zero of=test$i bs=1048576 count=1; i=$[$i+1]; done
Удаётся записать 14307 файлов - т.е. тоже 14G, что еще раз наводит на мысли о резервировании ~1-2G под метаданные. Причем после файлы нулевой длины продолжают создаваться - место под каталог есть, но данные объёмом в метр уже не пишутся.
# df -h /dev/sdh1
Файловая система Разм Исп Дост Исп% смонтирована на
/dev/sdh1 16G 15G 960K 100% /data/btrfs# du -c
14650372 .
14650372 итогоСтираю произвольным образом 4Gb данных (4096 файлов), и пишу на их место файл объемом почти в два гига.
Читаем файлик (для проверки на кеширование - два раза):
# dd if=\[Coalgirls\]_Katanagatari_01_\(1920x1080_Blu-Ray_FLAC\)_\[8DC80306\].mkv of=/dev/zero bs=16777216
124+1 записей считано
124+1 записей написано
скопировано 2083825966 байт (2,1 GB), 26,3548 c, 79,1 MB/c# dd if=\[Coalgirls\]_Katanagatari_01_\(1920x1080_Blu-Ray_FLAC\)_\[8DC80306\].mkv of=/dev/zero bs=16777216
124+1 записей считано
124+1 записей написано
скопировано 2083825966 байт (2,1 GB), 25,9846 c, 80,2 MB/cНет, это не SSD. Обычный SATA HDD (Seagate серии 11). Благодаря тому, что экстентный аллокатор порубил диск на блочки по 1Мб - фрагментация файла, похоже, не так высока.
Вот как-то так. А "академики" могут продолжать тестировать непонятно что на рамдисках.
> Вот как-то так. А "академики" могут продолжать тестировать непонятно что на рамдисках.Тесты dd как то не очень актуальны, bonnie++ в помощ.
>[оверквотинг удален]
> Файловая система Разм Исп Дост
> Исп% смонтирована на
> /dev/sdh1
> 16G 15G 960K 100% /data/btrfs
> # du -c
> 14650372 .
> 14650372 итого
> Стираю произвольным образом 4Gb данных (4096 файлов), и пишу на их место
> файл объемом почти в два гига.
> Читаем файлик (для проверки на кеширование - два раза):дальше можно не смотреть. Мисье системный программист не знает такой элементарщины как
sysctl -w vm.drop_caches=3
тогда о чем мы можем говорить?
> sysctl -w vm.drop_caches=3
> тогда о чем мы можем говорить?Не вижу смысла обсуждать танцы с бубном для Linux - как скзал "слоник" должно работать "из каропки".
> Не вижу смысла обсуждать танцы с бубном для Linux - как скзал
> "слоник" должно работать "из каропки".Именно. Никаких плясок вокруг дропов кешей и прочего. Всё так, как считает нужным ОС. В достаточно жестких условиях - 512Мб RAM.
>> Не вижу смысла обсуждать танцы с бубном для Linux - как скзал
>> "слоник" должно работать "из каропки".
> Именно. Никаких плясок вокруг дропов кешей и прочего. Всё так, как считает
> нужным ОС. В достаточно жестких условиях - 512Мб RAM.а что тогда мы проверяем 2мя чтениями? :) как хорошо система кэширует данные? :)
Спасибо - это просто сферический конь в вакуме.Вообще по правилам QA - каждый perormance testing должен быть в чистом окружении, с не прогретым кэшем. А что тут тестируют - не понятно.
> а что тогда мы проверяем 2мя чтениями? :) как хорошо система кэширует
> данные? :)
> Спасибо - это просто сферический конь в вакуме.Когда сможете закешировать 2 гига в 512 метрах - приходите.
>> а что тогда мы проверяем 2мя чтениями? :) как хорошо система кэширует
>> данные? :)
>> Спасибо - это просто сферический конь в вакуме.
> Когда сможете закешировать 2 гига в 512 метрах - приходите.Мне что то подсказывает что в тесте не всегда будут читаться все 2 гига и что попадания в кеш вполне возможны.
> Мне что то подсказывает что в тесте не всегда будут читаться все
> 2 гига и что попадания в кеш вполне возможны.Это как, простите?
> Вообще по правилам QA - каждый perormance testing должен быть в чистом
> окружении, с не прогретым кэшем.поэтому сферические тесты в вакууме и интересуют только сферических дятлов в вакууме.
> sysctl -w vm.drop_caches=3
> тогда о чем мы можем говорить?Смысла не имело, поскольку объём системной памяти площадки - 512Мб :)
> Стираю произвольным образом 4Gb данных (4096 файлов), и пишу на их место файл объемом почти в два гига.
> Читаем файлик (для проверки на кеширование - два раза):а о функции sysctl -w vm.drop_caches=3, мисье системный программист не в курсе?
Остальное - это не тестирование - это профанация этого.
> а о функции sysctl -w vm.drop_caches=3, мисье системный программист не в курсе?См.выше.
> Да, в линуксах не принято маркетинговый буллшит впаривать.Читаю #123, #122 и понимаю, что каноникаловский маркетинг убунтушникам не так заметен...
> А какой смысл обманывать самих себя?
Разница начинается вместе с продуктом, для себя обычно достаточно технологии.
> Читаю #123, #122 и понимаю, что каноникаловский маркетинг убунтушникам не так заметен...Я про линуксный кернель. Какой смысл им там всем вместе сильно врать? И кого они обманут? Самих себя? :)
>> А какой смысл обманывать самих себя?
> Разница начинается вместе с продуктом, для себя обычно достаточно технологии.И тем не менее, технология особенно хороша когда правильно подана. ДВС сам по себе - кусок металла, который довольно сложно куда-то применить простому смертному. А в виде готового автомобиля - уже представляет некую пользу, etc.
> разработанная профи, таки стала доступна в лине?Титаник тоже профи разработали. Да еще и непотопляемым называли. А оказалось - вполне себе потопляемый...
> ZFS.linux и больше нихера не нужноНаверно не будет ZFS.linux пока ораклу нужно продавать саны ...
> Наверно не будет ZFS.linux пока ораклу нужно продавать саны ...У ZFS.linux шансы на выживание все же побольше, чем у ZFS.freebsd. На лине хотя бы свои разработчики есть, а не только копипастеры.
>> Наверно не будет ZFS.linux пока ораклу нужно продавать саны ...
> У ZFS.linux шансы на выживание все же побольше, чем у ZFS.freebsd. На
> лине хотя бы свои разработчики есть, а не только копипастеры.Ода шансы так и прут :-)) у бубунте уже на рабочем столе реклама прописалась :-)) не смогут брать бабло за дистр будут брать бабло за отключение рекламы и прочей хери.
Какие конструктивные и профессиональные аргументы.
> ораклу нужно продавать саны ...Ораклу похрен что продавать. Ему не нyжно "продавать саны". Ему бабки нужны. Клиентура просит линукс. Значит будет линукс. Они вон вполне охотно unbreakable linux-ом барыжат.
>> ораклу нужно продавать саны ...
> Ораклу похрен что продавать. Ему не нyжно "продавать саны". Ему бабки нужны.
> Клиентура просит линукс. Значит будет линукс. Они вон вполне охотно unbreakable
> linux-ом барыжат.Потому что у него цель не человечество облагодетельствовать. А вполне себе одного человека. Владельца. Собственно, как и у любого НОРМАЛЬНОГО вменяемого бизнеса.
> Собственно, как и у любого НОРМАЛЬНОГО вменяемого бизнеса.Это в котором подобные Вам -- сменные винтики по шекелю кучка, а платиновые партнёры решают развал RAC сами, поскольку поддержка всех уровней решить не в состоянии?..
Н-да, докатились уже с мерками нормальности. Прям в пару к http://www.opennet.me/openforum/vsluhforumID3/87021.html#64
>> Собственно, как и у любого НОРМАЛЬНОГО вменяемого бизнеса.
> Это в котором подобные Вам -- сменные винтики по шекелю кучка, а
> платиновые партнёры решают развал RAC сами, поскольку поддержка всех уровней решить
> не в состоянии?..Милый мой, я, в отличие от тебя, владелец действующего бизнеса. А ты, говоришь, по шекелю работать готов? Пожалуй, тебя не найму - болтаешь много не по теме.
> Милый мойЭто к партнёрам.
> я, в отличие от тебя, владелец действующего бизнеса.
Похоже, проблемы с BI на бытовом уровне. Впрочем, считайте как хотите.
>> Милый мой
> Это к партнёрам.
>> я, в отличие от тебя, владелец действующего бизнеса.
> Похоже, проблемы с BI на бытовом уровне. Впрочем, считайте как хотите.Взаимно, друг мой, взаимно.
У Теодора фамилия звучит как "Шоу".
> У Теодора фамилия звучит как "Шоу".Чё не Чао? ...Сяо?!..
> Чё не Чао? ...Сяо?!..Российский летчик Ли Си Цын :)
>> Чё не Чао? ...Сяо?!..
> Российский летчик Ли Си Цын :)Так-то в оригинале это был вьетнамский летчик.
>> Российский летчик Ли Си Цын :)
> Так-то в оригинале это был вьетнамский летчик.Если уж докапываться, то _заявленный_ как вьетнамский. :)
PS: и времена были ещё союзные, ага.
zfs trim = http://people.freebsd.org/~pjd/patches/zfstrim8.patch>> kstat.zfs.misc.zio_trim.zio_trim_bytes: 0
>> kstat.zfs.misc.zio_trim.zio_trim_success: 0
>> kstat.zfs.misc.zio_trim.zio_trim_unsupported: 0
>> kstat.zfs.misc.zio_trim.zio_trim_failed: 2742
>>> kstat.zfs.misc.zio_trim.zio_trim_failed: 2742failed - это "прекрасно" :)
но тем не менее - появилсо
ждем сообщений нагуляла о том, "как прекрасен этот TRIM"
только теперь не отмажется уже
>>>> kstat.zfs.misc.zio_trim.zio_trim_failed: 2742
> failed - это "прекрасно" :)
> но тем не менее - появилсо
> ждем сообщений нагуляла о том, "как прекрасен этот TRIM"
> только теперь не отмажется ужеА нахер он нужен ? Включаете компрессию и получаете тоже самое только на годами проверенных алгоритмах.
> А нахер он нужен ? Включаете компрессию и получаете тоже самое только
> на годами проверенных алгоритмах.Бррррр. Совсем заклинило? Какое отношение имеет компрессия к TRIM?
>> А нахер он нужен ? Включаете компрессию и получаете тоже самое только
>> на годами проверенных алгоритмах.
> Бррррр. Совсем заклинило? Какое отношение имеет компрессия к TRIM?Жесть ... а что такое по вашему компрессия?
> Жесть ... а что такое по вашему компрессия?Уменьшение избыточности данных.
>> Жесть ... а что такое по вашему компрессия?
> Уменьшение избыточности данных.ППЦ а что такое избыточность ?
> ППЦ а что такое избыточность ?Читайте уже теорию, хотя бы для общего развития. А то, не зная элементарных вещей, лезете в дебри c TRIM/компрессией и т.д.
http://en.wikipedia.org/wiki/Data_compression - для ликбеза пойдёт. Если плохо с английским - можете прочитать и русский вариант, но он менее информативен.
>> ППЦ а что такое избыточность ?
> Читайте уже теорию, хотя бы для общего развития. А то, не зная
> элементарных вещей, лезете в дебри c TRIM/компрессией и т.д.
> http://en.wikipedia.org/wiki/Data_compression - для ликбеза пойдёт. Если плохо с английским
> - можете прочитать и русский вариант, но он менее информативен.Ура месье открыл для себя кмпресси ... попутно гугль и вики. Осталось открыть разницу между компрессией и дейпликацией.
> Ура месье открыл для себя кмпресси ... попутно гугль и вики. Осталось
> открыть разницу между компрессией и дейпликацией.А теперь читаем выше - и видим, что тобой написано слово "компрессия". А не "дедупликация".
Дедупликация тоже, строго говоря, относится к компрессии. Только к очень-очень хреновой - на уровне блочных повторов фиксированного размера. Поэтому всерьез её никто компрессией обычно не называет.
Но вот какое таки отношение даже дедупликация имеет к TRIM, чёрт побери? xD
Может быть, у вас какая-то особая, уличная компрессия/дедупликация?
>> Ура месье открыл для себя кмпресси ... попутно гугль и вики. Осталось
>> открыть разницу между компрессией и дейпликацией.
> А теперь читаем выше - и видим, что тобой написано слово "компрессия".
> А не "дедупликация".
> Дедупликация тоже, строго говоря, относится к компрессии. Только к очень-очень хреновой
> - на уровне блочных повторов фиксированного размера. Поэтому всерьез её никто
> компрессией обычно не называет.Ну вот оказывается дедупликация это хреновая компрессия ... непрошло и пол года.
> Но вот какое таки отношение даже дедупликация имеет к TRIM, чёрт побери?
Вот действительно причем тут трим ?
> Вот действительно причем тут трим ?Совсем плохо, да?
Цитирую в первоисточнике:
"
> ждем сообщений нагуляла о том, "как прекрасен этот TRIM"
> только теперь не отмажется ужеА нахер он нужен ? Включаете компрессию и получаете тоже самое только на годами проверенных алгоритмах.
"
>> Вот действительно причем тут трим ?
> Совсем плохо, да?
> Цитирую в первоисточнике:
> "
>> ждем сообщений нагуляла о том, "как прекрасен этот TRIM"
>> только теперь не отмажется уже
> А нахер он нужен ? Включаете компрессию и получаете тоже самое только
> на годами проверенных алгоритмах.
> "Еслиб месье так херовато передергивал на выборах его бы уже привлекли ...
> Еслиб месье так херовато передергивал на выборах его бы уже привлекли ...Точно, клиника. Ну и да - много не передергивай, а то отвалится...
>> Еслиб месье так херовато передергивал на выборах его бы уже привлекли ...
> Точно, клиника. Ну и да - много не передергивай, а то отвалится...Так вот кто предлагал в темноте под одеялом ...
И че серьезно ? 8-0
>>> Осталось открыть разницу между компрессией и дейпликацией.
> Ну вот, оказывается, дедупликация -- это хреновая компрессия... не прошло и полгода.Осталось открыть разницу между дедупликацией и дейдупликацией. :)
>> Но вот какое-таки отношение даже дедупликация имеет к TRIM, чёрт побери?
> Вот действительно, причем тут трим?Именно это у Вас и спрашивали (#249) в ответ на высказывание вида "зачем бэкапы, когда есть годами проверенный рейд".
TRIM это комманды посылаемые ссд (сата-контроллеру)
компресия выравнивает блоки но а сам trim уже работает с блоками оперативки внутри ssd кеша
> TRIM это комманды посылаемые ссд (сата-контроллеру)
> компресия выравнивает блоки но а сам trim уже работает с блоками оперативки
> внутри ssd кешаконечно, если в ссд контроллере присутсвует трим ;)
> TRIM это комманды посылаемые ссд (сата-контроллеру)
> компресия выравнивает блоки но а сам trim уже работает с блоками оперативки
> внутри ssd кешаКаким образом _компрессия_ выравнивает блоки? :)
> компресия выравнивает блокиС фига ли? Никогда неизвестно заранее насколько сожмется тот или иной кусок данных.
>> ждем сообщений нагуляла о том, "как прекрасен этот TRIM" только теперь не отмажется уже
> А нахeр он нужен ? Включаете компрессию и получаете тоже самоеЭто пять. Вот уж не знал что компрессия заменяет trim.
http://svnweb.freebsd.org/base?view=revision&revision=240868
мой сервер# sysctl -a | grep trim
vfs.zfs.trim_disable: 0
vfs.zfs.trim_txg_limit: 64
kstat.zfs.misc.zio_trim.zio_trim_bytes: 7420416
kstat.zfs.misc.zio_trim.zio_trim_success: 848
kstat.zfs.misc.zio_trim.zio_trim_unsupported: 5380
kstat.zfs.misc.zio_trim.zio_trim_failed: 0
