АртемЪ:
занятые частично кластера все равно остаются.
их не целесообразно занимать полностью - большие потери идут при перезаписях.
поэтому в обычных файловых системах с неполностью занятыми кластерами не пытаются бороться полным их изничтожением.
Только специфические append only системы такие как описанная выше система хранения фоток в Контакте - полностью избавлены от этой проблемы.
вы видимо начинающий девелопер, и еще не сталкивались ситуацией, когда "у меня все работает, а на сервере не хочет". ну или работаете над мелкими проектами, где процесс разворачивания на сервер вручную никого не удивляет.
для избежания таких проблем придумано куча техник.
одна из самых известных Docker - позволяет небольшими затратами ресурсов добиваться идентичности окружения.
в случае Win и MacOSX - приходится использовать виртуалки для эмуляции типичного сервера на базе Linux.
впрочем, некоторые люди не могут освоить слишком много сущностей и все что выходит за пределы их мозга называют - не нужно, у меня и так работает.
про терминалы - строго говоря, следовало бы написать шеллы, а не терминалы.
но думаю, что квалифицированному спецу понятно из контекста о чем идет речь.
Saboteur: ушел из компании - возможности остались у компании.
тебе инвестиции нужно найти.
если ты не звезда первой величины типа Павла Дурова (хотя у него и своего бабулеса полно, не факт что ему инвесторы нужны), это будет сложно.
Вопрос только в размере блока.
512 он байт, 4 килобайта или 64 килобайта.
В остальном все однотипно - под файл выделяется определенно количество блоков на диске.
Один и тот же блок не может быть использован разными файлами одновременно.
Из-за этого происходит потеря места. Ведь нет никаких гарантий, что размеры файлов строго кратны размерам блоков.
Некоторые файловые системы умудряются писать в блоки несколько файлов, занимая все свободное место. Но большинство файловых систем все же так не поступают.
Именно так работает большинство известных файловых систем.
Это не так.
Дописывание очередного файла в конец свободного блока данных, без пропусков - это свойство отдельных ФС. Это исключение, а вовсе не правило. Правилом для большинства ФС является использование блока не полностью.
ВКонтакте реализована нестандартная схема хранения медиа-файлов. Без этих узких мест файловых систем - без потери места и без необходимости поиска файла - достаточно знать смещение и размер файла чтобы отдать его пользователю, нет необходимости читать дерево каталогов. Правда, им пришлось из-за этого, видимо, отказаться от удаления.
Adamos: то есть вы по умолчанию считаете, что топикстартер "сам с усам" и все знает.
поэтому лишний раз ему подробнее рассказать и уточнить ньюансы использования малых дисков не нужно?
почему?
это его обидит что ли?
Какой смысл работать с движком, который ориентирован на российский/СНГ рынок? :)
Почему бы и нет.
У меня основной заказчик - это интернет-магазин, где идет жесткая интеграция вебсайта с внутренней системой учета на базе 1С.
Правда там не Битрикс, а заказное решение.
Я к тому пишу, что на рынке РФ можно делать деньги.
Упомянутый проект веду уже 10 лет.
Как не трудно догадаться - уже несколько автомобилей я с него купил.
А у Битрикса есть своя ниша.
Например, он лицензированный. Значит всяким гос. конторам доступен для использования.
Уверяю вас - государство хорошо оплачивает.
Про то, что львинная доля в гос. проектах уходит коррумпированным посредникам - это вранье. Я сталкивался за последние 15 лет с этим единожды.
Adamos: если чел не понимает какая ему нужна техника - то он не представляет и какие нужны объемы дисков и как с дисковым пространством следует обходиться. имхо.
dmfun:
Зависит не от размера файлов.
А от того какой остаток от деления их размера на размер блока ФС у большинства файлов.
А 4 млд. файлов по 100 килобайт - это вообще мимо, там будет пол-пентабайта - это вообще не один компьютер.
Подавляющее большинство людей, скажем, котиков когда качают из интернета (или голых девушек) - тупо все валят или на рабочий стол или там оставляют, куда скачало (по умолчанию это системный диск с профилем пользователя, каталог Download)
занятые частично кластера все равно остаются.
их не целесообразно занимать полностью - большие потери идут при перезаписях.
поэтому в обычных файловых системах с неполностью занятыми кластерами не пытаются бороться полным их изничтожением.
Только специфические append only системы такие как описанная выше система хранения фоток в Контакте - полностью избавлены от этой проблемы.