Re: Загрузился!!! - Неутешительные итоги



Posted by Дмитрий Москаленко on July 29, 1999 at 06:42:20:

In Reply to: Загрузился!!! posted by Владимир Антипин, Вологда on July 28, 1999 at 04:43:36:

: Сервер версии 3.05 загрузился после следующих действий:

: По совету Дмитрия Москаленко был увеличен размер свободного
: дискового пространства со 100 Мб до 250 Мб. После этого все заработало.
: Никаких экспериментов по поводу необходимого дискового пространства
: не проводилось, возможно хватило бы и меньшего.

: Спасибо, с уважением В. Антипин

Из произошедшей истории можно сделать ряд выводов:
1. Народ в массе своей с трудом оперирует такими понятиями, как «файловая система», «кластер» и т. п.
2. Файловая система FAT далека от совершенства.
Вот у уважаемого В. Антипина получилось, а что будет, если наступит, скажем, ноябрь? или сентябрь?
Не вдаваясь в подробности, предположим ситуацию:
- размер раздела диска, где лежат данные ФБП, составляет 1,2 Мб (продавцы компьютеров обычно не идут
на меньшую разбивку);
- зарегистрировано такое количество операций, вызывающих появление первичного документа, что в каталогах первичных документов образуется 2^14=16384 непустых файлов (документы+дескрипторы) - это вполне реально, я такую ситуацию наблюдал.
Сосчитаем размер кластера на диске.
Он считается приблизительно так:
РазмерКластера=ОкруглВверхДоБлижайшейСтепени2(ОбъемДискаВБайтах div 60000)
Для нашего примера:
ОбъемДискаВБайтах=1024*1024*1024*1,2=1288490188 байт
ОбъемДискаВБайтах div 60000=21474
Округлением получаем 32768 байт/кластер.
Практически в 99% случаев объем файлов с первичными документами и файлов-дескрипторов находится в пределах нескольких килобайт, поэтому, не теряя общности, можно считать, что каждый из имеющихся у нас 16384 файлов
занимает по 1 кластеру (меньшими порциями отводить дисковое пространство под файл просто невозможно).
Получили, что для хранения этой информации необходим объем дискового пространства 16384*32768=(2^14)*(2^15)=2^29=536870912 байта (512 Мб), т. е., фактически, полдиска
(при том, что фактический объем хранимых данных составляет 2 кб*16384=32768 кб или 32 Мб или даже меньше).
Хотя уже при создании раздела в 800 Мб удается снизить объем хранимых данных аж в 2 раза (т. к. кластер становится в 2 раза короче).
Использование файловой системы NTFS подобные проблемы если не снимает, то сводит к минимуму, но NTFS не поддерживается операционной системой Windows 95.
В какой-то мере проблему позволяет решить FAT32 (детище Windows 95), но такая файловая система не поддерживается ни одной из известных операционных систем, кроме Windows 95 (причем в '95 и в '98 FAT32 тоже разные и несовместимые), что повышает риск потери данных.

Возможные пути решения проблемы:
1. Ждать, пока появится операционная система, не столь пугающая пользователя, как Windows NT, и не столь близкая по организации к DOS, как Windows 95.
2. Пользователям - активно повышать компьютерную грамотность и организовывать свои рабочие места так, чтобы не возникало несуществующих барьеров (вроде неиспользованных "хвостов" кластеров).
3. Авторам ФБП - придумать какой-либо способ хранения первичных документов (в одном файле или даже внефайловый). Чем это чревато? Первичные документы уже нельзя будет распечатать, например, из Norton Commander; появится дополнительная индексирующая структура (которую придется хранить, обрабатывать и редактировать) - это дополнительный расход оперативной памяти и (или) замедление работы сервера, а также вероятность нежелательных перерывов работы из-за повреждений файла-хранилища, индексирующей структуры и связей между ними. Хранилище будет постоянно фрагментироваться (издержки любого индексного доступа) и будет нуждаться в дефрагментации. Тем более, что нет ни одного более-менее удачного примера реализации такой схемы хранения данных (ни в одной СУБД нет полноценной реализации работы с MEMO-полями).
Поэтому, как мне кажется, ДЛЯ ПОЛЬЗОВАТЕЛЕЙ НАИБОЛЕЕ ПРОДУКТИВЕН ПУТЬ №2 - ОВЛАДЕНИЕ ПРИЕМАМИ РАБОТЫ С КОМПЬЮТЕРОМ БОЛЕЕ СЛОЖНЫМИ, ЧЕМ ВВОД ТЕКСТА И РАСКЛАДЫВАНИЕ ПАСЬЯНСА.


Пpишедшие ответы: