smilealex писал(а):prud писал(а):
То есть в Вашем случае вероятность того, что к одному файлу ломануться одновременно несколько желающих и имеющих право на запись, по Самбе и NFS нулевая? Или в режиме файлопомойки действительно разруливается нормально? (1С вообще отдельная песня - чуть голову не сломал, добиваясь приемлимого компромисса скорость-надежность).
нет.. вероятность
НЕ нулевая))... но к нулю стремится.. файло лочится первым захватившим его, остальным на чтение.. кстати, накатывалось ещё и ACL. в моём случае именно файлопомойка & PDC..
зы я уже ушёл с того места где поднимал на системных.. не могу точно сейчас проверить! в данный момент поднимаю на связке самба+лдап.. кстати интересен конфиг на котором разрулилась 1С.. точнее именно компромисс..
Ситуация - до десятка юзеров в семерочной дбф-ной сильно кастомной бухгалтерии, тачки от старых селеров с вын98 до п4 вынХР, для шары с базой:
strict locking = yes
oplocks = no
level2 oplocks = no
admin users = все бухи
еще глобально max open files покрутить можно, у меня - 30000
sysctl.conf(возможно что-то крутил для NFS, сейчас уже сходу не помню) :
kern.ipc.somaxconn=1023
net.inet.tcp.delayed_ack=0
net.local.stream.recvspace=65535
net.local.stream.sendspace=65535
net.inet.tcp.sendspace=65535
net.inet.tcp.recvspace=65535
kern.maxfiles=131071
kern.maxfilesperproc=32767
Всяческие бешенные процедуры обычно запускаются утром или вечером одним бухом, через это получается фактически монопольный режим - все очень быстро, а днем если чего задумается на минутку - у них всегда бумажная работа есть, при этом, тьфу-тьфу-тьфу, в отличие от давно стоявшей винды проблем с базой по некорректным выходам, косякам программизма и тп не припомню.
Вот зарплатную, тоже семерочную дбфную еще больше пиленую, базу не победил - чего там 1С-ники напридумывали уж не знаю (не моя епархия) - в немонопольном режиме скорость никакая при прочих равных с бухгалтерией - забил, там обычно одна расчетчица сидит.
Вот примерно примерно следующее из Гугля удержало меня пару-тройку лет назад, от экспериментов, осуществленных Вами:
Creating a Samba share which is equivalent to an NFS exported filesystem
on the same host:
This may not be fine. The problem is that Samba handles Windows-style file
locking internally whereas NFS uses UNIX-style file locking at the kernel
level. Problems can occurr if the same file is accessed by both SMB and NFS
at the same time. You can however prevent these problems from happening
through careful server configuration (allowing NFS and Samba to share the
same filesystem without any problems).
В данном случае careful server configuration понял как "сильно ограниченная".
Насколько понимаю, в приложении к 1С, у того же Этерсофта сетевая версия на NFS, без возможности шарить это по Самбе - значит это действительно очень сложно.