Вход | Регистрация




Напомнить пароль?

Вход через OpenID

Облако Тегов
Active Directory, Cisco, Data Deduplication, dynamic access control, File Server, File Server Resource Manager, File System, Hyper-V, PowerShell, powershell web access, Security, Server Core, Server Interface, smapi, SMB, smi-s, storage, Storage Management, vmware, Новое, установка
Архив
Март 2012 (5)
Февраль 2012 (4)
Январь 2012 (3)
Декабрь 2011 (3)
Ноябрь 2011 (3)
Октябрь 2011 (10)
Windows Server 8 » Новости » Storage Management » Что такое ReFS

Что такое ReFS

 (голосов: 2)

Resilient File System   "...Сегодня система NTFS является наиболее широко используемой, передовой и функционально богатой файловой системой. Но переосмысливая Windows а мы в данный момент разрабатываем Windows 8 - мы не останавливаемся на достигнутых высотах. Поэтому вместе с Windows 8 мы также внедряем совершенно новую файловую систему. ReFS (расшифровывается, как Resilient File System - Отказоустойчивая файловая система) создана на основе NTFS, поэтому в ней сохранились важнейшие возможности совместимости, в то же время она разработана и спроектирована с учётом нужд нового поколения технологий и сценариев хранения данных. В Windows 8, ReFS будет введена только как часть Windows Server 8, такой же подход мы использовали для внедрения всех предыдущих файловых систем. Конечно же, на прикладном уровне на клиенты будет предоставляться доступ к данным ReFS такой же, как к данным NTFS. Но нельзя забывать о том, что NTFS все еще является ведущей технологией в индустрии среди файловых систем для ПК." - Стивен Синофски.

 

   Итак, что же это такое - Resilient File System, новая файловая система для Windows ? Это файловая система создавалась для удовлетворения огромного количества требований наших клиентов, и нынешних, и будущих, связанных со всеми областями применения Windows .

 

Ключевыми целями ReFS являются:

  • Поддержка высокой степени совместимости с частью функций NTFS, которые являются наиболее востребованными, а также вывод из употребления других функций, не таких удобных, за счет сложности и размеров системы.
  • Проверка и автоматическое исправление ошибок данных. Данные могут повреждаться по многим причинам, следовательно, требуют проверки и, по возможности, автоматического исправления. Однако просто записывать метаданные поверх нельзя во избежание оборванных записей. Этот вопрос будет детально разобран далее.
  • Оптимизация под экстремальное масштабирование. Масштабируемые структуры должны использоваться во всех случаях. Не будем предполагать, что алгоритмы проверки диска, например, могут масштабироваться под размер всей файловой системы.
  • Всегда держать файловую систему включенной. Подразумевается, что в случае повреждения, будет выгодно изолировать неисправность и оставить доступ к остальной части тома. Это будет происходить одновременно с восстановлением как можно большего количества данных и без прекращения работы.
  • Предоставлять полную сквозную отказоустойчивую архитектуру при использовании в связке с функцией Storage Spaces («Пространства хранения»), которая была спроектирована и создана вместе с ReFS .

   ReFS имеет следующие ключевые характеристики (заметьте, что некоторые из этих характеристик обеспечиваются только в связке с функцией Storage Spaces):

  • Целостность метаданных при помощи контрольных сумм;
  • Возможность использования целостных потоков, обеспечивающих целостность пользовательских данных;
  • Копирование при записи (создание транзакционной модели при записи, обеспечивающее надежность обновлений дисков);
  • Большие размеры томов, файлов и каталогов;
  • Создание и управление файловой системой упрощается методом группировки и виртуализации ячеек хранения;
  • Для большей производительности используется распределение данных посредством управления полосой пропускания, создан резерв по отказоустойчивости  
  • В целях защиты от скрытых ошибок используется очистка диска ;
  • Тома устойчивы к повреждениям, предусмотрена опция «восстановления» тома с максимальной доступностью;
  • Общие пулы носителей для нескольких ПК, созданные с целью повысить равномерность нагрузки и отказоустойчивость.

   К тому же, ReFS будет использовать часть функций и семантику NTFS, включая шифрование BitLocker, списки управления доступом, журнал USN, сообщения об изменениях, символьные ссылки, точки соединения, точки подключения, точки повторной обработки, снимки томов, идентификаторы файлов, нежесткие блокировки.

   И, конечно же, данные в ReFS доступны через те же использующиеся для доступа к файлам на клиентах интерфейсы программирования приложений (API ), что используются в любых других операционных системах, имеющих доступ к нынешним томам NTFS

Ключевые атрибуты и функции проекта

   Атрибуты нашего проекта тесно связаны с нашими целями. Во время изучения этих атрибутов, следует учесть историю развития индустрии файловых систем, которые используются на сотнях миллионов устройств, от миникомпьютеров до крупнейших центров данных, от миниатюрных форматов хранения данных до наиболее крупных многошпиндельных, от твердотельных накопителей до самых больших дисков и систем хранения из всех существующих. В то же время, доступ к файловым системам Windows предоставляется повсеместно огромному спектру приложений и системного ПО. ReFS учитывает этот факт и берет его за основу. Мы не стали начинать с нуля, а переосмыслили систему NTFS в той её части, где это было разумно. Прежде всего, мы стоим на той же прагматичной позиции, которая требуется при создании крупной файловой системы - это нечто, с чем только корпорация Microsoft сталкивалась в таких масштабах.

Повторное использование кодов и совместимость

   Рассмотрим файловую систему API: для неё совместимость наиболее важна и наиболее сложна технически. Переписывание кода, который отвечает за выполнение семантики файловой системы, не предоставит в результате должного уровня совместимости, и внедряемые функции будут сильно зависеть от кода приложения, синхронизации вызовов и аппаратного обеспечения. Поэтому при создании ReFS мы повторно использовали код, отвечающий за выполнение семантики файловой системы Windows. Этот код определяет интерфейс файловой системы (чтение, запись, открытие, закрытие, уведомление об изменениях, и т.д.), поддерживает файл в памяти и состояние тома, усиливает безопасность, и поддерживает кэширование памяти и синхронизацию файлов данных. Повторное использование этого кода предоставляет надежность в вопросе совместимости с функциями NTFS, которые мы будем применять и в будущем.

   Помимо повторно используемой части, NTFS -версия основы кода использует вновь разработанный механизм с применением структур на дисках, таких как Основная таблица файлов (MFT ), для представления файлов и директорий. ReFS сочетает в себе повторно используемый код и совершенно новый механизм, в котором заключена значительная часть инноваций ReFS . Графически это выглядит так:

 

Что такое ReFS

 

Надежные и масштабируемые структуры на дисках

   Поддержку и управление структурами на дисках осуществляет механизм дискового хранения. Он раскрывает универсальный интерфейс «ключ-значение», с помощью которого уровень, расположенный выше, управляет файлами, каталогами и т.д. Для реализации механизма хранения используются только деревья B+. Фактически, мы применяем B+ деревья как единую общую дисковую структуру для представления всей информации на диске. Деревья можно внедрять внутри других деревьев (корень дочернего дерева хранится в строке родительского дерева). На диске деревья могут быть очень большими и многоуровневыми или компактными, имеющими небольшое количество ключей и внедренными в другую структуру. Этот факт обеспечивает максимальную масштабируемость вверх и вниз для всех аспектов файловой системы. Устройство по единой структуре значительно упрощает систему и уменьшает количество кода. Интерфейс нового механизма включает понятие «таблиц» - это счетный набор пар «ключ-значение». У большинства таблиц имеется уникальный идентификатор (идентификатор объекта), по которому на них можно ссылаться. Специальная таблица объектов индексирует все такие таблицы в системе.

   Теперь давайте посмотрим, как с помощью таблиц создаются абстракции общих файловых систем:

Что такое ReFS

   Как показано на диаграмме выше, каталоги представлены в виде таблиц. Каталоги могут эффективно масштабироваться до очень больших размеров, так как мы используем для реализации таблиц деревья B+. Файлы реализуются в виде таблиц, внедряемых внутри строки родительского каталога, который также является таблицей (представлен как метаданные файла на диаграмме выше). Строки в таблице метаданных файла представляют различные атрибуты файла. Расположение области данных файла представлено в виде встроенной потоковой таблицы, которая является таблицей сопоставлений смещений (или, как вариант, контрольных сумм). Это означает, что файлы и директории могут быть очень большими, что никак не повлияет на производительность. Всё это с излишком компенсирует ограничения, имеющиеся в NTFS.

   Как и ожидалось, другие глобальные структуры в файловой системе, такие как ACL(Списки управления доступом) представлены в виде таблиц, происходящих из таблицы объектов.

   Распределение всего места на диске осуществляется иерархическим распределителем, который представляет свободное пространство в виде таблиц свободных областей. С точки зрения масштабируемости существует три вида таких таблиц: большой, средний и малый распределитель. Они различаются степенью разбиения пространства, за которое они отвечают: например, средний распределитель управляет участками средней величины, выделенными большим распределителем. За счет этого достигается отличная масштабируемость алгоритмов распределения места на диске, удобство и естественность в распределении соответствующих метаданных для лучшей производительности. Корни этих распределителей так же, как корень таблицы объектов, доступны в хорошо известном месте на диске. Некоторые таблицы имеют частные распределители, что предотвращает конфликты и позволяет локализовать область распределения.

   В отличие таблиц метаданных глобальных систем, записи в таблицах объектов относятся к каталогам, поскольку файлы встроены в каталоги.

Стратегия надежного обновления диска

   Надежное и эффективное обновление диска является одним из самых важных и сложных аспектов проектирования файловой системы. Мы потратили множество времени на оценку различных подходов. Один из подходов, который мы рассмотрели и отвергли, заключался в создании файловой системы со структурой в виде журналов. Этот способ реализации не подходит для типа файловой системы общего назначения, которая требуется в Windows . В том, что касается обеспечения согласованности на диске, NTFS опирается на журнал транзакций. Этот подход на месте обновляет метаданные на диске и вместе с этим использует журнал на стороне, чтобы учитывать изменения, которые можно откатить в случае ошибок или сбоя питания. Одним из преимуществ этого подхода является сохранение метаданных на месте, что может быть выгодно для производительности при чтении. Главные минусами системы журналов состоят в том, что записи могут вестись неупорядочено, и, что более важно, обновление диска может повредить записанные ранее метаданные при сбое питания во время записи - эта проблема известна под названием "оборванная запись".

   Для максимальной надежности и предотвращения оборванных записей, мы выбрали подход «размещение при записи», при котором метаданные никогда не обновляются на месте, а записываются в другом месте атомарным образом. В каком-то смысле этот подход основан одном из старейших понятий – «механизм теневых страниц», который используется для надежного обновления структур на диске. Транзакции строятся на основе подхода «размещение при записи». Так как верхний уровень ReFS унаследован от NTFS, новая модель транзакций легко использует уже существующую логическую схему восстановления после ошибок, которая была проверена и стабилизирована во многих выпусках.

   ReFS располагает метаданные таким образом, чтобы обеспечить возможность комбинировать записи для соответствующих частей (например, выделение для потока, атрибуты файлов, имена файлов и страницы каталогов) с помощью меньшего числа более крупных операций ввода вывода, что просто замечательно как для дисковых, так и для флэш-решений. В то же время сохраняется должная степень непрерывности чтения. Схема иерархического расположения здесь интенсивно используется.

   Мы проводим важные тесты, в ходе которых питание системы отключается в тот момент, когда система работает с очень большой нагрузкой, а после включения все структуры проверяются на наличие ошибок. Эти тесты – главный критерий состоятельности подхода. Мы достигли беспрецедентного уровня надежности во время тестирования файловых систем Майкрософт. Мы верим, что это решение станет лидирующим в индустрии и удовлетворит основные задачи проектирования.

Отказоустойчивость при повреждении диска

   Как говорилось ранее, одной из важнейших задач проектирования для нас является выявление и исправление повреждений. Это не только обеспечивает целостность данных, но также улучшает доступность системы и интерактивное взаимодействие. Таким образом, все метаданные ReFS проверяются по контрольным суммам на уровне страницы дерева B +, а сами контрольные суммы сохраняются отдельно от страницы. Это позволит нам обнаружить все формы повреждений диска, включая потерянные или сохраненные не в том месте записи, а так же битовый распад (ухудшение состояния данных на носителе). К тому же, мы добавили возможность проверять по контрольным суммам также и содержимое файлов. Когда эта опция, известная как «целостные потоки» включена, ReFS всегда записывает изменения файлов в стороннем месте. Эта техника подхода «размещение при записи» даёт уверенность в том, что существовавшие ранее данные не будут потеряны при перезаписи. Обновление контрольных сумм происходит автоматически при записи данных, поэтому если во время записи происходит сбой данных, у нас всегда будет систематически доступная для проверки версия файла, и тем самым повреждения можно было бы выявлять принудительно.

   Мы уже писали о Storage Spaces несколько недель назад. ReFS и Storage Spaces разработаны так, чтобы взаимодополнять друг друга как два компонента единой системы хранения данных. Мы делаем пространства хранения доступными для NTFS (и клиентских ПК), поскольку это очень полезно; многоуровневая архитектура поддерживает этот подход со стороны клиента, в то время как мы адаптируем ReFS к использованию на клиентах, чтобы в итоге была возможность применять ReFS и на клиентах, и на серверах.

   Помимо улучшения производительности Storage Spaces защищают данные от частичных и полных сбоев диска за счет хранения копий на нескольких дисках. Во время сбоев при чтении Storage Spaces могут считывать копии, а при сбоях записи (даже при полной потере данных носителя при чтении/записи) имеется возможность "прозрачно" перераспределять данные. Зачастую сбой не имеет отношения к носителю, а происходит из-за повреждения данных, либо из-за потери данных или сохранения их не в том месте.

   Именно эти виды сбоев ReFS может обнаружить, используя контрольные суммы. Когда ReFS обнаруживает такой сбой, она связывается с Storage Spaces для того, чтобы считать все возможные копии данных, и выбирает нужную копию, основываясь на проверке контрольных сумм. После этого система отдает команду Storage Spaces о необходимости восстановления поврежденных копий на основе верных копий. Всё это происходит прозрачно с прикладной точки зрения. Если ReFS не работает с зеркальными пространствами хранения, значит, нет смысла в автоматическом восстановлении повреждений. В этом случае система просто запишет событие в журнал, отметив, что было выявлено повреждение, и если это были файловые данные, то чтение невозможно. О том, как это повлияет на метаданные, я расскажу позже.

   Контрольные суммы (64 бит) всегда включены для метаданных ReFS, и при условии, что том размещен на зеркальных Storage Spaces, включается также автоматическое исправление. Все целостные потоки (см. ниже) защищены тем же способом. Это создает сквозное решение с высокой степенью целостности для пользователя, благодаря которому относительно ненадежное хранилище можно сделать весьма надежным.

Целостные потоки

   Целостные потоки защищают содержимое файла от всех видов повреждений данных. Хотя эта характеристика имеет ценность для многих сценариев, в некоторых случаях она неприменима. К примеру, для некоторых приложений предпочтительнее аккуратное управление хранением файлов с определенной сортировкой файлов на диске. Поскольку целостные потоки перераспределяют блоки каждый раз, когда содержимое файла изменяется, компоновка файлов для этих приложений слишком непредсказуема. Системы баз данных являются ярким примером. Как правило, такие приложения самостоятельно ведут учёт контрольных сумм содержимого файлов и имеют возможность проверять и исправлять данные путём прямого взаимодействия с интерфейсами API Storage Spaces.

   Для таких случаев, где необходима определенная компоновка файлов, мы используем механизмы и интерфейсы API для управления на разных уровнях разбиения.

   На самом основном уровне целостность является атрибутом файла (FILE _ATTRIBUTE _INTEGRITY _STREAM ). Также это атрибут каталога. При его наличии в каталоге атрибут наследуется всеми файлами и каталогами, созданными внутри каталога. Удобнее будет использовать команду «format», чтобы указать это для корневого каталога тома во время форматирования. Если применить это к корню, действие распространится на каждый файл и каталог на томе. Например:

D:\>format /fs:refs /q /i:enable D:\>format /fs:refs /q /i:disable

   По умолчанию, когда переключатель /i не указан, выбираемое системой поведение зависит от того, находится ли этот том на зеркальном пространстве. На зеркальном пространстве целостность включена, так как мы ожидаем, что преимущества значительно превзойдут издержки. Приложения всегда могут отменить эту настройку для отдельных файлов.

Борьба с «битовым распадом»

   Как описывалось ранее, сочетание ReFS и Storage Spaces предоставляет высокую отказоустойчивость данных в случае повреждения диска или сбоя хранения. Сложнее выявить и преодолеть потери данных, связанные с «битовым распадом», когда необнаруженные вовремя повреждения редко читаемых частей диска интенсивно растут. К тому времени, как такие повреждения будут считаны и обнаружены, они могут уже затронуть копии, либо данные могут быть утрачены из-за прочих сбоев.

   Чтобы справиться с битовым распадом, мы добавили системную задачу, которая периодически очищает метаданные и данные целостных потоков на томе ReFS, находящемся на зеркальном пространстве хранения. Очистка происходит посредством считывания всех лишних копий и проверки их на правильность с помощью контрольных сумм ReFS . Копии с ошибками исправляются с помощью годных копий, если контрольные суммы не сходятся.

   Атрибут файла FILE _ATTRIBUTE _NO _SCRUB _DATA показывает, что программа очистки должна пропустить файл. Этот атрибут полезен для приложений, которые сами ведут учёт информации о целостности, когда разработчик приложения хочет получить более жесткий контроль над тем, когда и как эти файлы очищаются.

   Инструмент командной строки Integrity .exe является мощным средством для управления политикой целостности и очистки.

Когда ничего не помогло... наличие непрерывного тома

   Мы ожидаем, что многие пользователи будут использовать ReFS в связке с зеркальными пространствами хранения, и в этом случае повреждения будут автоматически обнаруживаться и исправляться. Но бывают случаи, пусть и довольно редкие, когда может быть поврежден даже том на зеркальном пространстве – например, память неисправной системы может повредить данные, которые затем могут оказаться на диске и повредить избыточные копии. Кроме того, многие клиенты могут решить не использовать зеркальные пространства хранения под ReFS . 

   Для таких случаев, когда том повреждается, ReFS выполняет «восстановление» - функцию, которая удаляет данные с пространства имен в рабочем томе. Цель этой функции – предотвратить неисправимые повреждения, которые могли бы оказать влияние на доступность верных данных. Например, если единственный файл в директории получил повреждение и не может быть автоматически восстановлен, ReFS удалит этот файл из пространства имен файловой системы, восстановив оставшуюся часть тома. Эта операция обычно выполняется меньше чем за секунду.

   Обычно файловая система не может открыть или удалить поврежденный файл, и администратор не может ничего предпринять. Но так как ReFS может восстанавливать поврежденные данные, администратор сможет восстановить этот файл из резервной копии, или при помощи приложения создать его заново, избежав необходимости выключить систему. Это ключевое нововведение обеспечивает уверенность в том, что нам больше не нужно проводить дорогостоящую процедуру проверки и исправления диска в автономном режиме, и предоставляет возможность развертывать обширные тома данных без риска долгих периодов автономной работы из-за повреждений.

Абсолютная совместимость со стеком хранения

   Мы знали, что наш проект должен отвечать требованиям максимальной гибкости и совместимости. Мы спроектировали ReFS так, чтобы она была совместима со стеком хранения точно так же, как любая другая файловая система, с целью максимизировать совместимость с другими уровнями вокруг неё. Например, система может легко использовать шифрование BitLocker, списки контроля доступа для безопасности, журнал USN, уведомления об изменениях, символьные ссылки, точки соединения, точки подключения, точки повторной обработки, снимки томов, файловые идентификаторы и нежесткие блоки. Мы ожидали, что большинство фильтров файловых систем смогут легко работать с ReFS с небольшими модификациями или без них. Наши тесты подтвердили ожидания; к примеру, мы смогли убедиться в функциональности существующего антивирусного решения Forefront . 

   Некоторые фильтры, зависящие от физического формата NTFS, потребуют более масштабных модификаций.  Мы запустили расширенную программу совместимости, с помощью которой мы тестируем наши файловые системы с антивирусным ПО сторонних производителей, резервными копиями и прочими подобными программами. Ту же самую процедуру мы проводим с ReFS  и будем работать с нашими ключевыми партнерами над решением обнаруженных проблем совместимости. Мы уже занимались этим ранее, работа над ReFS не является особым случаем.

   Примечателен также такой аспект, как гибкость. Хотя ReFS и пространства хранения хорошо работают вместе, они спроектированы для работы независимо друг от друга. Это придало максимальной гибкости при развертывании для обоих компонентов без лишних взаимных ограничений. Говоря иначе, можно получить готовое решение для хранения, включающее развертывание ReFS с базовым хранилищем для наших партнеров, подбирая соответствующий уровень надежности и производительности.

   С пространствами хранения пул носителей может быть разделен между несколькими компьютерами и виртуальные диски могут беспрепятственно перемещаться между ними, обеспечивая дополнительную отказоустойчивость. При созданной нами архитектуре система ReFS запросто может извлечь из этого пользу.

Использование

   Мы тестировали ReFS, используя сложный обширный набор десятков тысяч тестов, которые создавались для NTFS в течение более чем двух десятилетий. Эти тесты воссоздают условия развертывания в усложненном виде, с которыми, как мы думаем, система может столкнуться, например, при сбое питания, при проблемах, связанных с масштабируемостью и производительностью. Следовательно, можно сказать, что система ReFS готова к тестовому развертыванию в управляемой среде. Будучи первой версией крупной файловой системы, предположительно ReFS потребует осторожности в обращении. Мы не характеризуем ReFS для Windows 8 как бета-версию. Новая файловая система будет готова к выпуску, когда Windows 8 выйдет из стадии «бета», потому что нет ничего важнее, чем надежность данных. Итак, в отличие от любого другого аспекта системы, здесь необходим консервативный подход к первоначальному использованию и тестированию.

   Помня об этом, мы будем вводить ReFS, следуя поэтапному плану: в первую очередь как хранилищную систему для Windows Server, затем как хранилище для клиентов, и в итоге как загрузочный том. Такой же подход мы использовали и раньше, при выходе новых файловых систем.

   Изначально, основной задачей теста будет запуск ReFS в качестве файлового сервера. Полагаем, что клиенты выиграют от её использования в таком качестве, особенно при использовании зеркалирования Storage Spaces. Мы также планируем работать с нашими партнерами в сфере хранения с целью интеграции файловой системы ReFS с их решениями для хранения.

Вывод

   Наряду со Storage Spaces, ReFS формирует фундамент для обеспечения хранения данных на базе Windows на следующее десятилетие или больше. Мы считаем эту систему важным инновационным шагом на пути создания современных хранилищ. Storage Spaces и ReFS, оба компонента с самого начала проектировались с возможностью дальнейшего развития, и мы надеемся увидеть ReFS в качестве следующей файловой системы массового применения.

 

 

Суренда Верма (Surenda Verma),менеджер по разработке отдела хранения данных и файловых систем

Статья подготовлена по материалам Building the next generation file system for Windows: ReFS.

Ключевые теги: File Server, File System
alert Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь. Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

Печать

Добавление комментария

Ваше Имя:
Ваш E-Mail:
Введите два слова, показанных на изображении:
Популярное
  • Что такое ReFS
  • Windows Server 8 Beta
  • Ответы на вопросы по ReFS
  • Windows Server 8 Hyper-V Component Poster
  • Построение оптимизированного частного облака, используя ...

  • Комментарии
  • Антон
    Windows Server 8 Data Deduplication (1)

    Автор: Антон
    Тема: Windows Server 8 Data Deduplication

    Жаль, что CSV не поддерживаются. Там бы это было особенно актуально
  • root-user
    DHСP Failover Cluster (2)

    Автор: root-user
    Тема: DHСP Failover Cluster

    2 Тимур
    Да, конечно DHCP, это я что один раз неправильно написал, а затем копи\\паст...
    Спасибо за то, что указали на ошибки.
  • Тимур
    DHСP Failover Cluster (2)

    Автор: Тимур
    Тема: DHСP Failover Cluster

    Может быть речь идет о DHCP, а не о каком-то DCHP?
    И еще "и указываете, какой роль".

    Извиняюсь за въедливость, и спасибо за информацию.
  • Rostikspin
    Хранилище и постоянная доступность в Windows Server 8 (2)

    Автор: Rostikspin
    Тема: Хранилище и постоянная доступность в Windows Server 8

    А можете более подробно написать/рассказать о SMB 2.2 Multichannel
  • CesirraliaRic
    Хранилище и постоянная доступность в Windows Server 8 (2)

    Автор: CesirraliaRic
    Тема: Хранилище и постоянная доступность в Windows Server 8

    Да, довольно интересные фишки добавлены.
    Надеюсь, что сие чудо от мелкомягких оправдает мои надежды и ожидания

  •    
    Каталог@Mail.ru - каталог ресурсов интернет