блочный уровень по сравнению с клонированием уровня файла?
Я просто недавно прошел ту же оценку, обрабатывают меня. Я нашел этот поток, который ударил меня твердо в лагерь Nehalem:
communities.vmware.com/thread/202280 (не может отправить гиперссылку, потому что я - новый пользователь),
По существу результаты указывают, что для приложений памяти-intesive, 8 ядер Nehalem будут обычно превосходить 16 по характеристикам из предыдущего поколения Xeon или Opteron в этом отношении.
Введите по абсолютному адресу вокруг на anandtech.com, и Вы найдете подобные сравнительные тесты.
Хорошо самое очевидное преимущество клонирования уровня файла состоит в том, что Вы не напрасно тратите время, клонируя неиспользованные блоки. Например, клон 40G раздел с 10G данных потребует 40G чтений и 40G записей на блочном уровне, но близко к 10G чтений и 10G записей на уровне файла.
Одно незначительное преимущество клонирования уровня файла, то, что оно эффективно отлично дефрагментирует Вашу файловую систему одновременно, тогда как блочный уровень, клонирующий фрагментацию клонов также.
Клонирование блочного уровня более просто, и Вы не должны волноваться ни о каком виде полномочий или других проблем, Вы знаете для 100%, уверенных, что клон будет идентичен оригиналу, но для уровня файла, клонирующегося возможно пойти не так, как надо, если Вы портите свои настройки.
-
1Если у Вас есть инструмент, чтобы сделать блочный уровень, клонирующийся, который знает о структуре файловой системы, он может пропустить неиспользованные блоки, и таким образом, возможно, не требуются полных 40 ГБ чтений/записей. I' m думающий zfs отправляют/получают сюда, но I' m уверенный существуют другие файловые системы или инструменты, которые делают что-то подобное. – Mark 18 July 2009 в 00:40
-
2Если it' s знающий о структуре файловой системы, it' s инструмент клонирования уровня файла. – womble♦ 18 July 2009 в 01:59
Мой худший опыт с клонированием уровня файла был разделом NT4 на 20 ГБ с крошечными файлами приблизительно на 1.6 м. Скорость передачи была бы ~8Meg/sec с клонированием блочного уровня (по 100Meg сеть) и должна была взять где-нибудь между часом и полутора часами, это закончилось в <150K/sec из-за всего файла system\permissions наверху и заняло почти два дня.
Как люди сказали, что блочный уровень использования, когда хит на метаданных файла является слишком большим. Используйте файл, базирующийся, когда не будет многих файлов.
Я привык к системе репликации блоков, которая только копирует блоки, которые изменились и выделяются файлам. Это может работать очень хорошо.
Файловая репликация является дешевой и легкой сделать в открытой системе однако rsync/unison, для сценариев нужно больше обслуживания, чем репликация на NAS или SAN.
Если существуют миллионы файлов затем, блочный уровень является единственным способом пойти, у нас есть много файловых систем, которые имеют 40 миллионов файлов в 600 ГБ, и файловая репликация не собирается работать там.