Как стать автором
Обновить

Комментарии 23

Простите за дилетантские вопросы:
Какой аппаратный интерфейс взаимодействия рассматриваемого дискового массива с клиентом? SCSI?
Какой логический протокол используются поверх физического интерфейса?
Если используется оригинальный логический протокол, доступна ли документация, описывающая его?

Интересует не API, а описание пакетов, бегающих поверх физического интерфейса.
Спасибо.

используется FC и соответсвенно SAN ( scsi over FC) насколько я понял
Спасибо. Именно это и хотел узнать.
Можно уточнить, этот алгоритм позволяет объявить несуществующими области, в которых есть данные?

Ведь при удалении файла он не затирается нулями, там лежат данные, изменяется только мета-информация. И если кто-то их объявляет пустыми «подсмотрев» запросы о записи информации об удалении файлов?

Рискованное телодвижение…
в чём риск? мне кажется, что логично, что удалённые данные не занимают место…
или вам больше нравится идея с виндовой корзиной?:)
В чём риск? Например в том, что у меня будет миррор (рейд) между таким томом и обычным. Ближайший ресинк что покажет? Правильно, «она утонула». Рейд рассыпется как карточный домик.

Идея соблазнительная, но реально это грязный-грязный хак, потому что вы произвольно меняете содержимое чужого блочного устройства. Это рвёт все абстракции, в основе которых неизменность данных на блочном устройстве хранения.

Я уже молчу про то, что ваша система сделает с какой-нибудь ext5, попутав чуток в атрибутах…
В чём риск? Например в том, что у меня будет миррор (рейд) между таким томом и обычным. Ближайший ресинк что покажет? Правильно, «она утонула». Рейд рассыпется как карточный домик.

*вы путаете то что реально пишется на диски и то что видно системе (клиенту стораджа)
вы же не пытаетесь сравнить в лоб архив(не распаковывая) и исходные файлы?

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

*с этого места поподробнее… «чужого» это как? доступ к дискам идет через те же мозги. и про«грязный хак» может не стоит сразу?

Это рвёт все абстракции, в основе которых неизменность данных на блочном устройстве хранения.

не понял у кого где начались абстракции… вы архиваторами никогда не пользовались?

Я уже молчу про то, что ваша система сделает с какой-нибудь ext5, попутав чуток в атрибутах…

не понял… думаю на уровне драйверов всё уже решено…
Я записал 5Гб на хранилище и на локальный диск. Удалил файл.

Потом сделал diff между локальным блочным устройством и разделом с хранилища. Что я увижу на месте 5Гб данных на хранилище? Те данные, которые были записаны или нули?

Насчёт абстракций, не обращайте внимание, это сисадмиское, менеджеров по продажам это обычно не тревожит.
Скорее всего, вы увидите нули.
Или получите какую-нибудь ошибку в стиле «попытка чтения незаписанной памяти» — если такие вообще предусмотрены всякими API.
То, что вы не увидите чужих, или бывших своих данных — определённо.
То есть рейд при проверке рассыпется. Понятно. Радостная новость.
а где был raid? я вот не спроста спрашивал…
В примере выше, где я показал опасность нарушения уровней абстракции. Я делаю миррор между хранилищем и локальным диском — и рейд рассыпается, потому что хранилище себе на уме и хочет подменять данные на блочном уровне, исходя из тараканов файловой системы.
моно вопрос?
если хранилище УЖЕ ПИШЕТ RAID-ом зачем вам такой хитрый механизм организации дискового пространства?
Я записал 5Гб на хранилище и на локальный диск.

они у вас в софтовом зеркале?

Удалил файл.

тоже хорошо.

Потом сделал diff между локальным блочным устройством и разделом с хранилища. Что я увижу на месте 5Гб данных на хранилище?

ещё раз: как у вас осуществляется копирование? вручную? Тогда представьте себе две флешки. вы скопировали и туда и туда… потом на одной стёрли… что будет?

Те данные, которые были записаны или нули?

нули. кстати такие же нули вы увидите и на исходном устройстве при стирании файла(однако данные будут на месте, тут вы правы), правда до тех пор, пока система «случайно» не затрёт кусками новых файлов

Насчёт абстракций, не обращайте внимание, это сисадмиское, менеджеров по продажам это обычно не тревожит.

вы менеджеров тут в связи с чем упомянули?

сувж.
если про меня — я не менеджер и уж тем более к продажам отношения не имею :)
mdadm -c /dev/md0 -n 2 --level 0 /dev/netapp0 /dev/sdb
mkfs /dev/md0
mount /dev/md0 /mnt
(создали файлы, удалили файлы)
mdadm --scan /dev/md0

Что мы увидим в результате?
я не линуксоид :)
Я вам сначала описал это человеческим языком, потом показал как это сделаю.

Вам всё равно не понятно.

Видимо, мне следует игноировать ваши реплики, так как с весьма высокой вероятностью вы просто плохо разбираетесь в вопросе.
выше уже всё описано многократно. видимо Вам стоит немножко отступить от того чему Вас учили :) не на всегда, но просто представьте что бывает чуть иначе.

про разбирательство в вопросе — я не эксперт ни по netapp-у ни по 3par-у :) во всяком случае пока. а уж игнорировать или нет -решайте сами.
кстати в моём «человеческом языке» нет слова «diff»
и на последок: речь в статье шла про НОРМАЛЬНОЕ функционирование. а не " выцарапывание стёртых данных"
Согласен с amarao. Что-то вы недоговариваете :)

Файловые системы не обнуляют содержимое удаленных блоков (за редкими исключениями, в основном диктуемыми всякими military-grade security решениями), они просто помечаются как неиспользуемые, и без агента на уровне OS и драйвера FS об удалении ничего не узнать.
Единственное исключение, теоретически претендующее на «кроссплатформенность» это как раз использование SCSI-команд, но пока оно не так распространено, как должно бы.

С «освобождением»содержащих нули блоков совсем непонятно. А если эти нули где-то внутри данных (сами данные — нули, ну вот так бывает)? А как на такое вмешательство в данные отреагирует программа?
1) см выше.
2) думаю согласитесь, что 16кб «нулей» можно описать занчительно более лаконично… да? а про программу — так при чтении и обращении они будут (видимо) восстановлены… для простоты примера — процедура архивации и разархивации.
Кстати, я давно лоббировал поддержку TRIM в blktap в Xen'е, чтобы как раз иметь возможность возвращать разреженность назад с поддержкой гостевой ОС.
И, да, речь в данном случае должна идти не столько о WRITE SAME, сколько, как мне кажется, о TRIM, команде, которая (в теории) должна передаваться системе хранения, указывая, что блоки в аргументе больше не используются хост-сервером.
Вот если они реализовали TRIM так, что его будет по какой-то причине будет использовать система, то это да, это круто. А мухлёж с подменой данных — это всего лишь мухлёж.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий