Этого треда уже нет.
Это копия, сохраненная 6 февраля 2015 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 6 февраля 2015 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
56 Кб, 720x280
Кто юзал, что имеете сказать? Удалось ли MS создать конкурента ZFS или все как обычно у них? Я знаю, что в ZFS фич больше, но интересует в первую очередь контроль целостности и self-healing.
>>1111034
Пердолик пригорел. Пердолик, как там BtrFS - к 2020 хоть из альфы выберется?
Пердолик пригорел. Пердолик, как там BtrFS - к 2020 хоть из альфы выберется?
>>1111035
Похуй на говно красноглазых когда есть BSD и божественная ZFS.
Так что иди нахуй, спермач.
Говноиндусы до сих пор ничего не могут запаилить подобного. Где поддержка шифрования и сжатия для кластеров>4k? Где моментальные снапшоты? Где динамический размер екстента/кластера или бля я должен давать 128к и для иконок и для фильмов?
Ты обосрался маня, тебе продают перерисованное говно без существенных изменений. Уже ебанные сервиспаки продают и выдают за отдельную версию, а спермач и рад.
Похуй на говно красноглазых когда есть BSD и божественная ZFS.
Так что иди нахуй, спермач.
Говноиндусы до сих пор ничего не могут запаилить подобного. Где поддержка шифрования и сжатия для кластеров>4k? Где моментальные снапшоты? Где динамический размер екстента/кластера или бля я должен давать 128к и для иконок и для фильмов?
Ты обосрался маня, тебе продают перерисованное говно без существенных изменений. Уже ебанные сервиспаки продают и выдают за отдельную версию, а спермач и рад.
>>1111043
Сперма никак не доберется до уровня BSD двадцатилетней давности. BSD никак не доберется до уровня линукса начала двухтысячных.
Поссал на необучаемых рабов.
Сперма никак не доберется до уровня BSD двадцатилетней давности. BSD никак не доберется до уровня линукса начала двухтысячных.
Поссал на необучаемых рабов.
>>1111041
Нету. Я же сразу написал, что фич меньше.
Тебе сколько лет? Или ты ньюфаг просто? Так полно же тредов, где можно траллеть лалок))). Но зачем ты сюда это притащил? Здесь будет спокойное осуждение преимуществ и недостатков различных ФС, рвать пуканы иди в раковые треды.
>Где
Нету. Я же сразу написал, что фич меньше.
>спермач
>Говноиндусы
>перерисованное говно
>азаза, спермобляди соснулей
Тебе сколько лет? Или ты ньюфаг просто? Так полно же тредов, где можно траллеть лалок))). Но зачем ты сюда это притащил? Здесь будет спокойное осуждение преимуществ и недостатков различных ФС, рвать пуканы иди в раковые треды.
>>1111048
Слишком обогнал свое время. До него еще никто не может добраться, вообще. Есть вероятность, что пока доберутся, он помрет.
Слишком обогнал свое время. До него еще никто не может добраться, вообще. Есть вероятность, что пока доберутся, он помрет.
>>1111053
Plan 9/Inferno?
Plan 9/Inferno?
>>1111053
Если бы ещё OpenSolaris не убивали...
Если бы ещё OpenSolaris не убивали...
>>1111052
В сперме нет ФС, поэтому обсуждение обречено на провал. В сперме есть дыры, бэкдоры, зонды, вирусня, реестр, отсутствие возможности нормальной работы с софтом, да и самого софта без рекламы, зондов и вирусни, есть мусор, глюки, фризы, BSODы. Но ФС нет. Не завезли.
В сперме нет ФС, поэтому обсуждение обречено на провал. В сперме есть дыры, бэкдоры, зонды, вирусня, реестр, отсутствие возможности нормальной работы с софтом, да и самого софта без рекламы, зондов и вирусни, есть мусор, глюки, фризы, BSODы. Но ФС нет. Не завезли.
>>1111051
В чем кривость? с 7ки стоит - ни одного сбоя.
А вот линуксячее говно обосралось. 10 лет побед и вливания бабла (сравни как нибудь мульон в годя для bsd и сколько вливают для твоего велосипеда) и итог:
"В качестве причины прекращения использования по умолчанию Btrfs упоминается периодическое поступление от пользователей жалоб о работе Btrfs, в том числе об ошибках при исчерпании свободного дискового пространства, требующих ручного вмешательства проблемах с ребалансировкой метаданных и низкой производительности, по сравнению с другими ФС."
Охуеть как энтерпрайзненько.
В чем кривость? с 7ки стоит - ни одного сбоя.
А вот линуксячее говно обосралось. 10 лет побед и вливания бабла (сравни как нибудь мульон в годя для bsd и сколько вливают для твоего велосипеда) и итог:
"В качестве причины прекращения использования по умолчанию Btrfs упоминается периодическое поступление от пользователей жалоб о работе Btrfs, в том числе об ошибках при исчерпании свободного дискового пространства, требующих ручного вмешательства проблемах с ребалансировкой метаданных и низкой производительности, по сравнению с другими ФС."
Охуеть как энтерпрайзненько.
>>1111069
Так и не рассказал в чем же кривость?
И почему же у меня все работает множество лет без сбоев.
Так и не рассказал в чем же кривость?
И почему же у меня все работает множество лет без сбоев.
>>1111064
Ты порвалась, сперма.
Ты порвалась, сперма.
>>1111071
В линупсе ты конечно же имеешь свой шкарим? Маня, подотрись своим стимом с 50ю платформерами. Все игры так или иначе все равно под вайном.
В линупсе ты конечно же имеешь свой шкарим? Маня, подотрись своим стимом с 50ю платформерами. Все игры так или иначе все равно под вайном.
>>1111076
Да, на ноуте с 4G так и стоит.
Другое дело что это ведет к снижению производительности. А так ZFS пускали и на гиге памяти.
Да, на ноуте с 4G так и стоит.
Другое дело что это ведет к снижению производительности. А так ZFS пускали и на гиге памяти.
>>1111082
Это говно имитирующее мурошинд, до сих пор недоделано. Какое оно имеет отношение к божественному Скайриму?
>опенмв
Это говно имитирующее мурошинд, до сих пор недоделано. Какое оно имеет отношение к божественному Скайриму?
>>1111078
В линуксе/соляре он имеет нормальную виртуализацию, а не бздкостыль в виде вайна который ещё и в 64 бита(в бзд) не может
В линуксе/соляре он имеет нормальную виртуализацию, а не бздкостыль в виде вайна который ещё и в 64 бита(в бзд) не может
>>1111092
Виртуализация уровня бзддауна
Утёнок с первой игрой в серии ТЕС(скайрим) порвался
>Мне хватает и jailов.
Виртуализация уровня бзддауна
>морроутка пытаеться перефорсить
Утёнок с первой игрой в серии ТЕС(скайрим) порвался
>>1111084
И как, хорошо работает? Слышал еще, что фринасобляди не рекомендуют пускать ZFS без ECC. Мол, если память битфлипнется, обычная ФС не заметит, а ZFS распидорасит из-за чексумм.
>на ноуте с 4G
И как, хорошо работает? Слышал еще, что фринасобляди не рекомендуют пускать ZFS без ECC. Мол, если память битфлипнется, обычная ФС не заметит, а ZFS распидорасит из-за чексумм.
>>1111096
Чёт в голосяндру с этих бзддаунов
> обычная ФС не заметит, а ZFS распидорасит из-за чексумм.
Чёт в голосяндру с этих бзддаунов
>>1111094
лучше уж jail, чем куча недоделанных ОС, в которых до сих пор теряются данные. Пердолики, try harder.
лучше уж jail, чем куча недоделанных ОС, в которых до сих пор теряются данные. Пердолики, try harder.
>>1111062
Кстати многие моды ломаются под вайном из-за неумения в верхний-нижний регистр спермой.
> без модов?
Кстати многие моды ломаются под вайном из-за неумения в верхний-нижний регистр спермой.
>>1111103
Как правило легко правится
там два варианта:
все паковать в BSA - тогда похуй на регистр
править моды/меши.
Серьезно, ты хоть раз наблюдал за свою жизнь подобное? Если же это серьезные данные и коммерческая деятельность, то почему твой говносервер без ECC?
Как правило легко правится
там два варианта:
все паковать в BSA - тогда похуй на регистр
править моды/меши.
>если память битфлипнется
Серьезно, ты хоть раз наблюдал за свою жизнь подобное? Если же это серьезные данные и коммерческая деятельность, то почему твой говносервер без ECC?
>>1111108
Я не наблюдал, Гугл наблюдал.
Причем здесь сервер или не сервер, мой или не мой, серьезные данные или нет - это все не имеет никакого отношения к обсуждению возможного сценария (ссылка выше). Мне интересно, правда ли ZFS здесь будет хуже чем классическая ФС.
>ты хоть раз наблюдал за свою жизнь подобное
Я не наблюдал, Гугл наблюдал.
>почему твой говносервер без ECC
Причем здесь сервер или не сервер, мой или не мой, серьезные данные или нет - это все не имеет никакого отношения к обсуждению возможного сценария (ссылка выше). Мне интересно, правда ли ZFS здесь будет хуже чем классическая ФС.
>>1111118
Такое-то ВЫ ВСЁ ВРЁТИ
Такое-то ВЫ ВСЁ ВРЁТИ
>>1111035
btrfs вполне себе используется в продакшене
https://btrfs.wiki.kernel.org/index.php/Production_Users
btrfs вполне себе используется в продакшене
https://btrfs.wiki.kernel.org/index.php/Production_Users
>>1111120
Прости а причем тут ZFS вообще? Остальные FS имеют libastral чтобы понять что память сбойнула и не запишут поврежденные данные?
Прости а причем тут ZFS вообще? Остальные FS имеют libastral чтобы понять что память сбойнула и не запишут поврежденные данные?
>>1111128
3.5 анонимуса и смартфоны (вообще охуеть). Facebook и Netgear тестируют пока (хотя неясно, зачем она FB вообще). Вот когда NAS начнут с ней поставлять, тогда я может и поверю в ее стабильность.
3.5 анонимуса и смартфоны (вообще охуеть). Facebook и Netgear тестируют пока (хотя неясно, зачем она FB вообще). Вот когда NAS начнут с ней поставлять, тогда я может и поверю в ее стабильность.
>>1111128
какие-то ноунеймы и
support - означает что можно использовать. Но твой пердолячий страх и риск. Мишка Шигорин и тот признался что он бы ни за что не поставил бы в продакшн это поделие. А он какой-никакой дистроклепатель.
>testing in production
какие-то ноунеймы и
>NAS devices from Thecus support Btrfs support
support - означает что можно использовать. Но твой пердолячий страх и риск. Мишка Шигорин и тот признался что он бы ни за что не поставил бы в продакшн это поделие. А он какой-никакой дистроклепатель.
>>1111129
Почитай ссылку https://forums.freenas.org/index.php?threads/ecc-vs-non-ecc-ram-and-zfs.15449/ , там хорошо описан сценарий. Пересказывать дольше получится.
Почитай ссылку https://forums.freenas.org/index.php?threads/ecc-vs-non-ecc-ram-and-zfs.15449/ , там хорошо описан сценарий. Пересказывать дольше получится.
>>1111134
Остальные наебнуться точно так же
То что из-за self-healing может тоже что-то наебнуться - вполне понятно.
Но тут задам вопрос снова: был ли у тебя хотя бы один случай подобного сбоя памяти? На моем опыте память начинала откровенно сбоить и все падало почти сразу, либо она просто не определялась.
Бекапы в любом случае нужны, как и сверка того что набекапленно.
На нормальных серверах всегда используется ECC.
>Since our file got stored in RAM, its been corrupted. Now its 01110011. Then that is forwarded to the disk subsystems and subsequently stored on the disk trashed. If this were file system data you might have bigger problems too
Остальные наебнуться точно так же
То что из-за self-healing может тоже что-то наебнуться - вполне понятно.
Но тут задам вопрос снова: был ли у тебя хотя бы один случай подобного сбоя памяти? На моем опыте память начинала откровенно сбоить и все падало почти сразу, либо она просто не определялась.
Бекапы в любом случае нужны, как и сверка того что набекапленно.
На нормальных серверах всегда используется ECC.
>>1111138
В догонку. Подсчет контрольных сумм можно отключить. Но только ради этого? Бред.
В догонку. Подсчет контрольных сумм можно отключить. Но только ради этого? Бред.
>>1111138
Там и про бэкапы есть.
Очевидно. Оно у меня и на рабочей станции используется. Но ноутов с ECC, например, нет. На самом деле есть - мобильные воркстейшны на базе Xeon E5, но дорого.
Там и про бэкапы есть.
>На нормальных серверах всегда используется ECC
Очевидно. Оно у меня и на рабочей станции используется. Но ноутов с ECC, например, нет. На самом деле есть - мобильные воркстейшны на базе Xeon E5, но дорого.
495 Кб, 1680x1050
>>1111111
Сигнал получен. Приступаю к ликвидации.
Сигнал получен. Приступаю к ликвидации.
Еще одна заметка про ECC: http://louwrentius.com/please-use-zfs-with-ecc-memory.html
>>1111166
Но ведь любая файловая система испортится изза испорченной RAM. Странная статья. Я не понял какая особая связь ZFS и ECC-RAM.
Но ведь любая файловая система испортится изза испорченной RAM. Странная статья. Я не понял какая особая связь ZFS и ECC-RAM.
>>1111148
http://www.opennet.ru/opennews/art.shtml?num=41312
http://www.opennet.ru/opennews/art.shtml?num=41312
>Брендон Филипс (Brandon Philips), технический директор компании CoreOS Inc, развивающей основанное на идеях контейнерной изоляции серверное окружение CoreOS, выступил с предложением ухода от использования по умолчанию файловой системы Btrfs в пользу связки из Ext4 и многослойной файловой системы OverlayFS.
>В качестве причины прекращения использования по умолчанию Btrfs упоминается периодическое поступление от пользователей жалоб о работе Btrfs, в том числе об ошибках при исчерпании свободного дискового пространства, требующих ручного вмешательства проблемах с ребалансировкой метаданных и низкой производительности, по сравнению с другими ФС. Выбор в пользу OverlayFS обусловлен более высокой производительностью, простотой реализации и появлением данной ФС в составе штатного ядра Linux 3.18.
>>1111721
Нахуй все это говно, если есть православная ext4? Годами пользуюсь - ни одного разрыва. Копирование летает. По сравнению с тормознутой и глючной говноNTFS, которое может проебать данные при внезаном отключении, например, просто райская ФС.
Нахуй все это говно, если есть православная ext4? Годами пользуюсь - ни одного разрыва. Копирование летает. По сравнению с тормознутой и глючной говноNTFS, которое может проебать данные при внезаном отключении, например, просто райская ФС.
>>1111722
Ты просто не в теме. Иди вики почитай что ли. Или блог разработчика ZFS.
Ты просто не в теме. Иди вики почитай что ли. Или блог разработчика ZFS.
>>1111722
Как там дела с удалением одного большого файла или кучи мелких? Все так же тормозит как и на ext3? Я не трал, мне просто интересно.
Как там дела с удалением одного большого файла или кучи мелких? Все так же тормозит как и на ext3? Я не трал, мне просто интересно.
>>1111831
Никогда не замечал. Намедни поудалял кучу блюреев спизженных с торрента. Может они недостаточно большие, хз.
Никогда не замечал. Намедни поудалял кучу блюреев спизженных с торрента. Может они недостаточно большие, хз.
>>1111733
Тем не менее они пригодна для него.
Стоит на двух ноутах и десктопе.
Но советовать я бы не стал. Это скорее для тех кто хочет разобраться в системе и заточить под себя, потому как проще чем конфиги и сервисы в FreeBSD еще ничего не видел. Нет там изъебств с runlevel, нет системд с кокококмпиляцией модуля если вдруг захочется что-то поменять, нет привычки менять расоложение конфигов от версии к версии. rc.conf - большая часть всегда тут. И прочее.
Тем не менее они пригодна для него.
Стоит на двух ноутах и десктопе.
Но советовать я бы не стал. Это скорее для тех кто хочет разобраться в системе и заточить под себя, потому как проще чем конфиги и сервисы в FreeBSD еще ничего не видел. Нет там изъебств с runlevel, нет системд с кокококмпиляцией модуля если вдруг захочется что-то поменять, нет привычки менять расоложение конфигов от версии к версии. rc.conf - большая часть всегда тут. И прочее.
>>1111834
У меня на линуксовом NAS - ext3. И удаление тормозит дай боже.
А кучу мелких? Скажем тысяч 50? "допотопная" ufs2 - быстро.
У меня на линуксовом NAS - ext3. И удаление тормозит дай боже.
А кучу мелких? Скажем тысяч 50? "допотопная" ufs2 - быстро.
Эх пердолики, вечно хуйней занимаетесь бессмысленной.
бамп
>>1111111
Ну всё, борда просрана, можете закрывать...
Ну всё, борда просрана, можете закрывать...
>>1111166
https://groups.google.com/forum/#!topic/zfs-macos/qguq6LCf1QQ
A few things to think about when reading that forum post:
- The scenario described in that post is based on the assumption that all blocks read from disk somehow get funneled through a single memory location, which also happens to have a permanent fault.
- In addition, it assumes that after a checksum failure, the corrected data either gets stored in the exact same memory location again, or in another memory location that also has a permanent fault.
- It also completely ignores the fact that ZFS has an internal error threshold and will automatically offline a device once the number of read/checksum errors seen on it exceeds that threshold, preventing further corruption. ZFS will not go and happily mess up your entire pool.
- This would not be silent; ZFS would report a large number of checksum errors on all your devices.
- Blocks corrupted in that particular way would not actually spread to incremental backups or via rsync, as the corrupted blocks would not be seen as modified.
- There is no indication that the reported cases of data loss that he points to are actually due to the particular failure mechanism described in the post; there are lots of other ways in which memory corruption can lead to a file system becoming unmountable, checksums or not.
- Last but not leasts, note that “Cyberjock" is a community moderator, not somebody who’s actually in any way involved in the development of ZFS (or even FreeNAS; see the preface of his FreeNAS guide for some info on his background). If this were really as big of a risk as he thinks it is, you’d think somebody who is actually familiar with the internals of ZFS would have raised this concern before.
Actually, thinking about this some more, the real reason that this hypothetical horror scenario cannot actually happen in real life is that the checksum would never get recomputed from the improperly “corrected” data to begin with: The checksum for a given block is stored in its parent block (which itself has a checksum that is stored in its parent, and so on and so forth, all the way up to the uberblock), not in the block itself. Therefore, if a checksum failure is detected for a block, only the block itself will be corrected (and possibly corrupted as a result of a memory error), not its checksum (which is protected by the parent block’s checksum).
See e.g. the following website for more explanation of how things are organized internally: <http://www.nexenta.com/corp/zfs-education/207-nexentastor-zfs-copy-on-write-checksums-and-consistency>
https://groups.google.com/forum/#!topic/zfs-macos/qguq6LCf1QQ
A few things to think about when reading that forum post:
- The scenario described in that post is based on the assumption that all blocks read from disk somehow get funneled through a single memory location, which also happens to have a permanent fault.
- In addition, it assumes that after a checksum failure, the corrected data either gets stored in the exact same memory location again, or in another memory location that also has a permanent fault.
- It also completely ignores the fact that ZFS has an internal error threshold and will automatically offline a device once the number of read/checksum errors seen on it exceeds that threshold, preventing further corruption. ZFS will not go and happily mess up your entire pool.
- This would not be silent; ZFS would report a large number of checksum errors on all your devices.
- Blocks corrupted in that particular way would not actually spread to incremental backups or via rsync, as the corrupted blocks would not be seen as modified.
- There is no indication that the reported cases of data loss that he points to are actually due to the particular failure mechanism described in the post; there are lots of other ways in which memory corruption can lead to a file system becoming unmountable, checksums or not.
- Last but not leasts, note that “Cyberjock" is a community moderator, not somebody who’s actually in any way involved in the development of ZFS (or even FreeNAS; see the preface of his FreeNAS guide for some info on his background). If this were really as big of a risk as he thinks it is, you’d think somebody who is actually familiar with the internals of ZFS would have raised this concern before.
Actually, thinking about this some more, the real reason that this hypothetical horror scenario cannot actually happen in real life is that the checksum would never get recomputed from the improperly “corrected” data to begin with: The checksum for a given block is stored in its parent block (which itself has a checksum that is stored in its parent, and so on and so forth, all the way up to the uberblock), not in the block itself. Therefore, if a checksum failure is detected for a block, only the block itself will be corrected (and possibly corrupted as a result of a memory error), not its checksum (which is protected by the parent block’s checksum).
See e.g. the following website for more explanation of how things are organized internally: <http://www.nexenta.com/corp/zfs-education/207-nexentastor-zfs-copy-on-write-checksums-and-consistency>
>>1111166
https://groups.google.com/forum/#!topic/zfs-macos/qguq6LCf1QQ
A few things to think about when reading that forum post:
- The scenario described in that post is based on the assumption that all blocks read from disk somehow get funneled through a single memory location, which also happens to have a permanent fault.
- In addition, it assumes that after a checksum failure, the corrected data either gets stored in the exact same memory location again, or in another memory location that also has a permanent fault.
- It also completely ignores the fact that ZFS has an internal error threshold and will automatically offline a device once the number of read/checksum errors seen on it exceeds that threshold, preventing further corruption. ZFS will not go and happily mess up your entire pool.
- This would not be silent; ZFS would report a large number of checksum errors on all your devices.
- Blocks corrupted in that particular way would not actually spread to incremental backups or via rsync, as the corrupted blocks would not be seen as modified.
- There is no indication that the reported cases of data loss that he points to are actually due to the particular failure mechanism described in the post; there are lots of other ways in which memory corruption can lead to a file system becoming unmountable, checksums or not.
- Last but not leasts, note that “Cyberjock" is a community moderator, not somebody who’s actually in any way involved in the development of ZFS (or even FreeNAS; see the preface of his FreeNAS guide for some info on his background). If this were really as big of a risk as he thinks it is, you’d think somebody who is actually familiar with the internals of ZFS would have raised this concern before.
Actually, thinking about this some more, the real reason that this hypothetical horror scenario cannot actually happen in real life is that the checksum would never get recomputed from the improperly “corrected” data to begin with: The checksum for a given block is stored in its parent block (which itself has a checksum that is stored in its parent, and so on and so forth, all the way up to the uberblock), not in the block itself. Therefore, if a checksum failure is detected for a block, only the block itself will be corrected (and possibly corrupted as a result of a memory error), not its checksum (which is protected by the parent block’s checksum).
See e.g. the following website for more explanation of how things are organized internally: <http://www.nexenta.com/corp/zfs-education/207-nexentastor-zfs-copy-on-write-checksums-and-consistency>
https://groups.google.com/forum/#!topic/zfs-macos/qguq6LCf1QQ
A few things to think about when reading that forum post:
- The scenario described in that post is based on the assumption that all blocks read from disk somehow get funneled through a single memory location, which also happens to have a permanent fault.
- In addition, it assumes that after a checksum failure, the corrected data either gets stored in the exact same memory location again, or in another memory location that also has a permanent fault.
- It also completely ignores the fact that ZFS has an internal error threshold and will automatically offline a device once the number of read/checksum errors seen on it exceeds that threshold, preventing further corruption. ZFS will not go and happily mess up your entire pool.
- This would not be silent; ZFS would report a large number of checksum errors on all your devices.
- Blocks corrupted in that particular way would not actually spread to incremental backups or via rsync, as the corrupted blocks would not be seen as modified.
- There is no indication that the reported cases of data loss that he points to are actually due to the particular failure mechanism described in the post; there are lots of other ways in which memory corruption can lead to a file system becoming unmountable, checksums or not.
- Last but not leasts, note that “Cyberjock" is a community moderator, not somebody who’s actually in any way involved in the development of ZFS (or even FreeNAS; see the preface of his FreeNAS guide for some info on his background). If this were really as big of a risk as he thinks it is, you’d think somebody who is actually familiar with the internals of ZFS would have raised this concern before.
Actually, thinking about this some more, the real reason that this hypothetical horror scenario cannot actually happen in real life is that the checksum would never get recomputed from the improperly “corrected” data to begin with: The checksum for a given block is stored in its parent block (which itself has a checksum that is stored in its parent, and so on and so forth, all the way up to the uberblock), not in the block itself. Therefore, if a checksum failure is detected for a block, only the block itself will be corrected (and possibly corrupted as a result of a memory error), not its checksum (which is protected by the parent block’s checksum).
See e.g. the following website for more explanation of how things are organized internally: <http://www.nexenta.com/corp/zfs-education/207-nexentastor-zfs-copy-on-write-checksums-and-consistency>
>>1115348
Да понятно что раздули из мухи слона, почему бы тогда не разобрать случаи когда сбойнет рейд-контроллер/шлейф/уборщица протрет пыль/студент-уёбок прольет кофе или Пистолетов кончит внутрь сервера.
Одинаковая вероятность события.
Да понятно что раздули из мухи слона, почему бы тогда не разобрать случаи когда сбойнет рейд-контроллер/шлейф/уборщица протрет пыль/студент-уёбок прольет кофе или Пистолетов кончит внутрь сервера.
Одинаковая вероятность события.
>>1115479
Стабильность > альфа тест
Стабильность > альфа тест
>>1115498
Уменьшился шелест диска за счёт более разумного использования ОЗУ. Плюс компрессия серьёзно ускоряет доступ.
Уменьшился шелест диска за счёт более разумного использования ОЗУ. Плюс компрессия серьёзно ускоряет доступ.
>>1115499
Т. е. смысл новомодных ФС в перетягивании одеяла с харда на ОЗУ и процессор?
Т. е. смысл новомодных ФС в перетягивании одеяла с харда на ОЗУ и процессор?
>>1115437
Потому что от всего этого защита предусмотрена. Но защиты от сбоя памяти (кроме ECC) нет, ибо если не доверять памяти - чему тогда вообще доверять? Другое дело, что при сбойной памяти, вопреки россказням фринасовцев, распидорашивание вовсе не будет моментальным, незаметным и фатальным.
Потому что от всего этого защита предусмотрена. Но защиты от сбоя памяти (кроме ECC) нет, ибо если не доверять памяти - чему тогда вообще доверять? Другое дело, что при сбойной памяти, вопреки россказням фринасовцев, распидорашивание вовсе не будет моментальным, незаметным и фатальным.
>>1115500
Что плохого в перетягивании одеяла на современный процессор? LZO какое-нибудь ему раз плюнуть , а профит есть. Может ты еще и zram не юзаешь?
Что плохого в перетягивании одеяла на современный процессор? LZO какое-нибудь ему раз плюнуть , а профит есть. Может ты еще и zram не юзаешь?
bump
бамп
>>1131430
хуле ты бампаешь макака?
хуле ты бампаешь макака?
>>1134329
Проследуйте в свой загон.
Проследуйте в свой загон.
>>1111041
тащемто zfs есть и на линуксе. вполне стабильно и шустро работает, уже второй год использую практически на всех инсталляциях серверов.
тащемто zfs есть и на линуксе. вполне стабильно и шустро работает, уже второй год использую практически на всех инсталляциях серверов.
>>1111028
Ты главное не спросил: можно ли на эту йоба-фс ставить саму сперму?
Ты главное не спросил: можно ли на эту йоба-фс ставить саму сперму?
>>1138858
Из педивикии:
В Windows Server 2012 не поддерживается загрузка с ReFS. Ввиду отсутствия поддержки именованных потоков, ReFS не может быть использована для размещения экземпляров MS SQL, включая версию 2012.[10]
Короче, ФС запилили, а как использовать тут же соснули.
Из педивикии:
> Многие возможности NTFS не поддерживаются в ReFS, включая именованные потоки файлов (после проверки на Windows 10 TP ADS работает с ReFS. Для поддержки ReFS нужно вносить изменения в реестр), NTFS Distributed Link Tracking (DLT), короткие имена файлов (формат 8.3), сжатие файлов, шифрование на уровне файлов Encrypting File System, Transactional NTFS, жёсткие ссылки, extended attributes, и дисковые квоты.[4][2] Разреженные файлы (Sparse files) поддерживаются в RTM.[8][9]
В Windows Server 2012 не поддерживается загрузка с ReFS. Ввиду отсутствия поддержки именованных потоков, ReFS не может быть использована для размещения экземпляров MS SQL, включая версию 2012.[10]
Короче, ФС запилили, а как использовать тут же соснули.
>>1138858
Да похуй уже, все равно тут одни ебанутые пердолики. Нашел всю информацию в другом месте.
Да похуй уже, все равно тут одни ебанутые пердолики. Нашел всю информацию в другом месте.
>>1111028
Юзаю почти 1.5 года на r10 из 6 600х15к, адаптек 6405 с ббу и кэшем на 512, всё ок
если сравнивать с нтфс, то медленнее на запись, но и у рефс и у зфс ков. Только вот в моей зфс хранилочке, есть 4 ссд для зил кэша, а у майкрософта хуй. Кэш чтения у мс всегда работал одинаково, без умных предикшенов и прочего, и тут как был тупым, так и остался.
Селфхилинг не проверить ни на зфс, ни на рефс, по той простой причине, что если в зфс сайлент дата корапт ты увидешь во время скруба, то у мс никакого интерфейса для взаимодействия с рефс попросту нет, и ты не знаешь что у тебя там происходит(может у тебя там хард ебанулся и постоянно шлёт Reported_Uncorrectable_Errors портя все данные что найдёт).
Потому как рефс не умеет напрямую с железками работать, а зфс, нутыпонял.жипек
>Кто юзал, что имеете сказать? Удалось ли MS создать конкурента ZFS или все как обычно у них? Я знаю, что в ZFS фич больше, но интересует в первую очередь контроль целостности и self-healing.
Юзаю почти 1.5 года на r10 из 6 600х15к, адаптек 6405 с ббу и кэшем на 512, всё ок
если сравнивать с нтфс, то медленнее на запись, но и у рефс и у зфс ков. Только вот в моей зфс хранилочке, есть 4 ссд для зил кэша, а у майкрософта хуй. Кэш чтения у мс всегда работал одинаково, без умных предикшенов и прочего, и тут как был тупым, так и остался.
Селфхилинг не проверить ни на зфс, ни на рефс, по той простой причине, что если в зфс сайлент дата корапт ты увидешь во время скруба, то у мс никакого интерфейса для взаимодействия с рефс попросту нет, и ты не знаешь что у тебя там происходит(может у тебя там хард ебанулся и постоянно шлёт Reported_Uncorrectable_Errors портя все данные что найдёт).
Потому как рефс не умеет напрямую с железками работать, а зфс, нутыпонял.жипек
>>1139003
по той простой причине что ты долбоеб.
берешь dd и хуяришь по одному из дисков в рейде
>Селфхилинг не проверить ни на зфс, ни на рефс, по той простой причине
по той простой причине что ты долбоеб.
берешь dd и хуяришь по одному из дисков в рейде
>>1138946
Покажи и мне, пожалуйста.
Покажи и мне, пожалуйста.
>>1139111
Это ты же у нас долбоебушка с RAID10, но не способный его проверить, а не я.
Охуйеть теперь, как таким даунам доверяют железо.
Еще вариант - во время работы выдираешь диск и вставляешь. Но долбоеб, пытающийся тут похвастаться, перечисляя никому неинтересные характеристики, помимо самого рейда, даже это не способен придумать.
Пиздец.
Это ты же у нас долбоебушка с RAID10, но не способный его проверить, а не я.
Охуйеть теперь, как таким даунам доверяют железо.
Еще вариант - во время работы выдираешь диск и вставляешь. Но долбоеб, пытающийся тут похвастаться, перечисляя никому неинтересные характеристики, помимо самого рейда, даже это не способен придумать.
Пиздец.
>>1139152
ты блять конченный чтоли, что считаешь что железо которое у меня под рукой имеется, ахуеть какое достижение?
просто пиздец, такой бабах на ровном месте, а если бы я написал что у меня тут 3пар и дата домейн с внх на 8 стоек, ты бы на тяге своего пердака уже догонял вояджер?
ладно, хуй с тобой с твоими проекциями, ну нахуя мне в рабочей системе, которые люди время от времени юзают, создавать проблемы на ровном месте? в принципе мне похуй - я за эту тачку отвечаю только чтобы данные не проебались, а данные проебутся максимум за последние 24 часа, и то если тачка банально сгорит со всем. бизнесу позволительно такие потери, переразвернуть этот сервис - дело 1.5 часа за чайком и сладеньким, лениво потыкивая в какие апдейты накатить и как размапить новый волюм и какие шары каким юзерам отдавать.
повторюсь, скилловый ты наш, берёшь виртуалбоск, делаешь {1..100500} блобов, суешь в гостя, в винде делаешь свои делишки, и пишешь какой ты неосилятор и обосрамс, потому что если ты дд вольёш хуйни в место где были данные, то им придёт пизда с 99% вероятностю. т.к. в рефс нет дедупликации, а точечные изменения по 1 биту возможно рефс пофиксит, только вот вопрос нахуя? это не отказоустойчивость, это просто механизм защиты данных, всё.
ты блять конченный чтоли, что считаешь что железо которое у меня под рукой имеется, ахуеть какое достижение?
просто пиздец, такой бабах на ровном месте, а если бы я написал что у меня тут 3пар и дата домейн с внх на 8 стоек, ты бы на тяге своего пердака уже догонял вояджер?
ладно, хуй с тобой с твоими проекциями, ну нахуя мне в рабочей системе, которые люди время от времени юзают, создавать проблемы на ровном месте? в принципе мне похуй - я за эту тачку отвечаю только чтобы данные не проебались, а данные проебутся максимум за последние 24 часа, и то если тачка банально сгорит со всем. бизнесу позволительно такие потери, переразвернуть этот сервис - дело 1.5 часа за чайком и сладеньким, лениво потыкивая в какие апдейты накатить и как размапить новый волюм и какие шары каким юзерам отдавать.
повторюсь, скилловый ты наш, берёшь виртуалбоск, делаешь {1..100500} блобов, суешь в гостя, в винде делаешь свои делишки, и пишешь какой ты неосилятор и обосрамс, потому что если ты дд вольёш хуйни в место где были данные, то им придёт пизда с 99% вероятностю. т.к. в рефс нет дедупликации, а точечные изменения по 1 биту возможно рефс пофиксит, только вот вопрос нахуя? это не отказоустойчивость, это просто механизм защиты данных, всё.
>>1139172
Кому интересно сколько там у тебя мегабайтов кеша у рейда с батарейкой? От этого будет зависеть функциональность рейда? с 256М будет пахать RAID5 а с 512M RAID10?
Раз нет разницы то зачем это вообще упоминать, всем похуй.
Срал я на майрософтовские поделия.
Твой вопрос был про невозможность тестирования селфхилинга у ZFS. А это бред.
И таки да, подобное тестирование проводят до ввода рейда в эксплуатацию, а не когда на дваче посоветуют. Отсюда у меня фейспальм, а не бомбаж как ты там нафантазировал. Ты уже должен был бы знать как все это будет работать и что делать в случае отказа. По своему опыту скажу что у ZFS селфхилинг очень даже работает. Даже дату и объем покажет когда случилась оказия.
С мелкософтом я завязал давно. Хватило ебли с динамическими дисками. Когда это говно тупо отказывалось грузиться с зеркала.
Это значит что твоим данным придет пизда лишь от потери одного диска. Согласно тебе. Хуевый рейд значит у тебя. Зачем он нужен? Хуячь в JBOD/RAID0, смысл тот же.
Кому интересно сколько там у тебя мегабайтов кеша у рейда с батарейкой? От этого будет зависеть функциональность рейда? с 256М будет пахать RAID5 а с 512M RAID10?
Раз нет разницы то зачем это вообще упоминать, всем похуй.
>рефс пофиксит
Срал я на майрософтовские поделия.
Твой вопрос был про невозможность тестирования селфхилинга у ZFS. А это бред.
И таки да, подобное тестирование проводят до ввода рейда в эксплуатацию, а не когда на дваче посоветуют. Отсюда у меня фейспальм, а не бомбаж как ты там нафантазировал. Ты уже должен был бы знать как все это будет работать и что делать в случае отказа. По своему опыту скажу что у ZFS селфхилинг очень даже работает. Даже дату и объем покажет когда случилась оказия.
С мелкософтом я завязал давно. Хватило ебли с динамическими дисками. Когда это говно тупо отказывалось грузиться с зеркала.
>потому что если ты дд вольёш хуйни в место где были данные, то им придёт пизда с 99%
Это значит что твоим данным придет пизда лишь от потери одного диска. Согласно тебе. Хуевый рейд значит у тебя. Зачем он нужен? Хуячь в JBOD/RAID0, смысл тот же.
>>1139197
ну тут я с тобой отчасти солидарен, всё больший процент майкрософтских поделий мне не нравится
ох, ну тут у меня обосрамс(я раза 4 переписывал эту хуйню и уже замылил глазе), у рефс я не смогу узнать что происходит, у зфс есть кли который раскажет что и как, и в случае чего, можно в бд залезть где зфс хранит метаданные, но я в эту святыню, как грязный грешник не хожу. обычного zpool status хватает увидеть, были ли ошибки с прошлого скруба, или нет.(на 6 машинах, с кол-вом дисков и их качеством от регулярных сата, до ссд и сас интирпрайс, с лси и адаптековыми хба, ни на одной тачке не было инкремента циферок, а хардов и ссд там навалом, которая под нфс/рсинк с загибается на цпу(казалось бы схуяли, ну да тут это критично)
в смысле блять? защита данных через ков и метаданные- это не рейд, дедупликация позволит выжить данным, если вдруг ты каким-то хуем поцарапаешь часть блинов, а на других блинах тот же датасет будет читаться, дедуп по мне так нужен, тоьлко в архивных копиях, которые "вытаскиваются" и сайлент корапт проходит в виде окисления\дрейфа атомов и прочей хуйни. не использовать сейчас тот же р6 или р1 для важных данных - это уже имбецилизм, и как кто-то говорил "вон из профессии". Да и в реалиях компании в которой я работаю, мне бы какой-нибудь цеф заебашить, а то что-то я пригорюнился с цен на висан от вмвари. вот ещё мальца, и зоопарк из виртуализаций уйдёт, и настанет благодать, наймут вместо меня обезянку, которая в висфере могёт вм создавать, и будет счастье
>Срал я на майрософтовские поделия.
ну тут я с тобой отчасти солидарен, всё больший процент майкрософтских поделий мне не нравится
>Твой вопрос был про невозможность тестирования селфхилинга у ZFS. А это бред.
ох, ну тут у меня обосрамс(я раза 4 переписывал эту хуйню и уже замылил глазе), у рефс я не смогу узнать что происходит, у зфс есть кли который раскажет что и как, и в случае чего, можно в бд залезть где зфс хранит метаданные, но я в эту святыню, как грязный грешник не хожу. обычного zpool status хватает увидеть, были ли ошибки с прошлого скруба, или нет.(на 6 машинах, с кол-вом дисков и их качеством от регулярных сата, до ссд и сас интирпрайс, с лси и адаптековыми хба, ни на одной тачке не было инкремента циферок, а хардов и ссд там навалом, которая под нфс/рсинк с загибается на цпу(казалось бы схуяли, ну да тут это критично)
>Это значит что твоим данным придет пизда лишь от потери одного диска. Согласно тебе. Хуевый рейд значит у тебя. Зачем он нужен? Хуячь в JBOD/RAID0, смысл тот же.
в смысле блять? защита данных через ков и метаданные- это не рейд, дедупликация позволит выжить данным, если вдруг ты каким-то хуем поцарапаешь часть блинов, а на других блинах тот же датасет будет читаться, дедуп по мне так нужен, тоьлко в архивных копиях, которые "вытаскиваются" и сайлент корапт проходит в виде окисления\дрейфа атомов и прочей хуйни. не использовать сейчас тот же р6 или р1 для важных данных - это уже имбецилизм, и как кто-то говорил "вон из профессии". Да и в реалиях компании в которой я работаю, мне бы какой-нибудь цеф заебашить, а то что-то я пригорюнился с цен на висан от вмвари. вот ещё мальца, и зоопарк из виртуализаций уйдёт, и настанет благодать, наймут вместо меня обезянку, которая в висфере могёт вм создавать, и будет счастье
Кстати спермачи, а микрософт научилась наконец сжимать и шифровать файлы на разделах с кластером > 4к? Чем эти бездари там занимаются в своих Шиндовс 10?
Это же пиздец. Системный раздел как минимум в 20-30Гб и вся MFT засрана этим мелкокластерным говном.
Это же пиздец. Системный раздел как минимум в 20-30Гб и вся MFT засрана этим мелкокластерным говном.
Тред утонул или удален.
Это копия, сохраненная 6 февраля 2015 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 6 февраля 2015 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.