proNovell

Имеется в работе OES11sp2
Работает как файловый сервер.
Работает в двух режимах доступа к файлам
- NFS
- NSS на ext3.

NFS - смотрит на тот же каталог, где располагается том NSS.
Такая организация сделана для работы с совместными файлами двух групп пользователей с Window с клиентом Novell и на МАКах по NFS.

Работало без проблем до тех пор пока размер некоторых файлов не привысил 30-40Гб. Во время удаления(или перезаписи) жизнь замирает без явных признаков в чём проблема. Ни каких видимом затыков нет.
Поиск по инету дал плачевный результат. Проблема в ext3.
Попытка перевести на btrfs или xfs, которые доступны для версии SLES для OES11sp2 - показали положительный результат в плане удаления, переписи файлов, но .... но катастрофическое замедление файловых операций. HDparm показывает разницу в 2-3 раза.

Вопрос кто-то пробовал ставить ext4 на OES11 (при условии что в описании саказано что поддерживается только на чтение). Если работает - стабильно ли. Потеря информации - не допустима.
Или кто предложит другое решение для ext3 по удалению файлов. Конечно вариант по усечению файлов - не подходит.

Пардон муа, а что мешает сделать по-лЮдски? Том nss, на нём данные и зашарить их же по NFS?
Проблема исчезнет, nss - это родная fs для серверов novell, так что с этой стороны тоже проблемы не будет.

Ковалев Артем писал(а):Пардон муа, а что мешает сделать по-лЮдски? Том nss, на нём данные и зашарить их же по NFS?
Проблема исчезнет, nss - это родная fs для серверов novell, так что с этой стороны тоже проблемы не будет.

Так и было задумано. И были проблемы с доступом к файлам. Перешили на то что сейчас работает - ни одной проблемы за пару лет, кроме озвученных и выявленных в последнее время.

NSS на ext3

Простите, я не понял смысла этой фразы. Это же альтернативные файловые системы - либо NSS ("родная" для OES), либо ext3 ("родная" для SLES). Или же это опечатка? Но тогда куда "смотрит" заэкспортированный по NFS каталог?

Насчёт NFS не пробовал, но одновременная работа NCP и CIFS на томе NSS идёт вполне нормально (включая поддержку технологии DST для теневых томов и межпротокольные блокировки файлов).

Константин Ошмян писал(а):

NSS на ext3

Простите, я не понял смысла этой фразы. Это же альтернативные файловые системы - либо NSS ("родная" для OES), либо ext3 ("родная" для SLES). Или же это опечатка? Но тогда куда "смотрит" заэкспортированный по NFS каталог?

Насчёт NFS не пробовал, но одновременная работа NCP и CIFS на томе NSS идёт вполне нормально (включая поддержку технологии DST для теневых томов и межпротокольные блокировки файлов).

Будем точны в определениях, не NSS на ext3, а NCP Volumes on Linux File Systems. Так пишут точно в документации. Обозвать этот режим NCP-шарой, как-то "вера не позволяет".

В качестве предложения в порядке обсуждения:

1. Не пробовали связку DSfW+Samba? Не нужен Novell Client, маки (если умеют SMB) - так же избавятся от NFS
2. Для маков есть Kanaka (аналог Novell Client). Рассматривали, не рассматривали?

Как по мне - реализованная схемы выглядит уж дюже сурово. Можно упростить - я бы остановился на DSfW. Samba не мерял, разница же между NCP+NSS и SMB+NSS вполне приличная (минимум 1 Мб/с в 100 Mbit FDX).

Правда, что-то наши яйцеголовые наворотили с Novell CIFS в OES2015 - регулярно отваливаются сеансы с записью в лог про Duplicate session. Собрал информацию, разбираются.

В OES11SP2 DSfW и Novell CIFS работают хорошо, проверено.

Может быть небольшое отклонение от темы, но... В силу определенного стечения обстоятельств смотрел я недавно в сторону PostgreSQL. И попутно наткнулся на следующее интересное сообщение относительно ext4:
http://www.postgresql.org/message-id/56 ... adrant.com И как-то неуютно мне сразу стало после прочтения этого сообщения:(

Andrey Karyagin писал(а):Может быть небольшое отклонение от темы, но... В силу определенного стечения обстоятельств смотрел я недавно в сторону PostgreSQL. И попутно наткнулся на следующее интересное сообщение относительно ext4:
http://www.postgresql.org/message-id/56 ... adrant.com И как-то неуютно мне сразу стало после прочтения этого сообщения:(

Обилие и разнообразие файловых систем под Linux ранее удивляло, а сейчас пугает.
Одно то что Novell в SLES упорно поддерживает 10 лет ReaiserFS, при том что проект больше мёртв, чем жив.
Проблемы возникающие с файловыми системами на Linux по прошествии нескольких лет эксплуатации у многих энтузиастов не решаются.
Так слово дефрагментация давно забытое, но живо хотя многие утверждают, что Linux этого не может быть.
Ставка на BtrFS многих вендоров тоже удивительно. Для данной ФС до сих пор нет чинилки при возможных краш системы. Да и грузит BtrFS систему не по детски.

Почему SuSE упорно обходит EXT4, из Вашего сообщения - проливает свет. Но почему Google выбирает EXT4 - не ясно.
Вот так и живём, как в сказке на лево пойдешь - систему убьёшь, на право пойдёшь от пользователей огребёшь, а прямо пойдешь - виндoс найдёшь.

P.S. А Postgres смотрели не в плане 1С.?

...Так слово дефрагментация давно забытое, но живо хотя многие утверждают, что Linux этого не может быть.
JFS от щедрот компании IBM якобы действительно не страдает фрагментацией:) См. также декабрьский номер журнала LinuxFormat, стр.24-29.

...Почему SuSE упорно обходит EXT4, из Вашего сообщения - проливает свет. Но почему Google выбирает EXT4 - не ясно.
Аналогичным образом Oracle Enterprise Linux и прочие производные от Red Hat по умолчанию продвигают XFS.

...Вот так и живём, как в сказке на лево пойдешь - систему убьёшь, на право пойдёшь от пользователей огребёшь, а прямо пойдешь - виндoс найдёшь.
Да уж. NSS на платформе NW6.5 по-прежнему рулит:)

P.S. А Postgres смотрели не в плане 1С.?
Нет, но могу дать ссылку на дружественную компанию, где всегда рады помочь: http://www.postgrespro.ru/products/1c_build

Andrey Karyagin писал(а):.....наткнулся на следующее интересное сообщение относительно ext4:
....

Причём что грустно статья так же относится и к ext3. Похоже вся логика журналов систем ext подвержена этой ошибке. Сам на это натыкался - терял данные на ext3.