Приветствую, дамы и господа!
Все, думаю, помнят про грабли №1 подсистемы SMB 2.0. Это выпадение винды в BSOD при получении специально сформированного пакета на 139 порт. Ну а я наткнулся на некие проблемы, которые, возможно, и фича, но описание в Интернет найти не смогли и, как следствие, потеряли кучу времени на решение. Подробности под катом.
У нас MS SQL Reporting Services выгружают раз в минуту некий отчет из корпоративной системы в CSV-файл, размером чуть меньше 400 байт, лежащий на файл-сервере. И есть самописанная программка, которая раз в 10 секунд читает этот файл и выводит цифры на большой экран. И все работало чудесно, пока в один прекрасный момент мы не заметили, что цифры не меняются. Начали расследование.
Сразу выяснилось, что Reporting Service в логах пишет, что файл уже кем-то используется. Возникло подозрение, что репортер пытается писать в тот момент, когда этот файл открывает программа показа. Хотя было непонятно, почему неделю все работало хорошо, а потом стало плохо.
Программа показа была переписана таким образом, чтобы файл открывался в режиме, когда прочие процессы могут иметь любой доступ к файлу. Не помогло.
Появилось подозрение, что это Delphi 7.0 не слишком корректно работает с Win7 и открывает файл «как-то не так». Тогда пришло решение — копировать файл в некий временный и открывать уже временный файл. При этом для копирования использовалась функция win 32 API — т.е. «по идее», там ошибок быть не должно. Но ситуация не изменилась.
Win-админ нашел тулзу для мониторинга состояния файла — открыт он или нет, а если открыт, то кем. Тулза показала, что действительно, после копирования файл еще длительное (субъективно больше секунды) оставался открытым. Опять пало подозрение на работу программы, написанной на старой Дельфи, под win7. И здесь последовали два последних теста, так сказать, «контрольные выстрелы». Я копировал файл FAR-ом и командой copy. Я думаю все понимают, сколько занимает копирование четырех сот байт на современных компах по гигабитной сети. И тут настало откровение — не смотря на то, что я говорил админу «Смотри» уже после того, как файл скопировался (ну не успевал я сказать быстрее), файл все равно был открыт еще длительное время после окончания копирования, даже при условии того, что копирование происходило штатными средствами.
Начали думать, от чего такое странное поведение. И вспомнили, что за три дня до этого наш файл-сервер начал «чудить». И на нем переставили ОС с Win 2003 SRV Storage Edition на Win SRV 2008 R2. Т.е., похоже, «собака порылась» где-то здесь. И в какой-то момент пришло просветление — ведь на Win 2008R2 используется SMB 2.0 Буквально в тот же день, чуть раньше, обратили внимание, что с SMB 2.0, вроде, стал работать быстрее, чем старый файловый сервер. Ну а дальше дело техники — отключение SMB 2.0 на клиенте и «мы в дамках», т.е. все стало работать по-старому.
Отсюда краткое резюме — SMB 2.0 файл закрывает не сразу, а по прошествии некого, достаточно длительного, времени. Почему и зачем — пока не знаю.
Все, думаю, помнят про грабли №1 подсистемы SMB 2.0. Это выпадение винды в BSOD при получении специально сформированного пакета на 139 порт. Ну а я наткнулся на некие проблемы, которые, возможно, и фича, но описание в Интернет найти не смогли и, как следствие, потеряли кучу времени на решение. Подробности под катом.
Преамбула (дано)
У нас MS SQL Reporting Services выгружают раз в минуту некий отчет из корпоративной системы в CSV-файл, размером чуть меньше 400 байт, лежащий на файл-сервере. И есть самописанная программка, которая раз в 10 секунд читает этот файл и выводит цифры на большой экран. И все работало чудесно, пока в один прекрасный момент мы не заметили, что цифры не меняются. Начали расследование.
Фабула (решение)
Сразу выяснилось, что Reporting Service в логах пишет, что файл уже кем-то используется. Возникло подозрение, что репортер пытается писать в тот момент, когда этот файл открывает программа показа. Хотя было непонятно, почему неделю все работало хорошо, а потом стало плохо.
Программа показа была переписана таким образом, чтобы файл открывался в режиме, когда прочие процессы могут иметь любой доступ к файлу. Не помогло.
Появилось подозрение, что это Delphi 7.0 не слишком корректно работает с Win7 и открывает файл «как-то не так». Тогда пришло решение — копировать файл в некий временный и открывать уже временный файл. При этом для копирования использовалась функция win 32 API — т.е. «по идее», там ошибок быть не должно. Но ситуация не изменилась.
Win-админ нашел тулзу для мониторинга состояния файла — открыт он или нет, а если открыт, то кем. Тулза показала, что действительно, после копирования файл еще длительное (субъективно больше секунды) оставался открытым. Опять пало подозрение на работу программы, написанной на старой Дельфи, под win7. И здесь последовали два последних теста, так сказать, «контрольные выстрелы». Я копировал файл FAR-ом и командой copy. Я думаю все понимают, сколько занимает копирование четырех сот байт на современных компах по гигабитной сети. И тут настало откровение — не смотря на то, что я говорил админу «Смотри» уже после того, как файл скопировался (ну не успевал я сказать быстрее), файл все равно был открыт еще длительное время после окончания копирования, даже при условии того, что копирование происходило штатными средствами.
Начали думать, от чего такое странное поведение. И вспомнили, что за три дня до этого наш файл-сервер начал «чудить». И на нем переставили ОС с Win 2003 SRV Storage Edition на Win SRV 2008 R2. Т.е., похоже, «собака порылась» где-то здесь. И в какой-то момент пришло просветление — ведь на Win 2008R2 используется SMB 2.0 Буквально в тот же день, чуть раньше, обратили внимание, что с SMB 2.0, вроде, стал работать быстрее, чем старый файловый сервер. Ну а дальше дело техники — отключение SMB 2.0 на клиенте и «мы в дамках», т.е. все стало работать по-старому.
Отсюда краткое резюме — SMB 2.0 файл закрывает не сразу, а по прошествии некого, достаточно длительного, времени. Почему и зачем — пока не знаю.