Крис Мейсон (Chris Mason), автор файловой системы Btrfs, сообщил (http://permalink.gmane.org/gmane.comp.file-systems.btrfs/23006) об интеграции в основной Git-репозиторий проекта экспериментальной реализации RAID5 (http://ru.wikipedia.org/wiki/RAID#RAID_5) и RAID6 (http://ru.wikipedia.org/wiki/RAID#RAID_6), встроенной в Btrfs. Поддержка RAID5/6 доступна для тестирования в рамках ветки raid56-experimental, созданной как для компонентов Btrfs уровня ядра, так и для набора утилит btrfs-progs.Отмечается, что хотя реализация RAID5/6 во многом похожа на MD raid, встраивание поддержки RAID в Btrfs имеет ряд преимуществ. Например, имеется возможность применения разных уровней RAID к метаданным и непосредственно хранимым данным или можно инициировать частичное перестроение RAID в случае выявления несоответствия контрольных сумм в процессе работы ФС. Кроме того, появляется возможность выполнения таких операций как перестановка данных между дисками (restriping) или добавление/удаление дисков в привязке к транзакциям в ФС. В будущем планируется обеспечить привязку логики работы RAID к состоянию метаданных ФС, например, в процессе функционирования RAID пропускать операции чтения для блоков, не задействованных в ФС.
В процессе тестирования реализация RAID5/6 в Btrfs заметно опередила по производительности MD raid, в основном благодаря устранению некоторых узких мест и задействованию таких особенностей как переработанный кэш распределения данных по дискам (Stripe cache), поддержка слияния частичных stripe-операций и вычисления контрольных сумм без задержки, в синхронном режиме. Кроме того, отмечается меньшая эффективность кэширования в MD, приводящая к большему числу операций чтения с дисков.
При оценке работы системы с 4 дисками и 2 накопителями fusionio, RAID5/6 в Btrfs при линейном копировании большого файла продемонстрировал пропускную способность 604MB/s, в то время как пропускная способность MD raid составила 162MB/s. Скорость чтения в Btrfs составила 380MB/s, а MD - 174MB/s (примечательно, что для MD скорость записи и чтения одинаковая, а для Btrfs отличается примерно в два раза). Тест на создание 12 млн файлов был выполнен для Btrfs raid5 за 226 секунд, а реализации на базе MD затратила 485 секунд.
Из пока не реализованных, но запланированных на ближайшее время возможностей отмечается поддержка операции scrub для проверки наличия bad-блоков на входящих в RAID дисков; поддержка операции TRIM (discard), которая позволит увеличить производительность при работе с SSD-накопителями и повысить их срок службы; добавление в набор утилит поддержки частичного перестроения RAID (parity rebuild); возможность множественного зеркалирования (тройное зеркало из RAID1).URL: http://permalink.gmane.org/gmane.comp.file-systems.btrfs/23006
Новость: http://www.opennet.me/opennews/art.shtml?num=36011
Ну, наконец-то, не прошло и два года... Только, imho, ближайший год-два этой фичей можно будет только на экспериментальных машинах играться.Тем не менее, btrfs потихоньку набирает критическую массу опций (снапшоты, поддержка рейда, сжатие), которые позволят ей наконец-то занять достойное место в ряду FS.
P.S. Родной RAID5/6 - это та вещь в btrfs, которую я уже давно жду. Пока же обхожусь ветхозаветной, но надежной комбинацией mdraid+LVM+ext4 ;)
Вопрос такой: а Вы уверены, что он (btrfs) будет в итоге работать лучше, чем "ветхозаветные" комбинации?Не далее как в пятницу переформатировал в md0/ext4 свой полутерабайтный том btrfs/raid0 (да-да, stripe), использовавшийся у меня как "рабочий" (т.е. под чекауты рабочих репозиториев и каталоги компиляции). Выяснилось, что gcc и javac начали на этом томе работать в несколько раз медленнее, чем "с обычным порошком", при этом, все шесть ядер проца стоят колом. Понятное дело, что этот эффект появился не сразу, а после >года использования в этом режиме.Ядро 3.6.9. Честно говоря, предметно разбираться с тем, где оно там тупит, времени/желания не было, но, в общем, ничего "старшного" я на этом томе не делал.
> Не далее как в пятницу...
> ... этот эффект появился не сразу, а после года использования:-/
> Тем не менее, btrfs потихоньку набирает критическую массу опций (снапшоты, поддержка рейда, сжатие), которые позволят ей наконец-то занять достойное место в ряду FS.Поддерживаю. Сам на нее облизываюсь.
> Выяснилось, что gcc и javac начали на этом томе работать в несколько раз медленнее, чем "с обычным порошком"
Это говорит лишь о том, что пока не готов. Ключевое слово "пока".
>Это говорит лишь о том, что пока не готов. Ключевое слово "пока".6 лет уже это "пока не готов". К 2030 будет готов?
xfs & zfs , да и линейка ext по 10 лет развивались, это нормально
Два? 6 лет они пилят если не больше. И каждый год это "btrfs работатет в следующем ядре намного быстрее и фичастее". Ставишь на комп - тормозища нереальные. Там же не задача трех тел решается и не диффуры, как можно простую копировалку данных с места на место пилить 6+ лет?
> "btrfs работатет в следующем ядре намного быстрее и фичастее".Ну так не врут же. Оно так и есть, внезапно.
> Там же не задача трех тел решается и не диффуры, как можно простую копировалку данных с места на место пилить 6+ лет?Там не "простая копировалка" - а файловая система. Что действительно - несколько сложнее чем вполне себе исследованная "задача трех тел"...
Хотя кто-то их ругал (Шишкин?), что, грубо говоря, btrfs делают не "по науке", а методом "давай сделаем так, мне кажица будет круто".
> комп - тормозища нереальные. Там же не задача трех тел решается
> и не диффуры, как можно простую копировалку данных с места на место пилить 6+ лет?А как можно куски металла и бетона годами перекладывать? Строительство любого крупного объекта почему-то требует уйму времени. Хотя казалось бы - куски металла или бетона, а то и вовсе какие-то примитивные кирпичи между собой соединить. Наверное секрет в том что из простых сущностей в сумме собирается навороченный и сложный агрегат.
Фуфло. Самый быстрый и надежный RAID - 10ка. Только жопешники с пустым кошельком используют пятерку в 2013м году, когда шпиндели стоят как лопата дерьма. С трехкратным снижением скорости записи.
> кошельком используют пятерку в 2013м году, когда шпиндели стоят как лопатаУгу, только 5-ка дает емкость (N-1) накопителей. Ну пусть (N-2) для горячего резерва. А у вас емкость N/2. В результате вы получаете из 12 накопителей только емкость 6. А с RAID5 - емкость как у 11 накопителей. Некая разница. Кроме цены есть еще занимаемое место, пожираемая энергия (+еще и охлаждение, если ее много).
При этом с raid5 на 12 дисков шанс вылета любых двух уж очень большой. Даже если вылетает один диск, риск словить ошибку на оставшихся дисках при перестроении и обломаться тоже велик.
А если надежность нам не нужна, а нужно экономить копейки - можно и stripe юзать.
В чём проблема? Используйте Raid 6 =)
> При этом с raid5 на 12 дисков шанс вылета любых двух уж очень большой.Двух дисков ОДНОВРЕМЕННО - таки низкий. А кто долго работает с degraded рэйдом - ССЗБ.
А никто и не говорит про ОДНОВРЕМЕННОВторой диск должен вылелеть в течении времени перестройки массива
Сколько будет перестраиваться нагруженный массив R5 из 12 дисков, например, по 2Тб - задание посчитать в свободное время. Необходимо учесть что на ВСЕ диски пойдет повышенная нагрузка. Вообщем я бы поостерегся очень сильно делать R5 на 12 дисках. Немногим лучше R0 получится 8-)
> А никто и не говорит про ОДНОВРЕМЕННО
> Второй диск должен вылелеть в течении времени перестройки массива
> Сколько будет перестраиваться нагруженный массив R5 из 12 дисков, например, по 2Тб
> - задание посчитать в свободное время. Необходимо учесть что на ВСЕ
> диски пойдет повышенная нагрузка. Вообщем я бы поостерегся очень сильно делать
> R5 на 12 дисках. Немногим лучше R0 получится 8-)Послушайте, аноны, вы никогда не видели одновременный отказ ДВУХ промышленных кондеров для серверной с потребляемой мощностью 130 квт? Я - видел. Температура мгновенно подскакивает до +65 в помещении. Серверная ДВОЕ СУТОК стояла без охлаждения. Машинки работали, там не писишное гогно было, а весьма жаростойкие СПАРКи. Однако - через неделю - ОДНОВРЕМЕННЫЙ вылет 147 винтов. Как вы думаете, что было бы, если бы использовали RAID-5?
Серверная ДВОЕ СУТОК стояла без
> охлаждения. Машинки работали, там не писишное гогно было, а весьма жаростойкие
> СПАРКи. Однако - через неделю - ОДНОВРЕМЕННЫЙ вылет 147 винтов. Как
> вы думаете, что было бы, если бы использовали RAID-5?НУ ССЗБ же, хренли оборудование не выключили раз всё так плохо???
И простите, какой RAID вас спасёт от вылета "одовременно 147 винтов"????
Если по теме, RAID-6 даёт достаточную надежность, поскольку даже если во время перестроения RAID'а е**нёт еще один винт, то всё будет нормально, а это вполне возможный CASE ибо во время перестроения нагрузка на диски выше.
> Температура мгновенно подскакивает до +65А если в серверную закинуть коктейль молотова - вообще красота будет.
Админчики локалхоста, такие админчики. У самих знаний не хватает так хоть читайте людей работающих в сфере СХД
http://blog.aboutnetapp.ru/archives/975
http://blog.aboutnetapp.ru/archives/223
Вы забыли написать "на правах рекламы".То что в нетапе есть только RAID-DP не делает его серебряной пулей.
Почему у всех разоблачителей так плохо с глазами и мозгами. Там официальные данные из нескольких мест по надёжности рейдов. Может в будущем тебе доверят какую-нибудь СХДшку начального уровня и ты лично сможешь потестить как на работе сказывается перестроение рейд5 в боевом режиме.
предлагаю охрененно быстрый на запись raid6 соответствующий RAID 6 (block-level striping with double distributed parity) provides fault tolerance up to two failed drives.
Суть:
1. имеем 5 дисков A B C D E
2. пишем первый блок получаем
A1 B1 C1 D E
3. Пишем второй блок получаем
A1 B1 C1 D2 E2
A2
3. Пишем третий блок получаем
A1 B1 C1 D2 E2
A2 B3 C3 D3число - номер блока данных (сектор логического диска поверх рейда)
буква - дискв результате удаления любых 2х дисков мы всегда можем прочитать всю инфу.
для буквоедов про четность: четность вычисляется как data xor 0все окуенно быстрый на запись raid6 как и на чтение готов. реализуйте. идея распространяется под gpl v2
ты неправ. Если диски примерно из одной партии (сразу кучу купил в одном месте одну и ту же модель) и диск вылетел уже больше из-за долгого времени работы, а не из-за брака, то при добавлении нового диска и перестроении рэйда не очень мелок шанс что вылетит и второй диск из той же "старой" партии - уж слишком большая нагрузка ложится на диски при перестроении.
> С трехкратным снижением скорости записи.На полном серьезе спрашиваю, а если на пятерке сделать так
echo 8192 > /sys/block/md0/md/stripe_cache_size
как скорость чтения/записи измениться ?
>> С трехкратным снижением скорости записи.
> На полном серьезе спрашиваю, а если на пятерке сделать так
> echo 8192 > /sys/block/md0/md/stripe_cache_size
> как скорость чтения/записи измениться ?Ты на полном серьезе натурально не сечешь, как работает 5 рэйд. Он считает CRC для КАЖДОГО записываемого блока. Смекаешь? При мало-мальски приличном объеме записи что происходит и как это зависит от размера блока?
У raid10 нет контроля четности. При сопоставлении заявленных BLER и объемах современных SATA-винтов наличие контрольной суммы - весомый аргумент.
Нужна скорость - RAID1 + ssd-cache.
> У raid10 нет контроля четности. При сопоставлении заявленных BLER и объемах современных
> SATA-винтов наличие контрольной суммы - весомый аргумент.
> Нужна скорость - RAID1 + ssd-cache.ZFS? С криптографическими контрольными суммами сквозными?
Да, особенно, когда берешь СХД за $2М, где диски занимают по $800к.
> Фуфло. Самый быстрый и надежный RAID - 10ка. Только жопешники с пустым
> кошельком используют пятерку в 2013м году, когда шпиндели стоят как лопата
> дерьма. С трехкратным снижением скорости записи.А ещё стоимость свободных SAS/SATA портов довольно высока, чтобы их расходовать на излишнюю избыточность.
> А ещё стоимость свободных SAS/SATA портов довольно высока, чтобы их расходовать на
> излишнюю избыточность.Ну не все же хранят на винтах только порево с торентов, которое при факапе можно просто перекачать заново, да?
> Тем не менее, btrfs потихоньку набирает критическую массу опций (снапшоты, поддержка рейда, сжатие), которые позволят ей наконец-то занять достойное место в ряду FS.У меня язык не поворачивается назвать этот комбайн ФС.
Ну, может это и не разу не юникс-вей, но мне, как конечному пользователю, глубоко пофиг на тонкости реализации того или иного "черного ящика", если только он будет хорошо выполнять свои функции (минимум потребляемых ресурсов, максимум фич и надежности).В данном случае я предпочел бы возможность рулить своими данными из одного места и btrfs, вроде как, эту возможность в теории предоставляет (про практику скромно умолчим).
По-моему Linux сейчас отходит от Unix-way, так что некритично,подумаешь, одним комбайном больше.
Давно ушел, если говорить о линуксе как о ядре. Это мегакомбаин, наверно самый комбпинистый в истории.
ну назовите того, кто не ушёл.
может соляра с её комбайном zfs?зыж
странные рассуждения чесслово. бтр хоть использует структуры и механизмы ядра.
> странные рассуждения чесслово. бтр хоть использует структуры и механизмы ядра.Да уж. А ZFSина таскает свой кэш, который кернель даже не может при душняке с памятью гарантированно потеснить. Это может и не проблема если машина целиком отдана под файлопомойку, но проблема во всех остальных случаях.
>ну назовите того, кто не ушёл.plan9/inferno, qnx, например :3. еще вроде aix, но я с ним дела не имел
> plan9/inferno, qnx, например :3. еще вроде aix, но я с ним дела не имелВот вы ими и пользуйтесь наздоровье, а я пешком постою и пингвином попользуюсь как-нибудь. Он может и не расово верный с точки зрения академиков, зато работает и довольно хорошо.
p.s.: не очень понятно почему вы мне отвечаете, а не тому индивиду.
>> plan9/inferno, qnx, например :3. еще вроде aix, но я с ним дела не имел
> Вот вы ими и пользуйтесь наздоровье, а я пешком постою и пингвином
> попользуюсь как-нибудь. Он может и не расово верный с точки зрения
> академиков, зато работает и довольно хорошо.
> p.s.: не очень понятно почему вы мне отвечаете, а не тому индивиду.Вы невкуриваете, UNIX - это:
From February 1995, computer systems have carried the UNIX brand if:
They guarantee to support the services specified in the Single UNIX Specification.
Customers can identify UNIX certified products by the Open Brand logo and the mandatory
attribution declaring to which version of the specification the product complies:- UNIX 93 applies to UNIX system products which pre-date the Single UNIX Specification.
- UNIX 95 applies to UNIX system products which conform to the Single UNIX Specification.
- UNIX 98 applies to UNIX system products which conform to the Single UNIX Specification , Version 2.
- UNIX 03 applies to UNIX system products which conform to the Single UNIX Specification , Version 3.See the platform pages for the latest information.
In licensing the UNIX brand a vendor warrants and represents that every certified product:
- Conforms to the specification.
- Meets The Open Group's test and certification requirements.
- Will continue to conform to the specification.
- Will be rectified within an agreed time should it be found to be non-conformant.UNIX certification is widely recognized as the international symbol of assurance in open systems.
By the end of 2001, the value of procurements of open systems referencing the brand had exceeded $25 billion.---
Из того что вспомню - в Linux нету <float.h> и <iso646.h>
---
Кстати, самый "чистый" UNIX живущий до сих пор - SCO OpenServer :)
> Из того что вспомню - в Linux нету <float.h> и <iso646.h>Ох, надо побрить брови в знак траура :'(.
> Кстати, самый "чистый" UNIX живущий до сих пор - SCO OpenServer :)
Не хочешь им попользоваться? И таки он живет, не сдох? А то SCOты свою репутацию заср@ли в хламину просто.
>> Из того что вспомню - в Linux нету <float.h> и <iso646.h>
> Ох, надо побрить брови в знак траура :'(.
>> Кстати, самый "чистый" UNIX живущий до сих пор - SCO OpenServer :)
> Не хочешь им попользоваться? И таки он живет, не сдох? А то
> SCOты свою репутацию заср@ли в хламину просто.Какие ещё знакомые буквы встретил в тексте, кроме SCO ?
>> Из того что вспомню - в Linux нету <float.h> и <iso646.h>это потому что ты олух.
<float.h> — The functionality described on this reference page is aligned with the ISO C standard. http://www.opennet.me/man.shtml?topic=float.h&category=3&rus...
<iso646.h> — The functionality described on this reference page is aligned with the ISO C standard. http://www.opennet.me/man.shtml?topic=iso646.h&category=3&ru...зыж
и да, man float.h и man iso646.h тоже есть в каждом линухе (ну, где есть man :D).
ззыж
павлин, если всё ещё не понял намёка — <float.h> и <iso646.h> идёт в составе компилятора (претендующего на поддержку ISO C standard). другими словами и на примере:
для gcc 4.7.2:
$ ls -l /usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/include/{float,iso646}.h
-rw-r--r-- 1 root root 8905 янв. 24 16:21 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/include/float.h
-rw-r--r-- 1 root root 1279 янв. 24 16:21 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/include/iso646.h
для clang 3.1:
$ ls -l /usr/lib64/clang/3.1/include/{float,iso646}.h
-rw-r--r-- 1 root root 3870 дек. 11 18:05 /usr/lib64/clang/3.1/include/float.h
-rw-r--r-- 1 root root 1565 дек. 11 18:05 /usr/lib64/clang/3.1/include/iso646.h
>[оверквотинг удален]Ой пля, звиняйте шо все стандарты ПОСИХ наизусть не помню
> Ой пля, звиняйте шо все стандарты ПОСИХ наизусть не помнюДа за что звинять то? Зафэйленый троллинг - это тоже вариант. Так даже забавнее. Для всех кроме того кто его зафэйлил :)
>> Ой пля, звиняйте шо все стандарты ПОСИХ наизусть не помню
> Да за что звинять то? Зафэйленый троллинг - это тоже вариант. Так
> даже забавнее. Для всех кроме того кто его зафэйлил :)Слухайте, че вы мне тут мозг выносите ...
В /usr/include/ нет этих файлов, то что они есть в ГЦЦ - ну и флаг им в руки!
Заголовки должны быть в /usr/include/, и все хедеры LIBC, и только тот компилер
считается ПОСИХовый - который понимает и реализует все описания в том числе из этих файлов.
Взгляни на вывод ls ещё раз.
Особенно на размер.
И перестань тупить.
>> странные рассуждения чесслово. бтр хоть использует структуры и механизмы ядра.
> Да уж. А ZFSина таскает свой кэш, который кернель даже не может
> при душняке с памятью гарантированно потеснить. Это может и не проблема
> если машина целиком отдана под файлопомойку, но проблема во всех остальных
> случаях.Трындишь, косой. Ты концепции ZFS читал, не? Там сказано в буквальном переводе следующее: "ZFS спроектирована так, чтобы не красть память у приложений. И освобождать ее по первому требованию". Как там ее бздуны переделали - это их, буратин, злая проблема. Но на Солярисе память, занимаемая ARC, освобождается МГНОВЕННО, как только брокер памяти сделает вялый запрос. И, если бы ты Solaris Internals хотя бы читал, то знал бы, как вообще это работает.
Так что - трындеть не мешки ворочать.
>Ты концепции ZFS читал, не? Там сказано в буквальном переводе следующее: "ZFS спроектирована так, чтобы не красть память у приложений.а ты концепции на заборах читал?
зыж
это и дурагу должно быть понятно, что если в системе появляется дополнительный кэш (даже отдающий память по первому требованию), то это всё-равно нагрузка на систему.
потому как каждое такое требование всё-равно будет дёргать подсистему zfs на тему "верни сцуко память".
вот так и борются между собой кэш системы, кэш zfs, кэш субд и тд. (и каждый из тех, кто может заюзать всю свободную память, но вернуть!!! по первому требованию)
> следующее: "ZFS спроектирована так, чтобы не красть память у приложений. И
> освобождать ее по первому требованию".Маркетинговый буллшит - это вообще в духе санок. А вот у нас очередная жертва промывки мозгов. С единственным аргументом - мол, санье - это круто. Вся аргументация.
Технически же есть некоторая разница между случаем когда ФС по мере возможности попытается отдать память и случаем когда кернель явно отберет потребную память у буфера, слив при необходимости отбираемые страницы на диск.
В первом случае оно будет работать "как повезет" и программы вполне могут обломаться с выделением памяти. Во втором случае ядро таки выкроит память если это в приинципе возможно сделать в указанной конфигурации. Без каких либо "как повезет". Небольшая такая разница. Но да, сани не слишком любили распостраняться о таких мелочах. Впаривать мешает, знаете ли.
> Как там ее бздуны переделали - это их, буратин, злая проблема.
IIRC оно и у саней так же было. У бздунов вообще сроду "нет ресурсов" подобные вещи капитально перепахивать. Вы точно не завираете?
> освобождается МГНОВЕННО, как только брокер памяти сделает вялый запрос.
Или уж мгновенно, или уж вялый. Если программа делает выделение памяти и для его удовлетворения надо скостить дисковый буфер - как минимум в лине ядро разопрется, отберет страницы у кэша, а при необходимости и сольет оные на диск для этого (заваливание этой механики в ступор с большой очередью страниц на медленном носителе кстати было одной из причин легендарного 12309). Но запрос таки выполнит. Без всяких "если повезет". Солярис сможет столь же гарантировано откусить от дискового буфера, в том числе и из области которая еще не слита по факту на диск? Ответ на этот вопрос бинарный, без всяких юлений задом. Гарантированное откусывание страниц от буфера ядром или есть или нет.
> И, если бы ты Solaris Internals хотя бы читал, то знал бы, как вообще это работает.
Спасибо, но на данный момент линуксы зело перспективнее. И как там это работает - я более-менее в курсе уже. Тратить столько ресурсов на изучение полутрупа от 1 вендора - нафиг не упало.
> Технически же есть некоторая разница между случаем когда ФС по мере возможности
> попытается отдать память и случаем когда кернель явно отберет потребную память
> у буфера, слив при необходимости отбираемые страницы на диск.
> В первом случае оно будет работать "как повезет" и программы вполне могут
> обломаться с выделением памяти. Во втором случае ядро таки выкроит память
> если это в приинципе возможно сделать в указанной конфигурации. Без каких
> либо "как повезет". Небольшая такая разница. Но да, сани не слишком
> любили распостраняться о таких мелочах. Впаривать мешает, знаете ли.Ну и бред ... А куда повезет то ? Если свободна память есть то проблемы нет, если занят даже своп ... то причем тут ARC ?
>> освобождается МГНОВЕННО, как только брокер памяти сделает вялый запрос.Ога останется только всем у кого есть указатель на эту область памяти сообщить что ядро ее туже того ... тютю :)) Нука раскажите как лине указателями манипулируют ?
> Ну и бред ... А куда повезет то ?Действительно, чтобы нагуал и не бредил - такого не бывает.
> Если свободна память есть то проблемы нет, если занят даже своп ... то причем тут ARC ?
Своп тут вообще никаким боком - спич сугубо про возможность отобрать страницы памяти у кэша. Выжав его при необходимости на диск, если страницы содержали не слитую на диск информацию.
>>> освобождается МГНОВЕННО, как только брокер памяти сделает вялый запрос.
> Ога останется только всем у кого есть указатель на эту область памятиО, мсье кажется не только не в курсе основ posix, он еще и не в курсе того как работают ядра и что за фигня - страничная организация памяти. Но мнение уже имеет.
>> Если свободна память есть то проблемы нет, если занят даже своп ... то причем тут ARC ?
> Своп тут вообще никаким боком - спич сугубо про возможность отобрать страницы
> памяти у кэша. Выжав его при необходимости на диск, если страницы
> содержали не слитую на диск информацию.Зачем кэшировать, если часть кэша будет располагаться в свопе? Подумай, какой в этом смысл.
ARC на то и адаптивный, чтобы при любых обстоятельствах всегда оставаться в оперативной памяти, жертвуя, если надо, занимаемым объёмом.
> ARC на то и адаптивный, чтобы при любых обстоятельствах всегда оставаться в
> оперативной памяти, жертвуя, если надо, занимаемым объёмом.Похоже ваши оппоненты с таким трудом запомнившие слово ARC никак ниасилят слово ZIL :))
>> Ну и бред ... А куда повезет то ?
> Действительно, чтобы нагуал и не бредил - такого не бывает.Алекс ведите себя прилично, если у вас бывают бредовые состояния, это не значит что так бывает к всех.
>> Если свободна память есть то проблемы нет, если занят даже своп ... то причем тут ARC ?
> Своп тут вообще никаким боком - спич сугубо про возможность отобрать страницы
> памяти у кэша. Выжав его при необходимости на диск, если страницы
> содержали не слитую на диск информацию.Если есть свободная память то Нахер забирать у кеша ?
>> Ога останется только всем у кого есть указатель на эту область памяти
> О, мсье кажется не только не в курсе основ posix, он еще
> и не в курсе того как работают ядра и что за
> фигня - страничная организация памяти. Но мнение уже имеет.И с чего вы сделали такой вывод ? Со своих познаний в данной области ? Опять ставите диагноз без фотографии ? Ну так раскажите нам как вы понимаете работу ядра, чтобы не оказалась что месье писТабол.
ЗЫ Третий раз прошу прошу данного конкретного поциента, а в ответ тишина ...
>> да, ты же 294-ый это прекрасно знаешь, правда?
>Конечно. Я регулярно троллю тормозов которые эпикфэйлят. Кстати, пропустить запятые в
>попытке подъ...ки - довольно фэйлово.Друг мой, боюсь вы себе льстите, это вас тролят :))
>> странные рассуждения чесслово. бтр хоть использует структуры и механизмы ядра.
> Да уж. А ZFSина таскает свой кэш, который кернель даже не может
> при душняке с памятью гарантированно потеснить. Это может и не проблема
> если машина целиком отдана под файлопомойку, но проблема во всех остальных
> случаях.ZFS не использовал, а мнение имеешь?
т.е. ты документацию читать не умеешь?
и утверждаешь что у zfs нет своего кэша (по имени ARC)?зыж
>ZFS не использовал, а мнение имеешь?кто бы пиндел, о гуру по всем линухам.
> т.е. ты документацию читать не умеешь?
> и утверждаешь что у zfs нет своего кэша (по имени ARC)?По ссылке ходил? Что там, читал?
ага. в основном хрень всякую, в которой какой-то перец пыжится доказать, что 2 и более кэша, претендующих на всю свободную память в системе, лучше одного.
называется — коза из носа.
>> т.е. ты документацию читать не умеешь?
>> и утверждаешь что у zfs нет своего кэша (по имени ARC)?
> По ссылке ходил? Что там, читал?Нехочу вас огорчать но ваш опонент по ссылкам из принципа не ходит ...
> Нехочу вас огорчатьНе хочу вас огорчать, но если вы пишете как папуас и ведете себя как папуас, вы называетесь папуасом. Любой третьеклассник получает за диктант с такими ошибками в тексте не более двух баллов.
>> Нехочу вас огорчать
> Не хочу вас огорчать, но если вы пишете как папуас и ведете
> себя как папуас, вы называетесь папуасом. Любой третьеклассник получает за диктант
> с такими ошибками в тексте не более двух баллов.К сведенью попуасов которые не ходят по ссылкам Изэн не пишет под анонимусами :))
> сведенью
> попуасовПапуасы за клавиатурой - такие папуасы! :)
> которые не ходят по ссылкам Изэн не пишет
Я нихрена не понял. Тут знаков препинания не хватает.
> под анонимусами :))
Вам это не поможет. Зареганность ника совершенно не мешает эпикфэйлить.
> Я нихрена не понял.И не только в этот раз :))
>> под анонимусами :))
> Вам это не поможет. Зареганность ника совершенно не мешает эпикфэйлить.да, ты же 294-ый это прекрасно знаешь, правда?
> да, ты же 294-ый это прекрасно знаешь, правда?Конечно. Я регулярно троллю тормозов которые эпикфэйлят. Кстати, пропустить запятые в попытке подъ...ки - довольно фэйлово.
> По-моему Linux сейчас отходит от Unix-way, так что некритично,подумаешь, одним комбайном
> больше.Linux is NOT UNIX (C) Линус.
Плохо не знать заповеди своих апостолов, вьюнош.
Что-то соляре с ZFS это не мешало называться юниксом.
> Что-то соляре с ZFS это не мешало называться юниксом.ну для начала в соляре нет Линуса.
> ну для начала в соляре нет Линуса.Это не мешает им юзать такое монстрило но при этом считаться юниксом. Вывод: вышеупомянутые ораторы вопившие насчет юникс-вэя - звездоболы.
> Что-то соляре с ZFS это не мешало называться юниксом."Ты не поверишь...." - но Соляра это AT&T UNIX. Опачки? Покурил бы матчасть что-ли. Прежде, чем роток открывать свой.
> "Ты не поверишь...." - но Соляра это AT&T UNIX. Опачки? Покурил бы
> матчасть что-ли. Прежде, чем роток открывать свой.Так я как раз и намекаю что эта хренота называется юниксом невзирая на то что там ZFS немеряный вкорячен. В свете чего блеяние тех индивидов про юниксвэй выглядит достаточно забавно. Чего я не понял - так это чего вы тут взъелись. Походу солярщиков жизнь поимела, настолько качественно что они от попаболи готовы вцепляться в глотку первому встречному. Ну, таких как вы мне не жалко, скажем прямо.
Ну, RAID и обычные пользователи... Думаю, все поняли.А то, что вы описали - это Ext4, которая работает, почти не жрёт ресурсов и стабильна. А Btrfs - это комбайн, занимающий свою нишу и делающий это хорошо, так что - своего рода UNIX-вэй тоже. Он ведь не лезет никуда дальше того, что делает ФС (не то, что всякие там systemd), но на десктопе - нафиг не сдался.
Время, в принципе, покажет, но я не собираюсь в ближайшее время менять свою ФС и не думаю, что Btrfs займёт место ext4 в ядре.
Про btrfs и десктоп я с вами не соглашусь. На счет рейда, да, это на десктопе не особо нужно большинству пользователей.А вот те же снапшоты для возможности быстрого отката очень бы пригодились. Испоганил файл/грохнул папку с важными документами по своей криворукости? Откатись хоть на неделю назад и радуйся жизни.
А контрольные суммы файлов, чтобы быть уверенным, что файл не битый? Мне так очень бы было полезно. Встречался, к сожалению, со случаями, что древний многогигабайтный архив оказывается уже давно не архив, а куча мусора, занимающая место (и когда он помер за последние надцать переездов с машины на машину - я не в курсе). А так я хотя бы знал, что надежды на конкретный файл нет и, что его вообще давно стереть пора.
И совсем еще забыл сжатие данных на лету. Imho, тоже отличная фича, которая на десктопах вполне будет востребованна.
Не совсем понятно про снэпшоты - можно откатить один файл или только всю систему? Но, в общем, полезная функция, если только они не будут занимать места на диске (в смысле будут использовать свободное место, но отдавать, когда оно кому-то понадобится, как мейчас кэш в RAM).И про контрольные суммы - что вам мешает сейчас сделать md5sum <файл>? Объясните, пожалуйста, более подробно, что же нового приносит сюда Btrfs.
А про сжатие - нафига оно на терабайтовых дисках? Только процессор грузить и восстановление усложнять. Хотя я не сторонник держать на диске столько всего, что может забить терабайтник, не знаю, но вроде бы оно должно копирование замедлять? Расскажите как оно по производительности, если использовали.
Как это ни странно но очень многие операции сжатие как раз ускоряет, посмотрите тесты
> Не совсем понятно про снэпшоты - можно откатить один файл или только
> всю систему? Но, в общем, полезная функция, если только они не
> будут занимать места на диске (в смысле будут использовать свободное место,
> но отдавать, когда оно кому-то понадобится, как мейчас кэш в RAM).
> И про контрольные суммы - что вам мешает сейчас сделать md5sum <файл>?
> Объясните, пожалуйста, более подробно, что же нового приносит сюда Btrfs.
> А про сжатие - нафига оно на терабайтовых дисках? Только процессор грузить
> и восстановление усложнять. Хотя я не сторонник держать на диске столько
> всего, что может забить терабайтник, не знаю, но вроде бы оно
> должно копирование замедлять? Расскажите как оно по производительности, если использовали.go самообразованием заниматься.
Со снапшотами, честно говоря, вживую не разбирался. Места, судя по всему, занимают немного (аналог инкрементального бэкапа). Восстанавливать, по идее, можно как весь снапшот целиком, так и отдельный файл - монтируем снапшот отдельным томом и сливаем с него все нужные нам файлы, отмонтируем снапшот. В идеале, для случая с домашним юзером, сию последовательность действий надо автоматизировать.С контрольными суммами мешает лень и забывчивость :) Их надо вручную делать после каждого изменения файла и сверять периодически тоже вручную.
В случае же btrfs`а все файлы имеют свою CRC (точнее каждый кластер файла), которая автоматически пересчитывается при любых с ними операциях. Плюс scrub, который запускается по крону и чекает структуру диска (в том числе и CRC файлов). В случае чего, файлы либо автоматически исправляются (если у нас рейд и есть резервные исправные копии), либо, как минимум, я получаю сообщение, что файл такой-то в таком-то каталоге накрылся медным тазом (ищите бэкап). Бонус в том, что не надо разворачивать весь бэкап на надцать терабайт, достаточно вытащить из него отдельный файл, что, чаще всего, гораздо быстрее.
Да, от злоумышленника или программного бага сие не спасет (тут md5sum по-прежнему рулит), а от сбоя в оперативке/рваном шлейфе/сбойном диске очень даже поможет.Сжатие... Зависит от того, что вам дороже - загрузка проца или загрузка винта? Иногда дешевле и быстрее прочитать 1 сектор с (относительно) медленного винта и распаковать его в 100 секторов в оперативке, чем "честно" читать всю эту сотню секторов с винта.
Кстати, btrfs поддерживает несколько достаточно быстрых алгоритмов сжатия, которые и сжимают неплохо и кушают проц умеренно. С учетом того, что ядер в процах много, то откусить процентов 10-20 от одного из них, в большинстве случаев, вполне допустимо.
А если еще вспомнить, что сжатие, при желании, отключаемо чуть ли не на уровне каждого конкретного файла, то пусть уж лучше эта фича будет...
Убедили, неплох Btrfs для десктопа. Может посмотрю когда-нибудь, когда стабилизируется.Но до статуса основной ей всё же далеко, т.к. там чаще важнее простота и стабильность, чем все эти вкусности.
Скажи, ты прозревший User294?
В zfs всё ещё нельзя загрузиться с любого снэпшота?
> В zfs всё ещё нельзя загрузиться с любого снэпшота?В оригинальном ZFS это реализовано с 2008 года. В релизе 10/08. AFAIK.
пруфик можно?зыж
или своими словами. если не много.
например в бтр снэпшот — это всё тот же добрый субволум. и делать с ним можно всё тоже, что и субволумом. например перегрузиться в снэпшот рута можно командой
# btrfs subvolume set-default <id_снэпшота>
# reboot
усё.
> пруфик можно?
> зыж
> или своими словами. если не много.
> например в бтр снэпшот — это всё тот же добрый субволум. и
> делать с ним можно всё тоже, что и субволумом. например перегрузиться
> в снэпшот рута можно командой
> # btrfs subvolume set-default <id_снэпшота>
> # reboot
> усё.С какого перепугу тебе кто-то обязан пруфы предоставлять? Тебе сказано русским языком - в релизе Солярис 10/08. Иди, релиз ноты кури.
Нлрмального человека культурно попросили.
Брехуны конечно ни чем никому не обязаны
Свободен.
что ж, для брехунов могу предоставить и сам.
НЕЛЬЗЯ загрузиться и работать с снепшота в zfs.
Только восстановление из снепшота в failsafe режиме поддерживается.
http://docs.oracle.com/cd/E19082-01/817-2271/ghzvz/index.html
> В zfs всё ещё нельзя загрузиться с любого снэпшота?# zfs rollback systempool@fixpoint
# zfs rollback systempool/usr@fixpoint
# reboot
Всегда так делаю, если после обновления системы что-то работает не так.
Зыж
И ещё. Все эти субволумы можно запускать в черуте, контейнерах и виртуалках.
> Скажи, ты прозревший User294?Нет, данный индивид не имеет никакого отношения ко мне. Но да, я думаю что ты устанешь тявкать в всех этих новостях. Половину из них кстати написал я :).
User294, почему ты пишешь от лица Анонима, если тебя так легко вычислить по написанному?
> Скажи, ты прозревший User294?Это к кому вопрос? Если ко мне, то, во-первых, я не User294, во-вторых, я даже не знаю - кто это или что это :)
>Не совсем понятно про снэпшоты - можно откатить один файл или только всю систему?вы монтируете снэпшит, как отдельную фс. например:
$ ls /media/btrfs/@snapshots/root_25.01.13/
boot etc lib lib64 mnt …
я ответил на вопрос?
можете с этой фс загрузится и работать как ни в чём не бывало дальше, а можете смонтировать в любую точку монтирования и вытащить оттуда нужный вам файл.
>А про сжатие - нафига оно на терабайтовых дисках?увеличивается и скорость, и свободное место.
правда также увеличивается нагрузка на цпу, но я это на своём i7 вообще никак не могу обнаружить.
>Расскажите как оно по производительности, если использовали.хм, xfce чуть медленнее загружается. вот это всё что я заметил. :D
> но отдавать, когда оно кому-то понадобится, как мейчас кэш в RAM).Оно и так и сяк умеет: есть автоснапшоты которые подтираются на автомате. Они временные. Или можно постоянный снапшот сделать, который подтираться не будет.
> И про контрольные суммы - что вам мешает сейчас сделать md5sum <файл>?
И потом мониторить обновление файла и опять запускать оный? Больно геморно.
> Объясните, пожалуйста, более подробно, что же нового приносит сюда Btrfs.
Удобство эксплуатации в основном. В принципе все что он делает при помощи костылей и подпорок можно и как-то иначе делать. Просто это намного мучительнее в плане администрежки получистя и работать будет хуже.
> А про сжатие - нафига оно на терабайтовых дисках?
Ну, если вместо терабайта влезет два - это же хорошо :).
> Только процессор грузить
Как ни странно, узкое место при записи/чтени - производительность диска, а вовсе не проца. По этому поводу запись и чтение при использовании сжатия может даже ускориться. И ускоряется. LZO довольно быстрый и не требовательный, он может сжимать до нескольких сотен мегов в секунду а распаковывать и еще быстрее даже.
> и восстановление усложнять.
А вот это в принципе может быть проблемой.
С другой стороны - грохнул ты на обычном ФС диру рекурсивно. Схватился за бошку - вай, не ту диру снес! В лучшем случае из бэкапа достанешь. В хучшем - получишь звание Генерала Фэйлора (того, который читает диск). А на btrfs просто отмотал на ближайший автоснапшот и порядок.
Опция монтирования autodefrag, тоже интересная фича.
И с каких пор ФС новее FATа подвержены фрагментации? :-)
любая фс, ради скорости записи/создания, фрагментируется. Не будет же она тебе во время записи делать дефрагментацию чтобы уместить твой очередной porno.avi в 3 гига.
Однако у Ext4 фрагментация стол незначительна, что незаметна. Есть ли смысл огород городить?
> Однако у Ext4 фрагментация стол незначительна, что незаметна. Есть ли смысл огород
> городить?Она незначительна, потому что этот самый автодефрагментатор всегда работает, что накладывает отпечаток и на скорость работы.
Нет там ничего такого, такое только планируется. Могу и ошибаться, но проблемы фрагметации там нет из-за грамотной реализации ФС. Есть только некий e4defrag, который не является автоматическим.
-m reserved-blocks-percentage
Specify the percentage of the filesystem blocks reserved for the super-user. This
avoids fragmentation, and allows root-owned daemons, such as syslogd(8), to continue
to function correctly after non-privileged processes are prevented from writing to the
filesystem. The default percentage is 5%.
это вообще из другой оперы и НИКАКОГО отношения к фрагментации/дефрагментации не имеет.
Вы хоть понимаете как лажанулись?
существует для того, чтобы когда вся файловая система заполнится и в систему никто не сможет войти (т.к. вход сопровождается созданием файлов, временных файлов, записями в журнал), то оставалось возможность восстановить работоспособность.
поэтому система оставляет этот процент свободных блоков, чтобы админ(root) смог войти и навести порядок.зыж
конечно 5% по-умолчанию для современных размеров винтоа это много.
обычно ставлю 1% (см. man tune2fs) на extX для фс больших, чем 100Gb.
ззыж
и да, фраза
>This avoids fragmentationпобочный эффект, говорит лишь о том, что при распределении непрерывных блоков для записи файлов (есессно тех что >1блока размером) учитывает и эти, свободные блоки.
другими словами, в эти 5% не входят конкретные блоки, учитывается только общее их количество.
что конечно позволяет избегать фрагментацию ещё до записи за счёт дизайна фс.
но всё-равно фс не даст записать (для не привилегированного пользователя) в случае когда места в осталось меньше этого значения.
> это вообще из другой оперы и НИКАКОГО отношения к фрагментации/дефрагментации не имеет.
> Вы хоть понимаете как лажанулись?
> существует для того, чтобы когда вся файловая система заполнится и в систему
> никто не сможет войти (т.к. вход сопровождается созданием файлов, временных файлов,
> записями в журнал), то оставалось возможность восстановить работоспособность.
> поэтому система оставляет этот процент свободных блоков, чтобы админ(root) смог войти и
> навести порядок.нет желания флеймить, но в баше меня вот эта падучесть удивляла, во фре с ее tcsh такого абсурда не наблюдается...
> нет желания флеймить, но в баше меня вот эта падучесть удивляла, во фре с ее tcsh такого абсурда не наблюдается...Угу. Значит вам горячий паяльник вставили (ведь у меня и в мыслях не было оскорбить вас недоверием)
> нет желания флеймить, но в баше меня вот эта падучесть удивляла, во
> фре с ее tcsh такого абсурда не наблюдается...Если у вас нет штанов - логично что и порвать их вы не сможете. Просто неудобно оно как-то - светить голым задом на морозе.
>> нет желания флеймить, но в баше меня вот эта падучесть удивляла, во
>> фре с ее tcsh такого абсурда не наблюдается...
> Если у вас нет штанов - логично что и порвать их вы
> не сможете. Просто неудобно оно как-то - светить голым задом на
> морозе.это наброс в сторону tcsh? мелкий, не жирущий, не падучий, просто и стабильно работает и функционала для работы с ком. строкой хватает. наброс в отброс.
> это вообще из другой оперы и НИКАКОГО отношения к фрагментации/дефрагментации не имеет.
> Вы хоть понимаете как лажанулись?
> существует для того, чтобы когда вся файловая система заполнится и в систему
> никто не сможет войти (т.к. вход сопровождается созданием файлов, временных файлов,
> записями в журнал), то оставалось возможность восстановить работоспособность.
> поэтому система оставляет этот процент свободных блоков, чтобы админ(root) смог войти и
> навести порядок.Вот и выросло поколение (с)
Оно именно из-за алгоритмов размещения вводилось - при почти полной заполненности тома скорость резко падает. Фрагментация - вторая цель. А уж вход рута - это сугубо побочный эффект, который в мозгах масс почему-то стал единственным (а подумать даже, зачем бы для этой цели резервировать в процентах, а не мегабайтах, не догадываются).
> filesystem. The default percentage is 5%.Это до некоторой степени помогает, но - только до некоторой.
> который не является автоматическим."В деревне построили вышку сотовой связи. Через месяц население подало жалобу, что, дескать, головные боли, ухудшение самочувствия, бла-бла-бла. Ответ от директора был простым:
Это все ерунда. Вы только подумайте, что будет, когда мы ее включим. :-)"
> любая фс, ради скорости записи/создания, фрагментируется. Не будет же она тебе во
> время записи делать дефрагментацию чтобы уместить твой очередной porno.avi в 3
> гига.У extent-based FS фрагментация отсутствует по определению. Go курить маны.
> У extent-based FS фрагментация отсутствует по определению.Ага, щаз. А если для размещения экстента нужного размера не оказалось непрерывного региона свободного места - как вы дуамете, что произойдет? Правильно - он будет разбит на части меньшего размера. Аналогично, если надо дописать в хвост файла, а там что-то еще уже записано - фрагмент таки получится.
> Go курить маны.
При том - вы. А также учиться пользоваться головным мозгом.
>> У extent-based FS фрагментация отсутствует по определению.
> Ага, щаз. А если для размещения экстента нужного размера не оказалось непрерывного
> региона свободного места - как вы дуамете, что произойдет? Правильно -
> он будет разбит на части меньшего размера. Аналогично, если надо дописать
> в хвост файла, а там что-то еще уже записано - фрагмент
> таки получится.Ты исходники ZFS-то посмотри. Прежде, чем тявкать. Как там и что реализовано.
>> Go курить маны.
> При том - вы. А также учиться пользоваться головным мозгом.Пшел вон, щенок.
> Ты исходники ZFS-то посмотри. Прежде, чем тявкать. Как там и что реализовано.А у нашего изена его легендарные 6мб/сек на шпиндель на хваленом ZFS-е получается наверное путем черной магии и приворотов, а вовсе не потому что фрагментация взлетела до небес и диски вместо того чтобы данные читать головы гоняют основную часть времени :).
Но если уж вы хотите поговорить о сорцах - ок, file:line, желательно с цитированием того волшебного места которое делает это (физически и логически невозможное с разумными затратами ресурсов xD) действие.
> Пшел вон, щенок.Таки поясняю: матерый волк отличается от щенка одним простым моментом: я вот например могу представить как будет выглядить обработка позиксного запроса на энную файловую операцию, вплоть до перемещений голов накопителя в результате. Хотя-бы прикидочно. А вот непытные щенки с большим гонором умеют только громко тявкать на форуме. Короче, ваши понты не соответствуют фактической квалификации.
>> любая фс, ради скорости записи/создания, фрагментируется. Не будет же она тебе во
>> время записи делать дефрагментацию чтобы уместить твой очередной porno.avi в 3
>> гига.
> У extent-based FS фрагментация отсутствует по определению. Go курить маны.Да ну ? :)) Неужто ? :)) а зачем же тогда дефрагментатор писали ? :))
> Да ну ? :)) Неужто ? :)) а зачем же тогда дефрагментатор писали ? :))Во, даже нагуал догадывается что тут что-то не так.
>И с каких пор ФС новее FATа подвержены фрагментации? :-)а вот и результат промывки мозгов, жертва рекламных проспектов.
<цитата>… В самом начале утверждалось, что NTFS не подвержена фрагментации файлов. Это оказалось не совсем так, и утверждение сменили - NTFS препятствует фрагментации. Оказалось, что и это не совсем так. То есть она, конечно, препятствует, но толк от этого близок к нулю. Сейчас уже понятно, что NTFS - система, которая как никакая другая предрасположена к фрагментации, что бы ни утверждалось официально. … </цитата>
>>И с каких пор ФС новее FATа подвержены фрагментации? :-)
> а вот и результат промывки мозгов, жертва рекламных проспектов.
> <цитата>… В самом начале утверждалось, что NTFS не подвержена фрагментации файлов.
> Это оказалось не совсем так, и утверждение сменили - NTFS препятствует
> фрагментации. Оказалось, что и это не совсем так. То есть она,
> конечно, препятствует, но толк от этого близок к нулю. Сейчас уже
> понятно, что NTFS - система, которая как никакая другая предрасположена к
> фрагментации, что бы ни утверждалось официально. … </цитата>Какая NTFS? Вы где находитесь? В приличном обществе такие слова не употребляют! ExtFs разных версий же, о них речь :-)
> ExtFs разных версий же, о них речь :-)Чудес не бывает - они тоже могут фрагментироваться. Для ext4 даже дефрагер есть.
> И с каких пор ФС новее FATа подвержены фрагментации? :-)С таких как на накопителе может не оказаться непрерывного блока достаточного для выполнения запрошенной операции, например. Т.е. так было всегда. А CoW фрашментируется просто по определению - недеструктивная запись подразумевает что изменения не перезапишут оригинал а будут вынесены в сторонку. Так что на диске будет одновременно и старая и новая версия файла. Ясен фиг, выносок с отличиями новой версии формирует фрагмент.
>сжатие данных на лету. Imho, тоже отличная фича, которая на десктопах вполне будет востребованнаИ упаковка хвостов файлов тоже будет востребована.
хвосты еще reiserfs паковать умела...
Запустить систему можно успешно и с ext2, так что ext4 так же и останется в качестве запускалки, а вот хранение данных я бы доверил btrfs
> Ну, может это и не разу не юникс-вейДа это даже не вопрос идеологии. Почему-то [почти] никто из пользователей Solaris или FreeBSD не заикается, что ZFS это не Unix way :) Вопрос в надёжности и качестве выполнения задач, которые сваливают на одну ФС. Во-первых, от усложнения системы надёжность неизбежно снижается и порождаются новые точки отказа, которых не может быть в комбинации более простых систем (LVM, MD, DM в общем виде). При равной функциональности комбинация этих подсистем всегда будет выигрывать в надёжности у комбайна вроде Btrfs, поскольку оные подсистемы взаимодействуют через простой интерфейс в виде блочного устройства и прекрасно абстрагированы от внутренних особенностей друг друга. Это, конечно, моё сугубо личное мнение :)
>Во-первых, от усложнения системы надёжность неизбежно снижается и порождаются новые
> точки отказа, которых не может быть в комбинации более простых систем
> (LVM, MD, DM в общем виде). При равной функциональности комбинация этих
> подсистем всегда будет выигрывать в надёжности у комбайна вроде Btrfs, поскольку
> оные подсистемы взаимодействуют через простой интерфейс в виде блочного устройства и
> прекрасно абстрагированы от внутренних особенностей друг друга. Это, конечно, моё сугубо
> личное мнение :)К сожалению, у медали две стороны. Комбинация простых технологий почти наверняка проиграет в скорости и ресурсожручести за счет лишних уровней абстракции, которые выпилены в комбайне. Про надежность молчу, ибо в плюсе комбинации простых систем - изоляция частей (и их ошибок) друг от друга, в минусе - это лишний код, который тоже может быть небезупречен. В общем, считать надо.
Да и управление разнородным комплексом технологий всегда сложнее и больше подвержено человеческим ошибкам. Согласитесь, добавка нового диска в btrfs`ный пул несколько проще и быстрее, чем в случае mdraid+LVM+ext4.
это не комбайн, это БТР
+1
> это не комбайн, это БТРЭто не БТР, это "шоб тоже було, а чо."
А где здесь комбайн?
Эта ФС всего лишь предоставляет интерфейс для работы с файлами и в будущем будет делать это хорошо.
> У меня язык не поворачивается назвать этот комбайн ФС.Нужно посмотреть на реализацию. Если в ядре можно будет отключать ненужное, то вполне unix-way . Вот даже в ext* и resierfs можно отключать acl - вполне себе unix-way.
Кстати о reiserfs №4 и btrfs, сразу вспоминается интервью полуторагодовой давности с Шишкиным на хабре о том как рейзерфс не пущають в ядро с какой-то мутной мотивацией, зато бтр этот не смотря на конструктивные недостатки вполне сразу велкам. Двойные стандарты аднака.
> ядро с какой-то мутной мотивацией,Мутная мотивация - это у Шишкина. Сделать какой-то том на 600Мб (когда он HDD такого объема в последний раз видел?) и завалить его метаданными - круто. Но не слишком реалистично. Впрочем, пару починок багов спровоцировало, так что тоже хлеб.
Зато за собой бревна в глазу: навороченный и полусобранный экспонат пихать в майнлайн без понимания того кто все это будет майнтайнить - интересная идея. В случае с btrfs вопрос кто его майнтайнить будет как-то не возникал.
Ну и сколько времени мэйнтейнят? Толку от этого долгостороя, что он в дереве ядра, если он не работает до сих пор?
> Ну и сколько времени мэйнтейнят? Толку от этого долгостороя, что он в
> дереве ядра, если он не работает до сих пор?Что значит - не работает? Вы ядро линукса только на картинке видели? Да, там может и не работает. А так - пул слепить можно. Работать будет. А то что функционал расширяют, баги давят и прочая - так это нормальный рабочий процесс.
Это значит что целей не достиг. Медленный он на fsync, даже с самыми наисвежайшими костылями подпорками в ядре. Также жутко фрагментирует когда диск заполнен больше чем на 2/3. А свежеразмеченный раздел с 10% заполнения никому не интересен, любая файловая система хоть fat хотьчто еще летает на таком.
> Это значит что целей не достиг. Медленный он на fsync, даже с
> самыми наисвежайшими костылями подпорками в ядре.А таки свежайшими костылями неплохо подтянули этот момент. Там где fsync-ов много, оно втопило буквально в разы.
> Также жутко фрагментирует когда диск заполнен больше чем на 2/3.
Ну так и дефрагер у него есть. Но вообще, эксплуатировать CoW на сильно забитом томе - довольно дурная идея, да. Я бы оценил допустимое занятие тома в 70-80%. Больше уже нехорошо. Вон у местного изена zfs вообще смешные цифры выдает :).
> никому не интересен, любая файловая система хоть fat хотьчто еще летает на таком.
У фата на самом деле проблемы совсем иные:
- Лимит на число кластеров. И емкость тома как результат. Ну то-есть, на большой том или не хватит битности для адресации кластера или кластера надо огромного размера, что неэффективно.
- Нет никакого индекса для работы с большими иерархиями. Там все оформлено простыми списками. Поэтому как только в директории более тысченки-другой файлов, FAT начинает немилосердно тормозить на любых операциях которые требуют что-то делать с файловой иерархией.
- Лимит на размер файла.Именно в аллокации места фат тормозить в общем то и не обязан. А если мы про засраные фрагментацией тома - зафрагментировать можно все. Я даже XFS разок уложил. Хоть это и не очень просто.
>> Также жутко фрагментирует когда диск заполнен больше чем на 2/3.
> Ну так и дефрагер у него есть. Но вообще, эксплуатировать CoW на
> сильно забитом томе - довольно дурная идея, да. Я бы оценил
> допустимое занятие тома в 70-80%. Больше уже нехорошо. Вон у местного
> изена zfs вообще смешные цифры выдает :).с дедупликацией, да — смешные 6МБ/с. Без дедупликации честные 25-35МБ/с с одного шпинделя 5400rpm. А вам так слабо?
у меня с дедупликацей дает 50МБ/с на SAS 15.000rpm
Intel Xeon® E7-4870
>>> Также жутко фрагментирует когда диск заполнен больше чем на 2/3.
>> Ну так и дефрагер у него есть. Но вообще, эксплуатировать CoW на
>> сильно забитом томе - довольно дурная идея, да. Я бы оценил
>> допустимое занятие тома в 70-80%. Больше уже нехорошо. Вон у местного
>> изена zfs вообще смешные цифры выдает :).
> с дедупликацией, да — смешные 6МБ/с. Без дедупликации честные 25-35МБ/с с одного
> шпинделя 5400rpm. А вам так слабо?Нафига включать дедуплекацию если проц не фонтан ? На 2600К up 4Ггц на асусной матери с 4-мя каналами памяти бодречком работает ;)
>>>> Также жутко фрагментирует когда диск заполнен больше чем на 2/3.
>>> Ну так и дефрагер у него есть. Но вообще, эксплуатировать CoW на
>>> сильно забитом томе - довольно дурная идея, да. Я бы оценил
>>> допустимое занятие тома в 70-80%. Больше уже нехорошо. Вон у местного
>>> изена zfs вообще смешные цифры выдает :).
>> с дедупликацией, да — смешные 6МБ/с. Без дедупликации честные 25-35МБ/с с одного
>> шпинделя 5400rpm. А вам так слабо?
> Нафига включать дедуплекацию если проц не фонтан ? На 2600К up 4Ггц
> на асусной матери с 4-мя каналами памяти бодречком работает ;)Это был всего лишь тест.
> Это был всего лишь тест.Не кормите местную публику подобными тестами, они вас очень превратно понимают, у одного поциента дошло до навязчивых идей ... :)))
Да, по кормлению публики вы специалист :). Сначала вы закатили сферические тесты в вакууме на каком-то рамдиске, потом спалились на незнании семантики доступа к файлам POSIX. Покормили вы здесь всех весьма хорошо в результате - местные тролли от истощения теперь точно не умрут xD.
> А вам так слабо?А у меня ext4, на не сильно то и крутом MIPS с частотой менее гигагерца, через usb-to-sata адаптер и то быстрее работает с этим самым, ноутбучным, 5400. Вот такое вот эпичное опускалово, да? :)
> Сделать какой-то том на 600Мб (когдаА нужно было сколько? 600Гб? Кто будет время тратить? Не суть важен объем, сколько дефект дизигна, который имеет место. И это не единственный конструктивный недочет, который он в том интервью озвучивал.
> Зато за собой бревна в глазу: навороченный и полусобранный экспонат пихать в
> майнлайн без понимания того кто все это будет майнтайнить - интересная
> идея. В случае с btrfs вопрос кто его майнтайнить будет как-то
> не возникал.Вот он бы и "майнтайнил". Круто заниматься хобби при этом получать за это денег. А там и другие девелоперы подтянутся, процесс бы пошел.
> А нужно было сколько? 600Гб? Кто будет время тратить?А нужно было нормальный типовой размер накопителя. Да, 600Гб уже ближе к делу. Ну или где я по вашему буду использовать дисковую ФС на 600Мб томе?
> Не суть важен объем, сколько дефект дизигна,
У любой ФС можно обнаружить полный ахтунг, если стартовые условия правильно подогнать. Я вот как-то XFS в жуткие тормоза загнал. Это не значит что XFS - тормозной и неудачный дизайн. Просто любой ФС можно подогнать нагрузку которая для него неудачной окажется. У любой ФС есть сильные и слабые стороны. Целенаправленное тюкание по слабым сторонам позволит выставить ФС в отстойном свете. С этой точки зрения вообще ВСЕ существующие ФС - "отстой", подобрать неудачные нагрузки можно для любой. Но намного лучше смотреть какие-то осмысленные сценарии. Встречающиеся в реальном мире.
> который имеет место.
Несмотря на полную синтетичность этого теста, разработчики таки учли часть претензий и заметно убавили объем метаданных в указанной шишкином ситуации. Пусть она синтетичная, но все-таки хорошая ФС не должна тушеваться и в сложных ситуациях. И объем метаданных в таком случае там сильно скостили.
> И это не единственный конструктивный недочет, который он в том интервью озвучивал.
Ну так и ряд багов пофиксили с тех пор. А вообще оценивать дизайны ФС по каким-то вырванным краевым случаям - удел академиков. Нормальных же людей интересует чтобы оно нормально работало на практике в более-менее типовых сценариях и имело рукоятки для не слишком типовых.
> Вот он бы и "майнтайнил".
Это при том что он упоминал что он работает над ФС "как получится" и "когда будет время", заметно отставая от майнлайна? Простите, а зачем в ядре кусок poorly maintained кода? Оно или заклинит выпуск ядра на эн месяцев пока Шишкин найдет время доработать свою ФС под новое ядро, или перцы выкатят не стыкующийся друг с другом тянитолкай, где рейзер 4 не работает или работает криво. Оно кому-то надо?
> Круто заниматься хобби при этом получать за это денег.
А Шишкину кто-то готов дать денег за его хобби? Он вроде как упоминал что занимается ФС в свободное от работы время и потому оно и слоупочно. А, как бы, что оно такого уникального может предложить клиентам? Вякание про красивые дизайны академики могут оставить себе, перцев с бабками все это не пронимает. Им чтобы работало и бабло приносило.
> А там и другие девелоперы подтянутся, процесс бы пошел.
Или не пошел бы. Никто не хочет решать чужие проблемы за свой счет. Если оно такое хорошее и нужное - пусть перец найдет себе финансирование, сколотит хоть какую-то командочку, способную майнтайнить это в тех же темпах что и основное ядро - тогда к нему наверное и отношение иное будет. А когда некто пытается решать свои проблемы за счет других - это не очень хорошо работает.
> А Шишкину кто-то готов дать денег за его хобби? Он вроде как
> упоминал что занимается ФС в свободное от работы время и потомуА иди почитай где работает и чем занимается.
> Кстати о reiserfs №4 и btrfs, сразу вспоминается интервью полуторагодовой давности с Шишкиным на хабре о том как рейзерфс не пущають в ядро с какой-то мутной мотивацией, зато бтр этот не смотря на конструктивные недостатки вполне сразу велкам.ЕМНИП там говорилось о том, что код не прошел "тест на качество", потому и не приняли.
Любой опытный программер знает, что мало заставить код работать, нужно чтобы он был написан грамотно, начиная с банального форматирования, именования переменных и комментариев, заканчивая корректным взаимодействием с остальной системой. Иначе потом это код практически невозможно поддерживать, особенно в таком проекте как ядро Линукс. Не знаю какие требования конкретно у мейнтейнеров ядра (сомневаюсь чтобы они устанавливали правила для именования переменных), но в любом случае - мало сделать чтобы код работал - он должен быть качественным.
OK.
Не насилуй себя, оно не стоит того.Не называй.
типа, ответ чемберленам (zfs)
> типа, ответ чемберленам (zfs)пока еще не ответ. до пром. применения пару лет впереди и система загружаться с нее научилась?
Конечно!
Граб2 к примеру держит её отлично, включая и сжатие lzo.
А что до пром-применения, ну дак это не мешает моему ноуту, где бтр уже больше 2-х лет и приехала с предыдущего ноута.
И сабж, как вы понимаете, мне не особо тут и нужен.
> Конечно!
> Граб2 к примеру держит её отлично, включая и сжатие lzo.
> А что до пром-применения, ну дак это не мешает моему ноуту, где
> бтр уже больше 2-х лет и приехала с предыдущего ноута.
> И сабж, как вы понимаете, мне не особо тут и нужен.Промышленное применение - не всегда гарантия качества, взять ту же Java.
Примеры Ваших качественных промышленных применений, пожалуйста.
> Примеры Ваших качественных промышленных применений, пожалуйста.Solaris ZFS.
> Solaris ZFS.Спасибо, конечно, но закладываться на оракла - хуже чем уповать на то что лев в клетке - сытый.
ZFS сейчас пилит не Oracle. Т.е. они тоже пилят, но им ничего не сотается как опилками этими разве что подтереться, а нормальный ZFS пилит illumos.
>> Solaris ZFS.
> Спасибо, конечно, но закладываться на оракла - хуже чем уповать на то
> что лев в клетке - сытый.напомните мне, кто пилит бтр?
> напомните мне, кто пилит бтр?Архитектом и центром интеграции патчей выступает Крис Мэйсон. В данный момент он сотрудник компании FusionIO. Думаю что вы под "пилит" подразумевали именно это :).
А так там целая толпа народа пилит, совершенно разные люди. Да, до кучи есть и парочка перцев из оракла, если вы об этом. Например, Miao Xie (если не соврал). Вполне прилично фигурирует в ченжлогах, кстати. Баги давит хорошо. Но в данный момент оракл - всего лишь один из. А не "the one and the only". У них в данный момент совершенно нет никаких средств для полного контроля этого процесса. Теперь это вполне самостоятельная и независимыя штука над которой совместно работает куча народа. Как оно и должно быть в открытом проекте. Надеюсь, я ответил на вопрос кто и что пилит.
> Конечно!
> Граб2 к примеру держит её отлично, включая и сжатие lzo.
> А что до пром-применения, ну дак это не мешает моему ноуту, где
> бтр уже больше 2-х лет и приехала с предыдущего ноута.
> И сабж, как вы понимаете, мне не особо тут и нужен.я это все о применении к райд5/6 в бтр-е говорил.
>до пром. применения пару лет впередиПару лет назад слышал тоже самое. ИМХО, оценка весьма неточна. Думаю, 15-20 лет до промышленного применения будет наиболее адекватным прогнозом.
ЗЫ Приятно все же видеть, что стремительный выход Linux из сектора enterprise NAS хоть немножко, но замедлился.
Enterprice NAS предполагают BSD-like лицензии, и только. Так как понятия Enterprice и GPL - несовместимы в принципе. Это вопрос не качества используемого програмного продукта, а желания не публиковать исходники и не возвращать изменения в mainstream.
Имхо, иногда имеет смысл заменять русские слова английскими, но только если научиться их писать, как минимум.
Вход цены же,так даже логичнее звучит
http://www.h-online.com/open/news/item/Btrfs-ready-for-produ...
https://www.linux.com/news/enterprise/systems-management/677...
Конечно же, мы им верим. А тот, кто рассказывает о случаях сыпучести btrfs, - тот просто злостный клеветник.
> btrfs, - тот просто злостный клеветник.Ну вон ZFSников на бзде что-то локапы в кернеле не смущают :). А всякие там соплярисы на столь конских условиях как предлагает ракль - вы уж как-нибудь сами юзайте.
>> btrfs, - тот просто злостный клеветник.
> Ну вон ZFSников на бзде что-то локапы в кернеле не смущают :).
> А всякие там соплярисы на столь конских условиях как предлагает ракль
> - вы уж как-нибудь сами юзайте.Совершенно бесплатно скачать и пользоваться в некоммерческих целях. http://downloads.oracle.com
Трындеть не надо раньше, чем не посмотришь. Хотя постой - ты, может, по английски не сечешь и на портал Оракла отродясь не ходил, но мнение имеешь?
> Совершенно бесплатно скачать и пользоваться в некоммерческих целях.В некоммерческих целях - это в песочнице в куличики чтоли поиграть? Спасибо, парни из оракла такие добрые, конечно. Но вы знаете, на фоне таких конских ограничений даже AGPL и GPLv3 - это очень мягкие лицензии, которые налагают существенно меньше ограничений. Как то - совершенно не запрещают коммерческое применение.
Не-не, спасибо, я как-нибудь пешком постою. А то вдруг заработаю еще копеечку - окажусь нарушителем лицензий. А оно мне надо - с юридической службой оракла бодаться? У них ресурсов - во! А у меня - во. Так что оракл идет курить бамбук.
> Трындеть не надо раньше, чем не посмотришь.На таких условиях я это даже качать не буду - это заведомо не укладывается в допустимые для меня сценарии.
> Хотя постой - ты, может, по английски не сечешь и на портал Оракла отродясь не ходил,
> но мнение имеешь?У меня в системе интерфейс целиком на английском, т.к. не жалую кривые переводы ;). И английский я секу достаточно для того чтобы понимать что такие условия лицензирования - bullshit. Go to hell, Oracle.
> Как ты предлагаешь убедить своего боссаЗа нарушение лицензии обычно отвечает тот кто ее нарушил. Т.е. недалекий кульсисоп. Вот пусть кому надо - тот и подставляется лишний раз. Боссу то чего, скажет что он в этом не компетентен и с него взятки гладки. Вопросы к юристам (которые такое на корню зарубят, если они есть и не даром жрут свой хлеб) и исполнителю (с которого обычно и снимают по факту стружку).
Вот только почему-то в новостях хватает сообщений о том что админу пришили условняк. А вот случаи когда награда перепала боссам - исчезающе редки.
>> Как ты предлагаешь убедить своего босса
> За нарушение лицензии обычно отвечает тот кто ее нарушил.Нарушила - фирма босса. Она и ответит.
> Т.е. недалекий кульсисоп.
Кому ты нужен?
> Боссу то чего, скажет что он в этом не компетентен и с
> него взятки гладки.Ему расскажут что к чему. Для начала, стопнут бизнес для проверки установленного ПО.
> Нарушила - фирма босса. Она и ответит.А вот это уже как повезет. В таких случаях почему-то крайним часто оказывается администратор, особенно если он как этот раздолбай, просто вкатил что-то куда-то зачем-то, без каких либо официальных бумаг от руководства на этот счет.
>> Нарушила - фирма босса. Она и ответит.
> А вот это уже как повезет.А никак не повезет, если таки прицепятся.
> В таких случаях почему-то крайним часто
> оказывается администраторКому может быть интересен нищеброд-аникей?
> Тебе надо шашечки или ехать? (С)
> Если ехать - и хватамбо мозгов - берешь и пользуешься. Сам поддерживаешь.
> Если шашечки - плюйся в сторону лицензий. Я вот не онанирую
> на тексты лицух - и вполне себе применяю. И не жужжу.Специалисты уже выехали. Ждите, скоро будут у Вас.
> А позиция принципиального онанис^Wидеалиста-онаниста - "Я на этих условиях даже качать
> не буду!" - а что, в хохотало дадут, если посмотришь и
> поиграешься? Нет? Тогда что ты стонешь раньше, чем тебя бить начали?
> А?Не, ну можно дождаться, когда начнут. Но если наперед извесно, что за это будут бить, то може не надо с этим "играться"?
> Тебе надо шашечки или ехать? (С)Мне надо ехать. Только вот с вашим ораклем оказываеться что я могу или на выбор играть в водителя, крутя руль, бибикая, но ни в коем случае не ездя из пункта А в пункт Б и уж тем более не перевозя никаких грузов, или же я должен платить за аренду драндулета больше чем за аренду аэробуса. Оно мне надо?!
> Если ехать - и хватамбо мозгов - берешь и пользуешься. Сам поддерживаешь.
Так я так и делаю. С пингвином. Там лицензия не запрещает коммерческое применение. Я не собираюсь гарантировать ораклу что не заработаю на использовании ОС ни цента. И зад свой подставлять под удар юридических служб мне не хочется лишний раз. Какая неожиданность, да?
> на тексты лицух - и вполне себе применяю. И не жужжу.
Ну я как бы не желаю лишний раз подставлять мой зад под законы об авторских правах и наезды юридических служб больших компаний. Так можно основательно залететь при случае. Поэтому класть на лицензии я не буду. Вместо этого я просто выберу продукт которым я могу пользоваться на законных основаниях для решения моих задач. А вы с вашими проблемами сами там разбирайтесь. А я себе лишних проблем в виде вендор-локина и конских условий лицензирования создавать не желаю. Зачем мне тонна проблем на ровном месте?
> не буду!" - а что, в хохотало дадут, если посмотришь и поиграешься?
Понимаете ли, я компьютерами пользуюсь не только для игр. Я еще и деньги на этом зарабатываю. По поводу чего мне условия оракла априори не подходят. Как еще доступнее это объяснить? Мне не поиграться в водителя. Мне ехать.
>> btrfs, - тот просто злостный клеветник.
> Ну вон ZFSников на бзде что-то локапы в кернеле не смущают :).там я их не видел уж года как три. говорят что дедупликация еще приводит к падениям, но она молода и зелена еще...
> еще приводит к падениям, но она молода и зелена еще...Ага, значит как на райды в btrfs, которым без году неделю - наезжать можно, а нa ZFS - ни-ни? Ишь какие хитрые, двухстандартные :)
>> еще приводит к падениям, но она молода и зелена еще...
> Ага, значит как на райды в btrfs, которым без году неделю -
> наезжать можно, а нa ZFS - ни-ни? Ишь какие хитрые, двухстандартные
> :)а где наезды на райды? это всякие 294-ый опять дергаются на зфс, хотя сами еще сопли на кулак мотают...
> а где наезды на райды? это всякие 294-ый опять дергаются на зфс,
> хотя сами еще сопли на кулак мотают...Да просто батхерт некоторых индивидов уже утомил. Да, в лине будет бтрфс. Да, он будет лучше зфс. Да, он будет развиваться намного активнее. Как и все остальное в лине. Кому это не нравится - может поискать крепкую стену и место для разбега. И не надо засорять форум вашим батхертом.
> Думаю, 15-20 летВы уверены что думаете? :) Делаю ставку: аналитик из-за парты приврал раз в 5, если не больше. Собственно, по минимуму оно уже сейчас вполне работает и особых отвалов башки не наблюдается.
Оно так работало 6 лет назад. И в тестах рвало все и вся. Именно по этому Линус и сказал тогда знаменитую фразу - "будущее линукса это btrfs, а пока перетопчемся на ext4".
> "будущее линукса это btrfs, а пока перетопчемся на ext4".А что тут не так? Именно так оно и есть. Ext4 резвый но - простой и не функциональный. Это один из лучших "заапгрейженных классических" дизайнов.
В каком состоянии сейчас находятся обслуживающие утилиты? В прошлый раз, когда пытался фиксить ошибки фс - утилита падала со страшными ассертами. ФС хорошая, мне нужно сжатие и снапы, но вот только из за проблем я сомневаюсь опять ставить её. Сейчас на reiserfs 3.
> Сейчас на reiserfs 3.Думаете, у рейзера утилиты восстановления сильно лучше? Вот уж что у рейзера проблематичное - так это они. Рейзеровские утилиты умеют окончательно "дочинивать" тома.
Очередной пример, как линуксоиды хаяли ZFS за то что там встроенный RAID и она-де комбайн, и радуются как только то же появилось в btw. Лол.