[NFS] часто бывает ошибка staled file handler
Ты не указал какая операционная система на NFS сервере, и какая на NFS клиенте. Это важно.
Кстати ты еще не указал где возникает эта самая ошибка.
нфс сервер не в курсе, но уверен, что это солярка.
нфс клиентов я описал уже- это линукс и солярка.
насчет "где возникает эта ошибка" очень тяжело понять, что ты хочешь знать.
есть станция1 и станция2..станция-n, которая запускает екзешники и те пишут в один и тот же файл.
на станции1 возникают проблемы stale handler при чтении этого файла.
нфс клиентов я описал уже- это линукс и солярка.
насчет "где возникает эта ошибка" очень тяжело понять, что ты хочешь знать.
есть станция1 и станция2..станция-n, которая запускает екзешники и те пишут в один и тот же файл.
на станции1 возникают проблемы stale handler при чтении этого файла.
> насчет "где возникает эта ошибка" очень тяжело понять, что ты хочешь знать.
Ну что здесь сложного? Тебе MessageBox вылазит с этой ошибкой? Или может ядро её печатает и она оказывается в /var/log/messages? Или может системный вызов возвращает ошибку, и номер errno говорит о этой ошибке? Или может быть ошибка возвращается из плюсовой библиотеки?
"Когда я запускаю программу, то происходит ошибка XXX" - вот это совсем не понятно.
Ну что здесь сложного? Тебе MessageBox вылазит с этой ошибкой? Или может ядро её печатает и она оказывается в /var/log/messages? Или может системный вызов возвращает ошибку, и номер errno говорит о этой ошибке? Или может быть ошибка возвращается из плюсовой библиотеки?
"Когда я запускаю программу, то происходит ошибка XXX" - вот это совсем не понятно.
только stalled file handle
на линуксе обычно означает, что примонтированная система отвалилась от сервера. проверь, есть ли PL, если есть - то чинить сеть и можно попробовать перевестись временно на NFS по TCP.
на линуксе обычно означает, что примонтированная система отвалилась от сервера. проверь, есть ли PL, если есть - то чинить сеть и можно попробовать перевестись временно на NFS по TCP.
Такая фигня возникает, когда компьютер долгое время был вне сети. В результате NFS отваливается полностью и даже перезапуски соответствующих сервисов не помогают. Мало того, перезагрузиться тоже нормально нельзя, поскольку NFS каталоги не хотят отмаунтиваться. С этим можно как-то бороться?
я не админ, а глупый юзер
сам понимаешь, как докладывают юзеры об ошибках
эта ошибка выдается в двух абсолютно разных местах:
1) при выполнении bash-script типа:
echo 1 > file.txt
где file.txt был создан с одной станции, а баш запустился на другой.
2) в Tcl, когда я пытаюсь сделать "seek $g [tell $g]"
где $g дескриптор на давно открытый файл, который дописывается с разных станций.
за вариант про ПЛ спасибо. самая здравая мысль тут.
то есть если у меня есть дескриптор на давно открытый файл и возникло ПЛ в сети (почему бы и не возникнуть за долгое время?) то может образоваться недоделанность этого файла? и тогда stalled?
собственно ошибка не частая ведь, но критическая...после ее возникновения дескриптор в tcl никогда не починится ;(
есть смысл сделать по TCP ? то есть у нас по удп что ли происходит сейчас? что улучшится\ухудшится при таком маневре?
сам понимаешь, как докладывают юзеры об ошибках
эта ошибка выдается в двух абсолютно разных местах:
1) при выполнении bash-script типа:
echo 1 > file.txt
где file.txt был создан с одной станции, а баш запустился на другой.
2) в Tcl, когда я пытаюсь сделать "seek $g [tell $g]"
где $g дескриптор на давно открытый файл, который дописывается с разных станций.
за вариант про ПЛ спасибо. самая здравая мысль тут.
то есть если у меня есть дескриптор на давно открытый файл и возникло ПЛ в сети (почему бы и не возникнуть за долгое время?) то может образоваться недоделанность этого файла? и тогда stalled?
собственно ошибка не частая ведь, но критическая...после ее возникновения дескриптор в tcl никогда не починится ;(
есть смысл сделать по TCP ? то есть у нас по удп что ли происходит сейчас? что улучшится\ухудшится при таком маневре?
stalled - это означает, что NFS уже отвалился, и дальше ты будешь висеть ждать его возвращения, пока он не появится назад (т.к. файловая система примонтирована с опцией hard, что by default, и что вообще говоря правильно). что при этом произошло с файлом - зависит от того, когда именно он отвалился, но если он вернется таки назад, а вероятность этого есть, то с файлом будет все 100%-ок. Если очень нужно убить процессы, которые из-за NFS подвисли, то обычно помогает такая последовательность: umount -f на твой nfs, потом kill -9 на процессы. через некоторое время умирают.
переход на tcp c udp даст меньше глюков, если они были вызваны хреновой сетью, но немного уменьшит скорость работы файловой системы.
переход на tcp c udp даст меньше глюков, если они были вызваны хреновой сетью, но немного уменьшит скорость работы файловой системы.
у меня ничего не зависает и ничего не отваливается - у меня выскакивают ошибки.
файловая система работает нормально за исключением, возможно, маленьких лагов.
никаких умаунтов я делать не могу, да и не требуется.
у меня дескриптор портится по ходу почему-то. а с файлом все ок всегда.
попробую на тцп уломать админа.
посмотрим на результаты.
файловая система работает нормально за исключением, возможно, маленьких лагов.
никаких умаунтов я делать не могу, да и не требуется.
у меня дескриптор портится по ходу почему-то. а с файлом все ок всегда.
попробую на тцп уломать админа.
посмотрим на результаты.
"переход на tcp c udp даст меньше глюков"
за счет чего?
во время лага запрос будет ждать, когда этот лаг закончится и он получит то, что требует?
все же мне кажется проблема в другом....в нфс есть понятие синхронизации. возможно с двух станций одновременно идет запись и чтение. и нфс не в состоянии дать читателю то, что записалось, ибо нужно все синхронизировать сначала...
так что лаги могут быть не при чем.
за счет чего?
во время лага запрос будет ждать, когда этот лаг закончится и он получит то, что требует?
все же мне кажется проблема в другом....в нфс есть понятие синхронизации. возможно с двух станций одновременно идет запись и чтение. и нфс не в состоянии дать читателю то, что записалось, ибо нужно все синхронизировать сначала...
так что лаги могут быть не при чем.
короче, мой тебе совет: почитай документацию. все объяснять лень, а там это описано.
спасибо, я уж как-нить обойдусь.
если не способны объяснить-значит проблема нетривиальная, значит оно глючить и должно.
если не способны объяснить-значит проблема нетривиальная, значит оно глючить и должно.
пиздец, о каком объяснении может идти речь если даже
нфс сервер не в курсе, но уверен, что это солярка.у тебя есть рут на сервере? можешь показать диагностику с сервера?
Наши админы даже слышать не хотят про nfs в продакшене...
спасибо, я уж как-нить обойдусь.LOL
если не способны объяснить-значит проблема нетривиальная, значит оно глючить и должно
чувствуешь разницу между "не способны объяснить" и "лень"?
P.S. Как раньше было принято говорить в подобных случаях в ru.perl, зачитывание документации вслух с выражением - $50/час
Наши админы даже слышать не хотят про nfs в продакшене...А как ваши админы решают задачи, для которых предназначена nfs?
А для каких задач он предназначен?
Я имею ввиду, предназначен не по задумке, а де-факто.
Насколько я знаю, NFS отлично решает некоторые частные задачи администрирования - такие, в которых изменения идут из одного источника.
Насколько я знаю, NFS отлично решает некоторые частные задачи администрирования - такие, в которых изменения идут из одного источника.
> Наши админы даже слышать не хотят про nfs в продакшене...
Любое безаппеляционное заявление может на самом деле быть разумным и подкреплённым какими-то соображениями. Точно также оно может и не быть таковым.
Любое безаппеляционное заявление может на самом деле быть разумным и подкреплённым какими-то соображениями. Точно также оно может и не быть таковым.
такие, в которых изменения идут из одного источникаКоммитишь, собираешь пакет, ставишь его кругОм. Считается что другим способом изменения в продакшн не должны попадать. Разумеется это все "официально" и бывают исключения, но тем не менее.
Коммитишь, собираешь пакет, ставишь его кругОм. Считается что другим способом изменения в продакшн не должны попадать. Разумеется это все "официально" и бывают исключения, но тем не менее.Это если речь о исполняемых файлах, которые меняются только руками человека. А если речь о данных, которые изменяются по ходу процесса?
А если речь о данных, которые изменяются по ходу процессаscp, что тут еще придумаешь
что тут еще придумаешьсетевые файловые системы, например тот же NFS.
Типичный пример использования NFS в продакшн: у нас на работе есть некоторое кол-во рабочих мест (пара десятков все под Linux, все сидят в одном NIS-домене, и home всех пользователей лежит на NFS. В результате любой пользователь может сесть за любое рабочее место и получить более-менее свое родное окружение (более-менее - с точностью до установленного на машине нестандартного софта). Не тормозит, не виснет, но дальше 30-40 мест судя по всему масштабируется плохо. Альтернативные решения - например AFS. Сложнее в реализации и поддержке, но масштабируются до 5000 рабочих мест без проблем.
NFS в продакшн: у нас на работе есть некоторое кол-во рабочих местNFS среди _рабочих мест_ какой же это продакшн?
Там то конечно можно...продакшна что такое по-твоему продакшн?
Ну те сервера куда клиенты ходят. Под большой нагрузкой, где нужно решать задачу надежности. А какая с nfs надежность...
где нужно решать задачу надежности. А какая с nfs надежность...А какие методы решения задачи надёжности ты знаешь, которые нельзя применить к NFS?
если продакшном в применении к НФС считать раздачу файловой системы на много клиентов - то да, НФС сливает под большой нагрузкой.
А какие методы решения задачи надёжности ты знаешь, которые нельзя применить к NFS?Кеширование, зеркалирование томов между серверами, и много чего еще. Посмотри, например, возможности AFS
если продакшном в применении к НФС считать раздачу файловой системы на много клиентов - то да, НФС сливает под большой нагрузкой.Не NFS сливает, а некоторые её реализации.
>> А если речь о данных, которые изменяются по ходу процесса
> scp, что тут еще придумаешь
Это неприемлимо дорого. Количество scp транзакций в секунду наверное раз в 500 меньше, чем NFS. Не говоря уж о том, что это не масшатабируется - чем больше клиентов, тем больше scp транзакций на одно изменение.
> scp, что тут еще придумаешь
Это неприемлимо дорого. Количество scp транзакций в секунду наверное раз в 500 меньше, чем NFS. Не говоря уж о том, что это не масшатабируется - чем больше клиентов, тем больше scp транзакций на одно изменение.
чем больше клиентов, тем больше scp транзакцийВы чего то все не туда завернули. Имеется в виду, что есть десяток машин, которые работают под нагрузкой и на них на всех нужны одни и те же данные. Так вот эти данные нужно раскопировать через scp, вместо того чтобы расшарить их по nfs. Потому что если ляжет nfs сервер то ляжет всё, а этого нельзя допускать, а если делать 2 nfs сервера то какая уж разница, проще раскопировать везде.
PS. проблема nfs не в том, что она не держит нагрузку, а в том что она неадекватна по отношению к сетевым проблемам, в том числе физическим. Ну это мнение наших админом, к которому я тоже все больше склоняюсь.
А как обеспечивается безопасность такого решения? Невозможностью подключить свою машину или модифицировать стоящую? Или используется версия NFS с нормальной системой безопасности?
Вы чего то все не туда завернули. Имеется в виду, что есть десяток машин, которые работают под нагрузкой и на них на всех нужны одни и те же данные. Так вот этиданные нужно раскопировать через scp, вместо того чтобы расшарить их по nfs.Вот я и говорю, что когда будет 50 машин, а изменения будут происходить каждую секунду, то scp не будет успевать.
А как обеспечивается безопасность такого решения?Административными методами (не компьютерными).
сливает сливает, почему - уже написал: неадекватное (с точки зрения многих разработчиков прикладного ПО) поведение в случае малейшей нестабильности сети.
Оставить комментарий
Maurog
после установке на кластере из 8 линуксов (двухпроцессорные + гипертрединг на 4 процессора)возникли проблемы на нфс.
в нфс втянуты солярки и эти линуксы.
часто бывает ошибка staled file handler, ну или типа того.
я так понимаю, что файл, записанный с одного компа не успевает синхронизироваться при обращении с другого компа. при чем сколько не жди, а на другом хосте хендлер постоянно потеряный и ошибка выдается (к примеру если файл давно открыт на чтение, а с другого компа он аппендится)
короче траблы какие-то на этом ебанном нфс ;(
как эту проблему можно решить?