| |
| 2.37, Anatoliy (??), 13:07, 03/11/2009 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>круть, файлопомойки на freenas и freebsd зарулят теперь окончательно.
Осталось самая малось, сделать нормальную поддержку SAN.
| | |
| |
| |
| 4.49, QuAzI (ok), 14:53, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>ага, подружить фрю с iSCSI так и не удалось
А FreeNAS это разве не FreeBSD с поддержкой iSCSI?
| | |
| 4.98, Warhead Wardick (?), 19:09, 03/11/2009 [^] [^^] [^^^] [ответить]
| –2 +/– |
Ну зачем же на всю страну кричать что руки мол растут из ... альтернативного места :)
Впрочем смотри FreeNAS - там оно уже настроено, как раз для кух^W начинающих.
PS: Просто для прикола было проверенно: ORACLE 10g RAC против них ничего не имеет, жрёт и работает :)
| | |
| 4.106, Aleksey Salow (ok), 20:22, 03/11/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
 Где именно у вас подружить не получилось? У меня фряха раздаёт по iscsi zvol-ы, и достаточно быстро.
| | |
| |
| 5.112, Ant (??), 23:02, 03/11/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
>Где именно у вас подружить не получилось? У меня фряха раздаёт по
>iscsi zvol-ы, и достаточно быстро.
Раздовать, может она и научилась, если установить из /usr/ports/net/iscsi-target, а вот как подманитировать с iscsi... Извините, у меня на 7.х в кернел паник уходит, к сожалению... C EMC CX3-10 проблемы? Если у кого-нибудь получилось, буду рад об этом услышать...
| | |
| |
| |
| 7.134, Ant (??), 12:36, 04/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
Вот и стоит Solaris 10, пока нормальной поддержки SAN не будет. :-(
| | |
|
| 6.119, Aleksey Salow (ok), 02:07, 04/11/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
>Раздовать, может она и научилась, если установить из /usr/ports/net/iscsi-target, а вот как
>подманитировать с iscsi... Извините, у меня на 7.х в кернел паник
>уходит, к сожалению...
8-CURRENT какой-то древний и 8-BETA1 полёт нормальный. Возможно в семёрке и были какие-то грабли, хотя думаю об этом в рассылках freebsd говорили бы.
| | |
| |
| 7.135, Ant (??), 12:36, 04/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>>Раздовать, может она и научилась, если установить из /usr/ports/net/iscsi-target, а вот как
>>подманитировать с iscsi... Извините, у меня на 7.х в кернел паник
>>уходит, к сожалению...
>
>8-CURRENT какой-то древний и 8-BETA1 полёт нормальный. Возможно в семёрке и были
>какие-то грабли, хотя думаю об этом в рассылках freebsd говорили бы.
>
Спасибо, попробую.
| | |
|
|
|
|
|
|
| 1.2, uldus (ok), 10:36, 03/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Меня удивляет, как такое простое и казалось бы очевидное решение раньше не придумали. По сути автоматическая расстановка хардлинков на блочном уровне.
| | |
| |
| 2.16, al (??), 11:31, 03/11/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
Дело не в идее. Дело в реализации. Понаписать это все так чтобы оно надежно работало
| | |
| 2.34, xxx (??), 12:56, 03/11/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
Если мне не изменяет память, нечто подобное, как и многое другое типа мнгновенных снимков и т. д. давно уже было реализовано в Plan9.
| | |
| 2.96, iZEN (ok), 18:54, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Меня удивляет, как такое простое и казалось бы очевидное решение раньше не
>придумали. По сути автоматическая расстановка хардлинков на блочном уровне.
Хардилинки — только для файлов. А здесь работа идёт на уровне блоков данных. Так что — круче только яйца, замороженные в жидком азоте!
| | |
| |
| 3.116, pavlinux (ok), 01:17, 04/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>>Меня удивляет, как такое простое и казалось бы очевидное решение раньше не
>>придумали. По сути автоматическая расстановка хардлинков на блочном уровне.
>
>Хардилинки — только для файлов. А здесь работа идёт на уровне блоков
>данных. Так что — круче только яйца, замороженные в жидком азоте!
>
Не, яйцы это ещё не круть, круть это определений дуплей на уровне магнитных доменов, по намагниченности :)
Ну или хотя бы секторов.
А создателю ZFS переквалифицыроваться в разработчика нового интерфейса и
контроллера дисков, SCZI - Small Computer ZFS Interface.
Может на аппаратном уровне оно ещё интересней SCSI/SAS будет.
| | |
|
|
| 1.3, letsmac (?), 10:39, 03/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Интересно насколько упадёт скорость записи в таком режиме.
>>В таких системах может быть достигнута экономия дискового пространства в разы.
Интересно как система будет правильно отрабатывать многопотоковую запись/ дефрагментацию в таких системах.
| | |
| |
| 2.20, Mikula (?), 11:42, 03/11/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
 >дефрагментацию в таких системах.
Забудьте это слово применительно к ZFS ;)
| | |
| |
| 3.51, аноним (?), 15:09, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
А мозк включить? От фрагментации данных на диске ZFS не спасет, а эта недоидея ее только повысит.
| | |
| |
| 4.53, Mikula (?), 15:11, 03/11/2009 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>А мозк включить?
Включайте!
>От фрагментации данных на диске ZFS не спасет, а эта недоидея ее только повысит.
ZFS не подвержена фрагментации. Правда анонимам это неведомо. :)))
| | |
| |
| 5.78, аноним (?), 17:07, 03/11/2009 [^] [^^] [^^^] [ответить]
| +4 +/– | |
Вы неуч. ZFS подвержена фрагментации также как и любая другая ФС.
Пусть есть два файла, у которых каждый второй блок совпадает. ZFS не долга думая удаляет дубликаты, и получается, что при последовательном чтении для каждого второга блока надо лезть в другое место диска. Возражения будут?
| | |
| |
| |
| 7.124, User294 (ok), 04:57, 04/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Это не актуально. SSD и им подобные на дворе.
Дяденька, подарите мне SSD на 4 Тб, я с удовольствием отправлю жесткие диски в отставку. А то если их покупать за свой счет, можно пожалуй остаться без портков и с пустыми карманами :). SSD настолько злобно стоят что даже корпоративщики их используют сильно местами. А учтя что они еще и интенсивные записи в большом объеме не очень любят (число циклов перезаписи у флеша ограниченое и в ряде режимов SSD долго не протянут) - удовольствие получается дорогое и достаточно нишевое.
| | |
|
| 6.151, Mikula (?), 10:03, 05/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Вы неуч. ZFS подвержена фрагментации также как и любая другая ФС.
Судя по этому высказыванию Вы не знаете матчасти. Так что анон вперёд в гугл. И не порите больше чушь, ей больно.
| | |
| |
| 7.161, User294 (ok), 06:25, 06/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
Камон, расскажите же нам наконец - как это CoW да вдруг делается совсем без фрагментации?
| | |
|
|
| 5.120, User294 (ok), 04:33, 04/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>ZFS не подвержена фрагментации. Правда анонимам это неведомо. :)))
CoW не подверженный фрагментации? Сойдет за анекдот сезона :))). А не расскажете как идея CoW уживается с отсутствием фрагментации?Чисто на уровне технологий :)
ЗЫ а вот объединение блоков - неплохо придумано, тем более что ФС 1 хрен этим занимается. Потенциальные грабли - небольшое повреждение может оказаться куда более деструктивно чем обычно. Но идея дедупликатора на уровне ФС - хороша. Она очевидна но вот на практике ее почему-то до сих пор никто не реализовал и я видел как минимум пофайловые дедупликаторы.
| | |
| |
| |
| 7.168, Planner (?), 19:06, 26/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
не верю! Где бенчмарки? У мну на ноуте тормозит ужасно, если сильно фрагментированный pool заполнен на 97-99%.
| | |
|
|
|
|
| 3.101, Аноним (-), 19:34, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
Да, именно забудьте.
Дефрагментировать zfs невозможно.
А вот фрагментацию ее механизмы повышают. И очень сильно.
| | |
| |
| 4.169, Planner (?), 19:09, 26/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
возможно, но только методом копирования данных на новый носитель и копирования их назад :-(
| | |
|
|
| |
| 3.52, аноним (?), 15:10, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Дефрагментация... А она еще кому-то нужна?
кагбе да, если есть желание добиться максимальной скорости работы с устройством.
всё понятно, конечно, zfs рулит, ssd рулит, etc.
(потреbлядство же)
| | |
| |
| 4.55, Mikula (?), 15:17, 03/11/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
>>Дефрагментация... А она еще кому-то нужна?
>
>кагбе да, если есть желание добиться максимальной скорости работы с устройством.
Эта проблема где нибудь существует? кроме как на виндавозных FS?
ЕМНИП Ext4/UFS2 такой бяки почти нет, в отличие от...
| | |
| |
| 5.57, аноним (?), 15:24, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
безусловно, даже если один кластер с краю блина, а другой в самой жопе, то фрагментации нет, потому что её не может быть, потому что ext4/ufs2/zfs/lyalix/rulez/backtoschool
| | |
| |
| 6.61, 222 (?), 15:29, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>безусловно, даже если один кластер с краю блина, а другой в самой
>жопе, то фрагментации нет, потому что её не может быть, потому
>что ext4/ufs2/zfs/lyalix/rulez/backtoschool
а если он еще и на другом диске, вообще лучше сразу застрелиться, иначе как же мы на рейде без дефрагментации то жить будем
| | |
| 6.69, Mikula (?), 16:16, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>потому что её не может быть, потому что ext4/ufs2/zfs/lyalix/rulez/backtoschool
Нет не поэтому, но Ваш красноглазый задор меня развесилил. Вы уж хотя бы матчасть подучите Робачевского почитайте, глядишь знаний прибавиться, а задора анонимного поуменьшится. :-D))
| | |
|
| 5.80, аноним (?), 17:07, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
Везде существует. Просто нормальные ФС не склонны создавать ее на пустом месте, в отличие от.
| | |
| 5.121, User294 (ok), 04:38, 04/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Эта проблема где нибудь существует? кроме как на виндавозных FS?
>ЕМНИП Ext4/UFS2 такой бяки почти нет, в отличие от...
Почти нет - да, но всегда может найтись какойнить граничный случай... я вот например сумел достичь удаления 1 файла на XFS в течении аж 30 секунд и не очень быстрого чтения оного ;).Хотя XFS борется с фрагментацией очень сильно и загнать его в такое состояние можно только весьма специфичными действиями. Остальным тоже можно поднасрать если задаться целью. В реальной жизни конечно засрать том с такими ФС нелегко но - при должных усилиях все-таки возможно несколько просадить.
| | |
| |
| 6.153, Mikula (?), 10:25, 05/11/2009 [^] [^^] [^^^] [ответить] | +/– | Насрать, извините, можно везде, но когда при записи 1000 1Гб файлов фрагментация... большой текст свёрнут, показать | | |
|
|
| 4.71, Анон (?), 16:28, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
Откуда виндовозный подход и кто вам таки сказал, что фрагментация повышает скорость работы с диском?
| | |
| |
| 5.75, аноним (?), 16:40, 03/11/2009 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>Откуда виндовозный подход
старайтесь реже посещать лор.
>кто вам таки сказал, что фрагментация повышает скорость работы с диском?
логика и здравый смысл.
| | |
| 5.79, letsmac (?), 17:07, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
Все ФС основанные на деревьях Бэйэра от фрагментации сильно не страдают. Если только при мощном потоковом чтении. Но это не значит, что они не страдают вовсе. И относится это ко ВСЕМ файловым системам без исключений.
| | |
| |
| 6.88, sceptic (?), 17:38, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Все ФС основанные на деревьях Бэйэра от фрагментации сильно не страдают. Если
>только при мощном потоковом чтении. Но это не значит, что они
>не страдают вовсе. И относится это ко ВСЕМ файловым системам без
>исключений.
Что за деревья такие? Где можно почитать?
| | |
| |
| 7.92, аноним (?), 18:06, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Что за деревья такие? Где можно почитать?
b-дерево. учебник по программированию для первого-второго курса
| | |
|
| 6.102, Аноним (-), 19:35, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Все ФС основанные на деревьях Бэйэра от фрагментации сильно не страдают. Если
>только при мощном потоковом чтении. Но это не значит, что они
>не страдают вовсе. И относится это ко ВСЕМ файловым системам без
>исключений.
Поясните, как Б-деревья помогают избежать фрагментации?
| | |
| |
| 7.122, User294 (ok), 04:45, 04/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Поясните, как Б-деревья помогают избежать фрагментации?
А никак сами по себе не помогают, ха-ха-ха :))). Чуваки козыряют терминами без включения головного мозга. Более того - CoW-based дизайны еще и сами по себе достаточно склонны к фрагментации. Ну или как кто-то себе представляет всякие там снапшоты без фрагментации, интересно?Собссно CoW-механика подразумевает некую фрагментацию :P
| | |
|
| 6.123, User294 (ok), 04:51, 04/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Все ФС основанные на деревьях Бэйэра от фрагментации сильно не страдают.
Позорище космофлота! А вы сможете рассказать почтенной публике как вы представляете логику работы CoW без фрагментации? Да, я более менее въехал как эта красивая и эффективная идея работает ... и с удовольствием вас послушаю, как же там обойтись без фрагментаци, когда собссно копируемый в новое место блок по определению будет неким фрагментом :). Да, когда-то потом возможно выполнить слияние-дефрагментацию и прочая, но сие как раз будет отдельным явным действом.
| | |
|
|
|
|
|
| 1.4, Nexor (?), 10:54, 03/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Мне страшно от слов "менее надежный". Как можно обойтись без точной проверки блоков? Если у нас вдруг окажутся разные данные с одинаковым хэшем то полный пипец будет
| | |
| |
| |
| 3.13, Nexor (?), 11:26, 03/11/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ну вот если размер блока 4кбайта, а хэш 256 байт. Сколько блоков удастся однозначно идентифицировать?
| | |
| |
| 4.17, QuAzI (ok), 11:35, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Ну вот если размер блока 4кбайта, а хэш 256 байт. Сколько блоков
>удастся однозначно идентифицировать?
Ну возьмите все свои разделы, сбейте хеши и размер всех файлов в БД, поищите совпадающие, сравните по содержимому. Когда найдёте, тогда будет суть флейм. Хотя и так никто трезвый включать эту опцию на /tmp не додумается.
| | |
| |
| 5.32, 222 (?), 12:33, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>>Ну вот если размер блока 4кбайта, а хэш 256 байт. Сколько блоков
>>удастся однозначно идентифицировать?
>
>Ну возьмите все свои разделы, сбейте хеши и размер всех файлов в
>БД, поищите совпадающие, сравните по содержимому. Когда найдёте, тогда будет суть
>флейм. Хотя и так никто трезвый включать эту опцию на /tmp
>не додумается.
для ценнейших данных там кстати еще и режим verify есть
| | |
| 5.48, nikos (??), 14:37, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
 просто данные для вас не ценны
md5 от IP сильно ускоряет работу многих приложений, но, вот новость то, не уникально это значение, пока поймали за хвост проблему сошло 7 потов. Так же будет если после совпадения Хеша не проверять данные на взаимное совпадение.
| | |
| |
| 6.60, 222 (?), 15:26, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>просто данные для вас не ценны
>md5 от IP сильно ускоряет работу многих приложений, но,
>вот новость то, не уникально это значение, пока поймали за
>хвост проблему сошло 7 потов. Так же
>будет если после совпадения Хеша не проверять данные на
>взаимное совпадение.
ну так хочешь проверять содержимое, проверяй, есть же эта опция
| | |
|
|
| 4.127, pavlinux (ok), 05:46, 04/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Ну вот если размер блока 4кбайта, а хэш 256 байт.
> Сколько блоков удастся однозначно идентифицировать?
64 Эксабайт.
| | |
|
|
| 2.9, Аноним (-), 11:02, 03/11/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
Там процент вероятности коллизии имеет значение с 256 нулями, т.е. пока солнце не погаснет надежности хватит. С дргой стороны для контроля целостности теже самые хэши используются и никто не застрахован от сбоя памяти в сочетании с коллизией в ECC.
| | |
| 2.10, QuAzI (ok), 11:07, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
Тоесть появится некоторый файл такой же длинны, с таким же хешем? К тому же вопрос ставился не про замену SHA256 а про вторичный хеш.
| | |
| |
| 3.24, zazik (ok), 11:48, 03/11/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
>Тоесть появится некоторый файл такой же длинны, с таким же хешем? К
>тому же вопрос ставился не про замену SHA256 а про вторичный
>хеш.
Почему файл? Блок. А блоки все одинаковой длины, не?
| | |
|
|
| 1.5, QuAzI (ok), 10:55, 03/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
дефрагме... что простите?
А почему скорость должна упасть? Там хеши вычисляются, поиск по хешам милое дело, это вам не обход дерева каталогов с сравнением размера с последующим сравнением содержимого, как в винде все эти чистилки/удалялки копий делают.
| | |
| |
| 2.8, letsmac (?), 10:59, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
Ну это один обход. А тут при каждой записи вычисление хэша каждого блока + поиск + и тд. При перезаписи блока так ещё и ссылки отчищать. Архивная така ФС выходит.
| | |
| |
| 3.11, QuAzI (ok), 11:10, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Ну это один обход. А тут при каждой записи вычисление хэша каждого
>блока + поиск + и тд. При перезаписи блока так ещё
>и ссылки отчищать. Архивная така ФС выходит.
Нет, ну как бы ZFS поддерживает архивацию, но речь не о том. Допустим поиск дубликатов будет делать scrub или другая сервисная фича, это ещё предстоит устаканить. Тоесть создав файл предполагается же, что он ещё 33 раза поменяется. Другой вопрос это "упаковать", в порядке сервисного обслуживания.
| | |
| |
| 4.19, 222 (?), 11:40, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Нет, ну как бы ZFS поддерживает архивацию, но речь не о том. Допустим поиск дубликатов будет делать scrub или другая сервисная фича, это ещё предстоит устаканить. Тоесть создав файл предполагается же, что он ещё 33 раза поменяется. Другой вопрос это "упаковать", в порядке сервисного обслуживания.
во первых не файл, а блок
во вторых в блоге явно сказано дедупликация происходит сразу же
в третьих чексум блока вычисляется всегда, даже без дедупликации, с ней дополнительно появится только операция поиска в существующих хэшах
что в свою очередь ест память для них, но пока таблица влезает в память практически не сказывается на производительности и дает небольшое замедление при невлезающей в память таблице
читайте первоисточники
| | |
| |
| 5.38, QuAzI (ok), 13:14, 03/11/2009 [^] [^^] [^^^] [ответить] | +/– | Перечитал Это я затупил, там просто обзор есть, мол Data can be deduplicated a... большой текст свёрнут, показать | | |
| 5.40, B.O.B.A.H. (??), 13:23, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>в память практически не сказывается на производительности и дает небольшое замедление
>при невлезающей в память таблице
>
видел, когда ZFS ооочень тормозила, когда системе памяти не хватало.
но это исключительная ситуация - файлов на ФС было создано чрезвычайно много и они постоянно создавались/модифицировались.
| | |
| |
| 6.41, QuAzI (ok), 13:26, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>
>>в память практически не сказывается на производительности и дает небольшое замедление
>>при невлезающей в память таблице
>>
>
>видел, когда ZFS ооочень тормозила, когда системе памяти не хватало.
>но это исключительная ситуация - файлов на ФС было создано чрезвычайно много
>и они постоянно создавались/модифицировались.
Можете описать, как вы добились такой нагрузки?
| | |
| |
| 7.114, B.O.B.A.H. (??), 00:52, 04/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
вкратце - когда кол-во файлов приближалось к 100 000 000 (сто млн) - ZFS начинал заметно (даже глазу) тормозить, к примеру, на команде
ls -l
решило проблему простое увеличение памяти на сервере - с 8 Г до 16.
всё это дело наблюдалось прошлым летом.
сейчас, возможно, ситуация изменилась.
| | |
|
| 6.97, аноним (?), 18:56, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>видел, когда ZFS ооочень тормозила, когда системе памяти не хватало.
Врете. ARC работает независимо от остального VM, поэтому скорее будет паника kmem_too_small, чем zfs будет не хватать памяти. Сейчас сделали backpressure vm на arc, так что arc будет ужиматься если памяти будет не хватать, но все равно даже при arc_max=30M ZFS работает с замечательной скоростью.
| | |
| |
| 7.156, B.O.B.A.H. (??), 15:46, 05/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> чем zfs будет не хватать памяти.
думаю, что "памяти" хватало - никакой паники.
только не вся служебная информация о ФС не могла поместиться в ОП в один момент времени
| | |
|
|
|
| 4.31, letsmac (?), 12:30, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>>Допустим поиск дубликатов будет делать scrub или другая сервисная фича, это ещё предстоит устаканить
Тогда смысл несколько теряется. При удалении/изменении захэшированного файла, всё равно что произойдёт? Делать ремап блоков файла придется. Т.Е получается то-же разархивирование. Каждый раз прогонять распакованный файл и переколбашивать изменнёные блоки - не очень правильное решение.
>>Другой вопрос это "упаковать", в порядке сервисного обслуживания.
Вот и я говорю для архивов - неплохая фишка. Особенно для документных. Или выставлять атрибуты для файла отдельные - "сжимаемый" или фасовать по изменению. Получается "псевдоархив" с большой скоростью доступа.
| | |
|
|
|
| 1.12, Knuckles (ok), 11:26, 03/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Вставка хардлинка на блок другого файла это фактически фрагментация. При хорошей "оптимизации" пространства скорость чтения должна ощутимо упасть.
| | |
| |
| 2.14, QuAzI (ok), 11:30, 03/11/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
>Вставка хардлинка на блок другого файла это фактически фрагментация. При хорошей "оптимизации"
>пространства скорость чтения должна ощутимо упасть.
А 33 копии одного и того же файла в разных частях жёсткого диска, это лучше смотрится по части фрагментации?
| | |
| |
| 3.18, Knuckles (ok), 11:38, 03/11/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
Им необязательно быть фрагментированными. Все 33 вполне могут быть записаны на поверхности диска непрерывно. А вот если у вас такая помойка, что вы 33 одинаковых файла храните, то спасти место вам никакая ZFS не поможет.
| | |
| |
| 4.30, gyouja (?), 12:21, 03/11/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
уважаемый, при чем здесь помойка? пример - на сервере несколько десятков человек работают с одним репозиторием какой-нибудь VCS
| | |
| 4.99, Warhead Wardick (?), 19:21, 03/11/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
Если бы у тебя было хоть какое образование то ты бы знал о третьем начале ...
Классический размен скорости на размер. Причём пока не понятно 1:1 или всё же выгодали.
| | |
| |
| 5.108, Knuckles (ok), 20:50, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Если бы у тебя было хоть какое образование
Ох вау.
>то ты бы знал о третьем начале ...
Это что-то из твоей религии?
| | |
|
|
|
|
| 1.15, ameoba32 (?), 11:30, 03/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 Сомнительная полезность. В плане производительности, проблемы калькуляции свободного места на диске.. Да и сколько там можно сэкономить, дупликатов не так много, да и при текущей цене $/Tb.
| | |
| |
| 2.21, QuAzI (ok), 11:42, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Сомнительная полезность. В плане производительности, проблемы калькуляции свободного места на диске.. Да
>и сколько там можно сэкономить, дупликатов не так много, да и
>при текущей цене $/Tb.
А что не так со свободным местом на диске и его калькуляцией? Производительность останется в рамках. Если у вас дубликатов нет и данных для которых эта ФС нужна, может и писать не стоило? Владельцам файлообменников очень пригодится например.
| | |
| 2.22, 222 (?), 11:42, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Сомнительная полезность. В плане производительности, проблемы калькуляции свободного места на диске.. Да
>и сколько там можно сэкономить, дупликатов не так много, да и
>при текущей цене $/Tb.
однако это не только место, это и плюс в производительности записи, за счет меньшего числа операций и плюс меньшее использовании памяти приложениями за счет шареных блоков в открытых файлах
| | |
| |
| 3.27, Knuckles (ok), 11:50, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>это и плюс в производительности записи, за счет меньшего числа операций
Неверно. Операций будет больше. Потому что COW.
>и плюс меньшее использовании памяти приложениями за счет шареных блоков в открытых файлах
Неверно. Никак не повлияет. Для отображения файла в память, ее нужно выделить все равно столько же. А вот процесс чтения будет несколько иным, но он скрыт драйвером ФС.
| | |
| |
| 4.29, 222 (?), 11:55, 03/11/2009 [^] [^^] [^^^] [ответить] | +/– | я рад что есть люди знающие системы лучше разработчиков It all depends on you... большой текст свёрнут, показать | | |
| |
| 5.72, Knuckles (ok), 16:33, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>the performance improvement is due to the elimination of disk writes when storing duplicate data
Ага. А когда у одного файла та повторяющаяся часть поменялась, нужно это отследить и выделить дополнительный блок, в который записать изменения.
>plus the reduced memory footprint due to many applications sharing the same pages of memory.
Слепление страниц ядро Линукс умеет само.
| | |
| |
| 6.76, 222 (?), 16:43, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>>the performance improvement is due to the elimination of disk writes when storing duplicate data
>
>Ага. А когда у одного файла та повторяющаяся часть поменялась, нужно это
>отследить и выделить дополнительный блок, в который записать изменения.
если поменялась, запись нового блока идет на общих условиях, что меняем мы этот блок, что новый записываем
отличаются условия для неизменных блоков
| | |
|
|
|
|
| 2.23, Knuckles (ok), 11:47, 03/11/2009 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>дупликатов не так много
Да нет, на уровне блоков наверняка дубликатов достаточно. Такие вещи как заголовки исполняемых файлов (да и других форматов) ИМХО.
>при текущей цене $/Tb.
А это гораздо более существенно. Экономить сотню мегабайт при ее цене в пару баксов путем усложнения ФС (а значит и ее надежности) это как-то неразумно.
| | |
| |
| 3.26, 222 (?), 11:49, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>А это гораздо более существенно. Экономить сотню мегабайт при ее цене в
>пару баксов путем усложнения ФС (а значит и ее надежности) это
>как-то неразумно.
а сильно от самих данных будет зависеть, на некоторых одни минусы получаем
| | |
|
| 2.28, zazik (ok), 11:51, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Сомнительная полезность. В плане производительности, проблемы калькуляции свободного места на диске.. Да
>и сколько там можно сэкономить, дупликатов не так много, да и
>при текущей цене $/Tb.
Как-то действительно странно. Если дуБликатов мало, нафига оно надо, если дубликатов много, увеличивается вероятность коллизии.
| | |
| |
| 3.36, max (??), 13:07, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Как-то действительно странно. Если дуБликатов мало, нафига оно надо, если дубликатов много,
>увеличивается вероятность коллизии.
почитайте про свойства крипто-хеш-функций.
| | |
|
| 2.63, Daltinn (ok), 15:40, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
 >Сомнительная полезность. В плане производительности, проблемы калькуляции свободного >места на диске.. Да и сколько там можно сэкономить, дупликатов не так много, да и при >текущей цене $/Tb.
А на SAS, SAN или даже когда место на RAID заканчивается, и его надо расширять не простым добавлением винтов?
| | |
|
| 1.25, webbeans (?), 11:49, 03/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>Для систем, на которых не достаточно проверки по хэшу SHA256, предусмотрен режим повышенной надежности, при котором производится дополнительное полное сравнение блоков данных при совпадении хэша.
Круто, то есть, по сути, будут две контрольные суммы (два хэша) - SHA256 и ещё один?
| | |
| |
| 2.39, QuAzI (ok), 13:17, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Круто, то есть, по сути, будут две контрольные суммы (два хэша) -
>SHA256 и ещё один?
Ну да, и дополнительная проверка блока на "совпадение". Всё опционально, как и сама фича.
Интересно, к выходу 8.0-RELEASE фича будет доступна?
| | |
| |
| 3.81, аноним (?), 17:11, 03/11/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
>>Круто, то есть, по сути, будут две контрольные суммы (два хэша) -
>>SHA256 и ещё один?
>
>Ну да, и дополнительная проверка блока на "совпадение". Всё опционально, как и
>сама фича.
Охренеть. Скоро контрольные суммы будут занимать столько же, сколько и сами данные. Тогда можно будет просто заменить их копией данных и проблем с коллизиями не будет.
| | |
| |
| 4.100, QuAzI (ok), 19:25, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
Будут. Прийдёт злобный аноним, скажет что копия неверная, потому что ему это марсиане сказали, хотя обосновать он это фактами и не может, сотрёт обе записи и вообще нихрена не будет, одни только коллизии в анонимном вакууме
| | |
|
|
|
| 1.42, barmaglot (??), 13:27, 03/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 http://en.wikipedia.org/wiki/SHA256
Algorithm and
variant Output size (bits) Internal state size (bits) Block size (bits) Max message size (bits) Word size (bits) Rounds Operations Collisions found
------------------------------------------------------------------------
SHA-256/224 256/224 256 512 264 − 1 32 64 +,and,or,xor,shr,rot None
| | |
| 1.43, barmaglot (??), 13:44, 03/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Похоже уже все лоровцы сюда перебрались. "Фключить моск" никому идея не приходит. Пишут что попало без знания предмета.
О вероятности коллизий на пространстве 2^64 для SHA256 алгоритма можно почитать тут: http://www.springerlink.com/content/t1087808x7506841/
Если говорить о 4к,8к,16к,256к блоках, то можно просто игнорировать вероятность коллизии.
> Круто, то есть, по сути, будут две контрольные суммы (два хэша) - SHA256 и ещё один?
Для сравнения блоков по хешу используется тот-же самый хеш, что и для проверки целостности блока. Сравнение блоков на совпадение про "повышеных запросах надёжности", происходит только однажды про создании ссылки !
| | |
| |
| 2.154, Дмитрий Ю. Карпов (?), 11:05, 05/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> Если говорить о 4к,8к,16к,256к блоках, то можно просто игнорировать вероятность коллизии.
Когда-то Intel в Пентиумах допустила ошибку в делении и посчитала её маловероятной. Потом ей пришлось менять все дефектные процессоры за её счёт.
Почитайте что-нибудь про то, как организовывают транзакции: там не смотрят на вероятность неправильного срабатывания, а доказывают правильность работы алгоритма как математики доказывают теоремы.
| | |
| 2.157, Spase (?), 00:14, 06/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Если говорить о 4к,8к,16к,256к блоках, то можно просто игнорировать вероятность коллизии.
>
Хм... Вероятность коллизии, получается, стремится к нулю. Ну тогда алгоритм восстановления блока по хешу с вероятностью, стремящейся к 100% - в студию... Это ж какой архиватор получается. Ресурсоемкость алгоритма не интересует.
Ну а ежели тупо посчитать... Длина блока, скажем, 512 байт (1 сектор) = 2^4096. Длина хеша - 256 бит. Итого получаем секторов с одинаковым хешем 2^(4096-256). Понятно, что различных значений хеша меньше, чем секторов на диске, но тем не менее...
| | |
|
| 1.44, Аноним (-), 13:47, 03/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
вот весело будет если блок сдохнет при такой системе я потеряю все 33 файла а по старинке только один.
| | |
| |
| 2.45, QuAzI (ok), 13:52, 03/11/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
>вот весело будет если блок сдохнет при такой системе я потеряю все
>33 файла а по старинке только один.
При активной записи на жёсткий диск однотипных данных вы потеряете жёсткий диск раньше, чем при такой системе работы. Или на всём винте вам нужен только один этот файл (кстати, а почему блок сдохнет, циклов перезаписи в него то мы не повторяем? Т.е. это диагноз - винту кранты). И важные данные принято зеркалить, а ещё лучше архивировать куда-нибудь подальше, а то вдруг пожар, а паранойя спать не даёт.
К тому же режим опциональный. Т.е. для вас он будет выключен by default - не бойтесь за свои 33 копии.
| | |
| 2.54, barmaglot (??), 15:16, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
В ZFS поддерживаются RAID5/6 конфигурации, при последнем теряйте хоть 2 блока , хоть 2 диска целиком, - данные не будут утеряны.
| | |
| |
| 3.74, Anon Y Mous (?), 16:37, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>В ZFS поддерживаются RAID5/6 конфигурации, при последнем теряйте хоть 2 блока
>, хоть 2 диска целиком, - данные не будут утеряны.
Угу, тока называются они RAID-Z1, RAID-Z2. Да, еще и RAID-Z3 есть ;-)
| | |
|
|
| 1.46, Aleksey (??), 14:07, 03/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Пример реального применения:
1) вы занимаетесь монтажом видео. Периодически делая копии полученных результатов, чтобы позже иметь возможность откатить изменения. Для такого случая экономия может быть достаточно весомой.
2) все ваши пользователи работают под терминалками внутри одного компьютера с набором похожих данных. Тут тоже возможен выйгрыш.
3) Внутри многих файлов можно обнаружить целые массивы состоящие из символов с кодом 0. Вероятно и тут можно получить выйгрыш. Такого рода крупные разряженные файлы будут получаться достаточно маленькими.
| | |
| |
| 2.50, Юра (??), 14:58, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
1) лучше решать с помощью snapshot's, уже существующих в zfs.
| | |
| |
| 3.56, Aleksey (??), 15:23, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
Не факт. В каталогах структурировать информацию намного легче. Для пользователя точно.
| | |
| |
| 4.83, аноним (?), 17:12, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Не факт. В каталогах структурировать информацию намного легче. Для пользователя точно.
ln -s .zfs/snapshot/XXX MyCoolDir, не?
| | |
|
| 3.59, barmaglot (??), 15:26, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
Чушь, это совершенно разные фичи.
Вообще вероятность совпадения информации на блоках будет различаться от задач которые решаются. Это очевидно. Но статистически вопрос совершенно неосвещённый :)
| | |
|
| 2.155, Дмитрий Ю. Карпов (?), 11:07, 05/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> Внутри многих файлов можно обнаружить целые массивы состоящие из символов с кодом 0. Вероятно и тут можно получить выйгрыш.
Обработка таких случаев присутствовала в UFS изначально.
| | |
|
| 1.58, аноним (?), 15:25, 03/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Эм, а что, если по умолчанию используется чексуммы fletcher4, а в dedup sha256, будут считаться сразу две чексуммы?
| | |
| |
| 2.62, 222 (?), 15:35, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Эм, а что, если по умолчанию используется чексуммы fletcher4, а в dedup
>sha256, будут считаться сразу две чексуммы?
хм, хороший вопрос, похоже да
разве что и для дедупликации включен режим fletcher4,verify
кстати по этому поводу в блоге "On systems with a very high data ingest rate of largely duplicate data, this may provide better overall performance than a secure hash without collision verification. "
| | |
|
| 1.64, Аноним (-), 15:50, 03/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
Красиво, конечно, расписано для сферических данных с дубликатами в вакууме, но хочется конкретных цифр, например, для VPS-хостинга: экономия такая, скорости чтения/записи стали такие и такие, потребовалось доставить X Гб оперативки/ не потребовалось, эти же параметры через месяц работы.
ЗЫ: ну не верю я, что алгоритм записи с созданием хэша для каждого блока и поиска этого хеша в большой хэш-таблице сопоставим по скорости и ресурсоемкости с алгоритмом записи без этих наворотов.
| | |
| 1.65, аноним (?), 15:51, 03/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Чего-то я не совсем понял, видать и в самом деле просто туплю.
В новости "...Наиболее заметный эффект от технологии исключения дубликатов можно наблюдать при организации резервного копирования... В таких системах может быть достигнута экономия дискового пространства в разы...". Разве смысл резервного копирования не заключается еще и в том, что куски данных избыточно дублируются (физически), чтобы если сдохнет один блок, данные можно было взять в другом месте? А так все "ссылки" ведут на один блок, он сдох - и сдохли все 15 "ссылок" на этот блок из разных мест файловой системы
| | |
| |
| 2.66, аноним (?), 15:53, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
особенно если есть множество одинаковых блоков - заполненных нулями и т.п. Тогда ссылок на этот блок будет тысячи
| | |
| |
| 3.67, QuAzI (ok), 16:04, 03/11/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
>особенно если есть множество одинаковых блоков - заполненных нулями и т.п. Тогда
>ссылок на этот блок будет тысячи
Ну как бы, вы ежедневно боитесь того что ваш винт помрёт, а из сервера пойдёт дым. Это вопрос не к ФС, а к тому, где вы покупаете железо. Я же например боюсь что моя доблесная бухалтерия положив очередную сагу о инвентаризации на клавиатуру превратит базу в нечто хаотичное. Или например попадётся добрый вирь, который попытается зашифровать всё до чего дотянется, или просто какой-нибудь умник (царство ему небесное) на шаре попытается удалить всё. В общем не падения железа, а именно нарушения данных. При этом данные как правило не изменяются, а дописываются, дописываются и ещё раз дописываются.
А по железу вон, выше читайте, RAIDZ в помощь.
| | |
| |
| 4.111, Гений (ok), 23:01, 03/11/2009 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Ну как бы, вы ежедневно боитесь того что ваш винт помрёт, а из сервера пойдёт дым. Это вопрос не к ФС, а к тому, где вы покупаете железо.
молодец, профессионализм не скроешь )
| | |
|
|
|
| 1.77, jSnake (??), 16:51, 03/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Меня вот что интересует.
Вот ZFS обеспечивает дедупликацию на уровне ФС, Оракл на уровне БД, сторэджи (типа Hitachi) вообще чуть ли не на уровне контроллеров. Кстати, сжатия это тоже касается (ну модно сейчас дедуплицировать и сжимать).
Внимание, вопрос: а насколько эффективно будет всё ЭТО работать и сколько ресурсов пожирать в реальной системе? Зачем мне три(!!!) технологии дедкпликации/сжатия на одном несчастном куске данных? Это ведь какая мука для инженера выбрать)
| | |
| |
| 2.82, letsmac (?), 17:11, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Вот ZFS обеспечивает дедупликацию на уровне ФС, Оракл на уровне БД, сторэджи
>(типа Hitachi) вообще чуть ли не на уровне контроллеров.
Нормальные БД типа SyBase и Oracle позволяют хранить базу на RAW разделе. Что в принципе снижает количество прокладок вдвое.
| | |
| |
| 3.85, jSnake (??), 17:24, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
Не, я не про то (быстродействие баз на raw - отдельная оччччень спорная тема).
Я про именно сжатие (oracle грозит в 30 раз, hitachi в 24, symantec и emc не помню). Смысл в том, что эти механизмы уже реализуются на уровне железа (снизу) и софта (сверху). Теперь эта фича есть в ФС (посередине). Так вот резонный вопрос: а насколько оно всё надо? Особенно учитывая тот факт, что за эти опции тот же Оракл немалые деньги просит. Короче, форониксу задачка не из простых...
| | |
| |
| 4.94, Aleksey (??), 18:27, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
Ну если у вас все это (железо, поддерживающее сжатие) есть, то конечно надо где-то отключить. Но ведь у кого-то (сюрприз-сюрприз) может такого не оказаться.
| | |
| |
| 5.104, jSnake (??), 19:59, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
Что-то мне подсказывает, что очень-очень скоро сюрпризом станет наличие проблем с тройной (в лучшем случае) "оптимизацией" хранения данных - вряд ли вендоры будут разбираться в каком окружении будет соседствовать их железо/софт. Кстати, очень любопытно как отнесётся к этой разработке Oracle - им ведь нафик не нужные такие замечательные, но бесплатные фичи.
| | |
| |
| 6.107, QuAzI (ok), 20:49, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>как отнесётся к этой разработке Oracle - им ведь нафик не
>нужные такие замечательные, но бесплатные фичи.
Это проблемы оракла, что оно бесплатно и замечательно. Пусть сделает лучше и народ подумает, авось стоит заплатить.
| | |
| |
| 7.110, jSnake (??), 22:18, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Это проблемы оракла, что оно бесплатно и замечательно. Пусть сделает лучше и
>народ подумает, авось стоит заплатить.
А вот в том-то и проблема, что оракл УЖЕ продаёт СВОИ опции БД, сравнимые с возможностями opensource zfs (те же дедупликация/компрессия). И вот тут у Ларри и Co может возникнуть вполне предсказуемое меркантильное желание воткнуть бревно в колёса идей разработчиков zfs (про brtfs традиционно молчим). А вот это уже печально, ибо при всём пафосе никакого комьюнити не хватит довести zfs до ранга популярной фс. А жаль.
| | |
|
|
|
|
|
|
| 1.84, аноним (?), 17:16, 03/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
Замечательно. Мало того, что ZFS даже не пытается выделять непрерывные куски места под sparse файлы, т.е. файл, скачанный торрентом (где куски приходят черти в каком порядке, и в таком же ложатся на диск, судя по количеству seek'ов при чтении) фрагментирован просто неимоверно, так это теперь еще и его копированием не вылечишь. Way to go.
Алсо умиляют идиоты, которые говорят что ZFS не подвержена фрагментации.
| | |
| |
| 2.86, QuAzI (ok), 17:26, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
Фигассе, вы каждый фильм (которые в последнее время делают с таким сюжетом, что не факт что досмотришь, не говоря о том чтобы пересматривать и сохранять) ещё и копируете на отдельное, сугубо свободное и выделенное для него место? Для таких как вы - опция выключена by default.
| | |
| |
| 3.90, аноним (?), 17:40, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Фигассе, вы каждый фильм (которые в последнее время делают с таким сюжетом,
>что не факт что досмотришь, не говоря о том чтобы пересматривать
>и сохранять) ещё и копируете на отдельное, сугубо свободное и выделенное
>для него место? Для таких как вы - опция выключена by
>default.
Нет, это делает торрент клиент. Фракментированный кусок дерьма, разумеется, удаляется.
| | |
|
| 2.87, Аноним (-), 17:37, 03/11/2009 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> ZFS даже не пытается выделять непрерывные куски места под sparse файлы
откуда дровишки? и какой толк в sparse файлах, если место под них выделяется? отключи в своем torrent-клиенте использование sparse файлов тогда.
>Алсо умиляют идиоты, которые говорят что ZFS не подвержена фрагментации.
фрагментация не влияет на скорость SSD дисков. А дефрагметировать ZFS можно при помощи resilver'инга.
| | |
| |
| 3.91, аноним (?), 17:49, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>откуда дровишки? и какой толк в sparse файлах, если место под них
>выделяется? отключи в своем torrent-клиенте использование sparse файлов тогда.
Место можно выделять, а занимать только если писать больше некуда, знаете ли. Использование sparse файлов отлючить это кшна выход, ради этого надо было ZFS ставить. Только вот мне как-то не улыбается забивание 30гигов нулями при старте торрента, даже если мне их него нужен один 10kb файл. Кроме того, для всех торрентов, которые скачаны на десяток процентов и стоят на паузе, у меня на качающей машинке банально не хватит места.
>фрагментация не влияет на скорость SSD дисков. А дефрагметировать ZFS можно при
>помощи resilver'инга.
Особенно на jbod, ага. Да и на raidz это сделано через огромную жопу.
| | |
| |
| 4.113, Аноним (-), 23:54, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> для всех торрентов, которые скачаны на десяток процентов и стоят на паузе, у меня на качающей машинке банально не хватит места.
с dedup=on блоки с нулями не будут кушать места как раньше ;)
поэтому sparse-файлы более не нужны
> Особенно на jbod, ага.
нету в ZFS jbod'а. Пул из двух и более диском - это stripe (raid0). Кроме фрагментации там проблемой еще будет self-healing из-за отсутствия репликации (окромя copies).
| | |
| |
| 5.128, User294 (ok), 08:13, 04/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>с dedup=on блоки с нулями не будут кушать места как раньше ;)
>поэтому sparse-файлы более не нужны
Остается только крайне забавный вопрос: в насколько же большую задницу попадет от фрагментации после этого ваша ФС из-за тысяч и тысяч небольших дозаписей блоков, которые по мере скачки торента постепенно, медленно и по садистски *перестанут* быть дупами и стало быть их *придется* раздуплять обратно в отдельные блоки. Один хрен нивелировав ваши потуги экономии места. А вот алгоритмам аллокации все это подгадит очень сильно и мне так кажется что вам не понравится то что вы получите в результате. Если кто храбрый - может проверить, только если у вас том в хлам зафрагментируется - я тут не виноват, это вы все сами, etc :-P. Мой прогноз - если не дай боже скачка будет медленной а объем файлов заметно превысит кэш, скорее всего на томе будет твориться в итоге "полный пэ".
| | |
| |
| 6.131, QuAzI (ok), 08:49, 04/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
Для начала будет дописываться текущий блок, а потом уже, по мере необходимости, создаваться новый. В общем фрагментация будет такая же, как сейчас или меньше (за счёт того что некоторые блоки уже есть на винте и их сдедупили). ИМХО
| | |
| |
| 7.132, User294 (ok), 09:21, 04/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Для начала будет дописываться текущий блок, а потом уже, по мере необходимости,
>создаваться новый. В общем фрагментация будет такая же, как сейчас или
>меньше (за счёт того что некоторые блоки уже есть на винте
>и их сдедупили). ИМХО
Меньше? Даже в самом хорошем случае (т.е. все содержимое файла лежит более-менее последовательно), на дедупнутых блоках головы диска придется сгонять куда-то в задницу чтобы достать эти дедупнутые блоки, собственно - чудес не бывает. Т.е. степень фрагментации будет чуть больше. В сильно вермишельных случаях - вот там вопрос интересный. По идее что так что этак будет опа, где больше и где меньше вопрос интересный, скорее всего в обоих случаях вам хватит чтобы проникнуться :). Сбой в логике у вас в том месте что блоки конечно есть и их сдедупили, но вот только для их прочтения придется сделать перемещение голов куда-то сильно в сторону. Единственный вариант когда вы можете быть правы - много одинаковых блоков и кэш удержал нужный блок, так что диск мучать не пришлось. Но это не про торенты...
| | |
| |
| 8.133, 222 (?), 10:32, 04/11/2009 [^] [^^] [^^^] [ответить] | +/– | gt оверквотинг удален вот что странно, вначале человек плачет что плахой zfs н... текст свёрнут, показать | | |
| 8.136, QuAzI (ok), 13:07, 04/11/2009 [^] [^^] [^^^] [ответить] | +/– | Боже мой, вас почитать, DOS ещё жив Про упреждающее чтение ни слова, про буфера... текст свёрнут, показать | | |
| |
| 9.137, 222 (?), 13:24, 04/11/2009 [^] [^^] [^^^] [ответить] | +/– | ну это же очевидно, у них регулярно по расписанию стартует дефраг на их терабайт... текст свёрнут, показать | | |
|
|
|
|
| 5.138, QuAzI (ok), 14:05, 04/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
а без дедупликации каким местом self-healing работает (окромя copies) ?
| | |
| |
| 6.139, QuAzI (ok), 15:08, 04/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
Вот блин почему так трудно узнать ответ на те вопросы, которые действительно интересны?
Насколько я понял, благодаря тому что sha256 получается уникальным, при отключенном dedup можно делать self-healing через поиск блоков с совпадающим sha256. А вот делает ZFS это или нет непонятно. Нагуглил только что в сложных комбинашках, например в зеркале, она self-healing за счёт копии делает.
Была бы такая пальцатая ФС с самовосстановлением, останется только блекджек прикрутить и гарных девок.
| | |
| |
| 7.142, QuAzI (ok), 21:03, 04/11/2009 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Sha256 in ZFS IS used for self healing if you set it as checksum algorithm.. It is used, instead of fletcher, to check integrity of every block in datasets, not only in RAIDZ. It was like that since creation of ZFS, and now this same checksum field can be used for two purposes, integrity and deduplication.
Posted by Bartek Pelc on November 04, 2009 at 08:52 AM PST #
Всё, осталось блекджек и гарных девок. Зачётная ФС
| | |
| 7.143, Аноним (-), 23:39, 04/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> при отключенном dedup можно делать self-healing через поиск блоков с совпадающим sha256.
ЕМНИП, не делает. Но на основе dedup кода, думаю, будет сделать не трудно. Что-то типа dedup=keep, когда reference count'ы увеличиваются, но при повреждении данных в одном идет self-healing за счет оставшихся. Только это будет мало чем отличаться от copies.
| | |
| |
| 8.145, QuAzI (ok), 00:48, 05/11/2009 [^] [^^] [^^^] [ответить] | +/– | Какой dedup Какое copies Фиг с ними, это мне уже не интересно Хеши совпадают ... текст свёрнут, показать | | |
|
|
|
| 5.148, аноним (?), 06:36, 05/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
> с dedup=on блоки с нулями не будут кушать места как раньше ;)
> поэтому sparse-файлы более не нужны
Ага. Терь для торрентов нельзя будет использовать ZFS вообще, гыгы.
> нету в ZFS jbod'а
Ну страйп, какая разница. Никакого ресильверинга не будет в любом случае.
| | |
|
|
|
| 2.103, DrNo (??), 19:42, 03/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
Иди учи матчасть, а потом перечитай свое сообщение и отредактируюй как следует.
| | |
| |
| 3.149, аноним (?), 06:37, 05/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Иди учи матчасть, а потом перечитай свое сообщение и отредактируюй как следует.
Сначала напиши в поле "сообщение", что хотел сказать, потом жми "Отправить", позорище.
| | |
|
|
| 1.89, Аноним (-), 17:39, 03/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
значит ли это, что я могу перемещать/копировать файлы между ZFS-датасетами почти мгновенно?
| | |
| |
| 2.105, Andrey Mitrofanov (?), 20:09, 03/11/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
Нет, это значит, что 'cat /dev/dull > $FILE' теперь совсем не ограничен по объёму файла и практически не ограничен по количеству таких %) файлов на диске. :-D
| | |
| |
| |
| 4.150, Andrey Mitrofanov (?), 09:24, 05/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>/dev/zero хотели сказать?
Гы, ес-тестно. Оговорочки по англо-русскому словарю, наверное...
dull
[dʌl]
1. _a.
1) тупой; глупый
2) скучный; монотонный; dull beggar (или fish) скучный человек
3) тупой; притупленный; dull pain тупая боль; dull of hearing тугой на
ухо
4) тупой, неотточенный
5) тусклый
6) пасмурный
7) неясный; dull sight слабое зрение
8) безрадостный, унылый, понурый
9) вялый (о торговле)
10)неходкий, не имеющий спроса (о товаре)
2. _v. притуплять(ся); делать(ся) тупым, тусклым, вялым, скучным; to dull
the edge of one's appetite заморить червячка
/dev/dull - /me тупит %)
| | |
|
| 3.129, User294 (ok), 08:14, 04/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>'cat /dev/dull > $FILE'
Что за девайс у вас такой хитрый? Он показывает при этой операции дулю? Или что за ...? :)
| | |
|
|
| 1.144, Аноним (-), 23:43, 04/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
не очень понятно можно ли использовать по дефолту быстрый fletcher4, и, если такой блок уже есть, то сверять еще и sha256? или ничем не будет отличаться от verify?
| | |
| |
| 2.146, QuAzI (ok), 00:50, 05/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>не очень понятно можно ли использовать по дефолту быстрый fletcher4, и, если
>такой блок уже есть, то сверять еще и sha256? или ничем
>не будет отличаться от verify?
Если я правильно понял, то как раз и имелось ввиду что можно использовать fletcher4 для ускорения и второй алгоритм можно прикрутить.
| | |
|
|
