Средство для тестирования файлового сервера

Средство для тестирования файлового сервера

Требуется протестировать работу файлового сервера: операции записи, удаления, копирования, перемещения и т.д. Есть ли средство для автоматизации подобного тестирования?

Есть файловый сервер, который, похоже, "глючит": время от времени возникают ошибки, но при повторе операции они не воспроизводятся.

Сергей Слесарев SSlesarev@mail.ru +7 (095) 517-5000

#2 Clauster
  • ФИО: Худобородов Валерий
  • Город: Espoo
#3 Green
  • ФИО: Гринкевич Сергей
  • Город: Москва

Требуется протестировать работу файлового сервера: операции записи, удаления, копирования, перемещения и т.д.Есть ли средство для автоматизации подобного тестирования?

Есть файловый сервер, который, похоже, "глючит": время от времени возникают ошибки, но при повторе операции они не воспроизводятся.

для постановки диагноза нужны симптомы.В Вашем описании их нет.

#4 Гость_Guest_artem_*_*
  • Guests

Сергей создал эту ветку по моей просьбе.

Задача и симптомы проблемы:

Есть проблема с новым файл сервером - наше приложение периодически не может создать / удалить фолдеры на нем. Кроме того, периодически (очень редко) оно впадает в необъяснимое состояние, как будто сервер говорит ему что файл записан, но на самом деле файл не меняется. Возможно это связано с залочиванием или кэшированием. Приложение представляет из себя вычислительный кластер из 35 компьютеров, частота ошибки - один - два раза в день. В день пишется около 200 тысяч файлов. Общий дневной объем около 250 ГБ.

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

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

Хочеся воспользоваться более - менее стандартным и продвинутым средством для диагностики проблем. Это поможет убедить ЙТ в том что проблемы есть. Простенький скрипт для проверки некоторых операций уже написан и выявил некоторые базовые проблемы.

#5 Dmitry_NJ
  • ФИО: Дмитрий Шевченко
  • Город: New Jersey, USA
#6 Green
  • ФИО: Гринкевич Сергей
  • Город: Москва

Сергей создал эту ветку по моей просьбе.

Задача и симптомы проблемы:

Есть проблема с новым файл сервером - наше приложение периодически не может создать / удалить фолдеры на нем. Кроме того, периодически (очень редко) оно впадает в необъяснимое состояние, как будто сервер говорит ему что файл записан, но на самом деле файл не меняется. Возможно это связано с залочиванием или кэшированием. Приложение представляет из себя вычислительный кластер из 35 компьютеров, частота ошибки - один - два раза в день. В день пишется около 200 тысяч файлов. Общий дневной объем около 250 ГБ.

Про новый файлсервер мне известно только следующее: это линукс машина с самбой, размер дискового массива 2 Террабайта. Мы пишем туда файлы через виндовс шаринг.Артем

Артем,все таки нужно стараться быть более конкретным. Вы ведь тестировщик. Как бы Вы описывали эту проблему в баг-трекинговой системе? Надеюсь, что более подробно.

Мне не совсем понытно, что означает писать файлы на Линукс машину через виндойс шаринг. Ну, да это детали.

Причина невозможности удаления файлов и папок может быть несколько (на ум пока пришли только две): занятость файла/папки, отсутствие прав.

Если процесс идет нормально и условия создания/чтения/удаления файлов/папок не изменяются, то отсутствие прав отпадает.

В случае занятости файла/папки, так же возможны варианты.

1. система пытается удалить файл раньше чем закончилась запись (то же относится и к папке, если такая ситуация складывается с файлом из этой папки). Решение - проверять на чтение: если файл открывается на чтение, значит запись окончена и можно файл удалить.

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

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

Кеширование не может быть причиной залочивания файла/папки (по крайне мере я про такое не слышал). Кеширование - это операция сохранения в оперативной памяти копии данных, для обеспечения более быстрого формирования ответа (по сравнению с чтением данных с диска). Наглядный пример (хоть немного и не про файлы), у поисковых систем есть свой кеш в который сохраняются результаты последнего обхода "поискового паука". И этот кеш активно используется для формирования ответов на запросы, например у Google-а. Иногда возникают ситуации, что страницы уже удалены с серверов, но их можно получить из кеша поисковика.

📎📎📎📎📎📎📎📎📎📎