proNovell

Проинсталил я как-то сервак, тома НСС, компрессию забыл включить. Перелил данные с бакапа, и только потом включил компрессию. Прочитав, что "оно само потом пожметься", в свободное время, благополучно забыл об этом.
А недавно глянул статистику, зажато всего 3-5% винта, это ж непорядок. Полез смотреть аттрибуты каталогов - есть "сжимать немедленно" - оно, включаю. Оказываеться включаеться только на эту папаку, а на подкаталоги не расспространяеться. Как мне заставить том ужаться весь, не бегать же по каталогам?

Кирилл Яновский писал(а):Проинсталил я как-то сервак, тома НСС, компрессию забыл включить.

Вот и не лезь к компрессии. Нет её и хорошо.
Забава для нищих.

Давай не будем затрагивать тему целесообразности, ок?
У меня там не данные НАСАи т.д., а куча студенческого/преподавательского хлама, лабы, курсовые и прочий офисный мусор, который жметься в разы... Так что надежность - не на 1-м месте, тем паче за многие годы слетало пару раз из-за экспериментов админов, а не из-за проблем с компрессией, да и при крахе пула тоже поднималось почти без потерь.
ну а по-существу ничего не подскажете?

Кирилл Яновский писал(а):Проинсталил я как-то сервак, тома НСС, компрессию забыл включить.

Разрешите, я встряну...
Стоимость дополнительного винчестера несравнимо мала со стоимостью избавления от геморроя в связи с компрессией.

PS.
Вы на локальной винде тоже компрессию используйте?
Вот лучше на рабочей станции включите. Так меньше народу вас пинать будет.

У меня на 6-ке компрессия для юзверей стоит несколько лет, я и не знал, что с ней бывают проблемы... У меня их не было... а это даже не проблема, а так, скорее незнание мной чего-то ...

Да, и на счет раб. станций дополню - тут сложнее - они очень разные по университету - от целеронов-300/32мб до п4 т.д., а сервак более-менее, так что приучил файло хранить на нем.

А чем проблема-то Кто огреб проблем с СуперСтораджем/Дублеспейсом/Стакером - тот никогда больше не станет Иметь дело с этой технологией...

Баловался стекером... было дело, еще на 286/дос... суперская вещь, когда винта не хватает. Слетел только 1 раз, из-за меня, доэкспериментировался. У соседей по институту были слеты или из-за кривых рук или из-за глюков железа (мать, винт, шлейф).
Потом, правда, винты пошли побольше, необходимость отпала..

Я так понял, мне никто не ответит - как включить аттрибут "сжимать немедленно" для всего дерева каталогов... ???

Утилита FSUPDATE из набора Бэрда.

Чего вы все на компрессию бочку катите?
У меня много лет она работала на разных версиях NW без проблем (это вам не первые варианты под ДОС и первые винды). А то что кто-то пытается потом впихнуть данные на диск, на котором уже и после компрессии места нет, или сделать поиск подстроки во всех асболютно файлах на сервере, так это его проблемы! Скорость распаковки существенно выше компрессии и никаких тормозов из-за этого при чтении файла на нормальной дисковой подсистеме быть не долно по определению, да и проц в этом случае никогда не был узким местом.
Слова о том, что "у меня диск IDE" меня не интересуют - даже IDE может нормально работать при правильных драйверах и соответсвующей нагрузке.
А по сути вопроса - только пересоздание тома (так, по крайней мере, до сих пор было).

Павел Гарбар писал(а):Чего вы все на компрессию бочку катите?

Незнаю как там насчет NSS (до сих пор не надо было это мне), но компрессия на TFS - must die ОДНОЗНАЧНО! Был случай с платформой Intel7501HG2, с отличной дисковой подсистемой (2-хканальный SCSI RAID, точнее не помню), и недоделаными руками админа, неудосужившимся при создании томов снять компрессию с них... И на всем этом база данных PSQL, каждый файл до 0,5-1Gb, файлов штук 250... сервак перегружали тупо по 3 раза в неделю!... Этож с ума сойти можно Компрессию я им не снял, проблематично было пересоздать тома, но все решилось даже простым запретом сжатия файлов. Сейчас раз в пару месяцов перегружаются, чаще из-за глюков PSQL...

Павел Гарбар писал(а):А по сути вопроса - только пересоздание тома (так, по крайней мере, до сих пор было).

Собственно, это и есть суть. Выключение компрессии на томе делается через его пересоздание с выключенным атрибутом компрессии.

Включение компрессии на традиционном томе делается двумя путями:
1) Load NWCONFIG | STANDARD DISK OPTIONS | NETWARE VOLUME OPTIONS | <SELECT VOLUME>. FILE COMPRESSION - ON.
2) Load MONITOR | SERVER PARAMETERS | FILE SYSTEM. ENABLE FILE COMPRESSION - ON.

Что касается NSS, то тут вот какое дело:

NSS uses the same algorithm as TFS does, only the smallest filesize that is eligible to be compressed is different.
On TFS, this number is 512 + 1 bytes, on NW60 NSS, it is 4092 + 1 bytes, and on NW65 NSS, it is 8192 + 1 bytes.

This is done because:
1. NSS's smallest block size is 4K, while TFS does sub-allocation to 512 bytes units.
On NSS volumes, compression won't save diskspace if the file is smaller than 4K.
2. NSS compressed files also use one block for indirect file maps.
This ensures a compressed file won't save any disk space if its filesize is between 4K and 8K (at least one block for compressed data and one block for file map).

Following NSS compression commands are very useful :
- /(No)BGCompression Start/Stop background Compression. (Stop BGCompression will stop and clear all the enqueued background compression request.)
- /Compression=<VOL> Enable File Compression on the given volumes. (It can't be turned off once it's enabled)
- StopNormalCompression Stop normal Compression. (It will stop and clear all the enqueued normal compression request.)
- CompScreen Start the NSS Compression Statistics Screen.

Собственно, проблем найти это все в KB не составляет. Там еще масса документов по этой теме...
http://support.novell.com/cgi-bin/searc ... 092181.htm

Ну вообщем-то это все я проштудировал когда-то.
Вопрос состоял немного не в этом.
Я спрашивал, почему аттрибут на каталоге "сжимать немедленно" нельзя назначить рекурсивно, вглубь, на все подкаталоги? он применяеться только на файло, лежащее непосредственно в нем, а на подкаталоги - фигушки...
Нашел в Адремовской сервер-менеджере опцию - стоя на каталоге можно назначить этот аттрибут - сервак начинает лопатить, судя по всему все внутренние подкаталоги, но потом бросает это занятие, и, судя по nss /compscreen зажимаеться немножко файлов и опять стоим, чего-то ждем...

...или сделать поиск подстроки во всех асболютно файлах на сервере, так это его проблемы!

Ну очень интересная трактовка!
А я то всегда думал, что это наша, админская, проблема....
Или у кого-то неработопригодный сервер - это проблема пользователя? Класс! хАчууу в такую контору!

А во вторых - есть предложение разделить "хорошо работае" вообще и "хорошо работае в реальной сети".
К сожалению, должен солидаризироваться с коллегой SlyFox'ом : работать в реальной сети с компрессией невозможно. И (вы будете смеяться!) именно потому, что в самый неподходящий момент пара-тройка прямоходящих запускают этот самый глобальный поиск по всему диску.... ну потеряли они документ, а он может быть в катлоге одного их 3х отделов... вот всем скопом они и навалились на поиск... и что? и сервер ML370x3GGх4GB с системой на базе SCSI HP-5300 встает колом с утилизацией до 40%... и работа встает тоже...
С тех пор я не люблю компресиию...

типа нравится/не нравится, НО:

1. Компрессия работает и нормально, причем как на TFS так и на NSS (проверено, начиная с версии 4.11)
2. Чтобы компрессия нормально работала, надо чтобы было свободное место на томе, включая учащенный пурген при уменьшении этого свободного места
3. Не думаю, что правильно ожидать хорошей скорости при хранении на таком томе файлов по 0,5+Гб и туда-сюда их паковать/распаковывать
4. Сугубо ИМХО имеет смысл делать компрессию для файлов на томах со случайным доступом (т.е. типа домашних каталогов)
5. Компрессия хорошо помогает тогда, когда некоторые файлы требуется хранить, но не очень уж часто к ним обращаться
6. Компрессия помогает таки при необходимости сэкономить дисковое пространство и при этом не заморачиваться с удалением редко используемых данных на оффлайновые носители

... по-моему некорректно сравнивать продукты для сжатия дисков локальных станций и серверов (даже с учетом того что на станциях дисковое пространство подчас бывает объемнее)...

2 SlyFox - про файлы - 0,5-1 ГБ. Вообще не вопрос! Они НЕ СЖИМАЮТСЯ! Топчутся файлы размером до 256 МБ... Так что чистая пурга на компрессию! У меня дизайнеры свои гигабайтные картинки хранили на компрессуемых томах на NW 4.11 без проблем с производительностью - проблемы были только с местом регулярно :-)
Николаю Музалеву. Поиск по подстроке - да в общем тоже не проблема - открытые, но не измененные файлы на диск обратно не пишутся и так и остаются сжатыми. Другое дело что сервер в этот момент выходит из устоявшегося режима работы и переходит почти в пиковый, при этом все содержимое кэша практически обновляется и запросы уже напрямую уходят в дисковую подсистему. Если она плохая - производительность ессесно сильно падает, а если хорошая, то сетевой интерфейс по идее должен стать более узким местом чем скорость у дисков.
Проблема же с пользователями в том, что они не умеют и не хотят уточнить свой запрос, что существенно бы сузило круг поиска. Например, не искать по всему тому во всех файлах слово "заказчик" (и ему насыпет несколько тысяч файлов и он плюнет на результаты этого поиска), а каталоге договоров за этот год искать "ЗАО "Любимая контора"" в файлах *.doc... Есть же разница? И чья это проблема? Его же, пользователя, потому что так он все же найдет нужный себе файл, а не будет просто так во время обеденного перерыва сервер тренировать. Так что компрессия и тут не проблема, а наоборот - облегчение, так как с самого диска данных читать надо меньше, а процесс распаковки менее требователен к вычислительной мощности проца, чем сжатие (ее поэтому и делают по ночам).
Ни одного реального аргумента против компрессии на серверах NetWare я до сих пор не слышал. Другое дело, что диски стале значительно больше и дешевле, а форматы многих файлов и так уже сжатые, что сводит на нет значение компресии при хранении файлов на дисках сервера.