+  HandyCache форум
|-+  Главная категория» Общие вопросы» Особенности хранения кэша на диске (NTFS-сжатие, размер кластера, фрагментация и т.д.)
Имя пользователя:
Пароль:
Страниц: 1 [2] 3  Все   Вниз
« предыдущая тема следующая тема »
  Отправить эту тему    Печать  
Автор Тема: Особенности хранения кэша на диске (NTFS-сжатие, размер кластера, фрагментация и т.д.)  (Прочитано 34083 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Сергей
Beta tester
*****

Репутация: +9/-2
Offline Offline

Сообщений: 621
« Ответ #20 : 02 июля 2007, 14:28:06 »
Вот я и предлагаю компромисс. Не отказываться от сжатия совсем и сжимать только то что хорошо жмется.
Кстати, во времена медленных винтов сжатие еще и позволяло увеличить скорость винта. Потому что чтение и распаковка данных работала быстрее чем просто чтение несжатого файла.
Сейчас это уже не так актуально.
Сообщить модератору   Записан
Rick
Администратор
*****

Репутация: +15/-1
Offline Offline

Сообщений: 868


WWW
« Ответ #21 : 02 июля 2007, 14:45:40 »
Цитата: Сергей от 02 июля 2007, 14:28:06
сжимать только то что хорошо жмется.
Как определить, что имеет смысл сжимать, а что нет? Тип? Размер? Это все не очень то достоверно - в зависимости от содержимого результат будет разный.
Т.е. вопрос: что считать критерием для сжатия.

Цитата: Сергей от 02 июля 2007, 14:28:06
во времена медленных винтов сжатие еще и позволяло увеличить скорость винта. Потому что чтение и распаковка данных работала быстрее чем просто чтение несжатого файла.
Это миф. Целью всегда было впихнуть на диск больше данных - именно за счет быстродействия.
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #22 : 02 июля 2007, 15:25:26 »
Цитата: Rick от 02 июля 2007, 14:45:40
Т.е. вопрос: что считать критерием для сжатия.

Заголовки ответа сервера:

( Content-Type = 'text/html'  AND  Content-Encoding <> 'gzip|deflate|compress' )
« Последнее редактирование: 02 июля 2007, 16:27:19 от DenZzz » Сообщить модератору   Записан
Сергей
Beta tester
*****

Репутация: +9/-2
Offline Offline

Сообщений: 621
« Ответ #23 : 02 июля 2007, 16:41:49 »
Похоже сжатие в NTFS работает избирательно. Даже если у файла стоит аттрибут сжатия это не сначит что он сжат полностью. Возможно во время записи не зватило ресурсов и Windows чать блоков оставил нетронутыми.
Команда compact /c /f исправляет ситуацию Улыбка
Сейчас пройдусь по всему кэшу и узнаю сколько еще места освободится....
« Последнее редактирование: 02 июля 2007, 17:06:38 от Сергей » Сообщить модератору   Записан
NothingAnother
Beta tester
*****

Репутация: +7/-2
Offline Offline

Сообщений: 434

Spoiler
« Ответ #24 : 02 июля 2007, 20:43:06 »
Цитата: Сергей от 02 июля 2007, 16:41:49
если у файла стоит аттрибут сжатия это не сначит что он сжат полностью
А из чего это следует? Если ты имеешь в виду ключ "/F" - это не совсем то...
Сообщить модератору   Записан
Мы тоже не всего читали Шнитке!..
© В. Вишневский
Дем
Постоялец
***

Репутация: +6/-3
Offline Offline

Сообщений: 167
« Ответ #25 : 05 июля 2007, 12:08:20 »
Цитировать
Ну а тогда при чём здесь HC?  Да и как в таком случае синхронизировать доступ к файлам?
НС тут естественно не очень причём. А синхронизировать - в смысле?
Если чтобы ловило что НС на диск пишет - ставится хук и всех делов.
Если чтобы не мешало читать - то это ещё проще.

Цитировать
Мы не можем сжимать все подряд. Браузер нас не поймет
  А про "всё подряд" речи не идёт.
Только то, что опозналось как сжимаемые и, опционально, то, что не опозналось как несжимаемое - его совсем немного.
Цитировать
Большинство файлов в кэше - мелкие файлики немалая часть из которых несжимаема
Ещё момент - если файл достаточно мал, чтобы влесть в свободное место его записи в МFT (т.е. несколько сот байт) - он туда и попадёт.
Цитировать
А из чего это следует?
Ну собственно можно посмотреть размер до и после пересжатия.
А вот почему? Может в самом деле не успевает, а может и потому, что файл мелкими кусочками пишется
Сообщить модератору   Записан
Casm
Новичок
*

Репутация: +0/-0
Offline Offline

Сообщений: 23
« Ответ #26 : 14 сентября 2007, 02:04:22 »
Однажды на ru-board спросили привести данные о “сколько у кого в кэше HC файлов какого размера”.
Привожу то, что получилось у меня.
Папка  "Cache"   
Содержит:   
Папок                  26095
Файлов                 68402
Размер файлов          622,270,848
Упакованный размер     538,403,576
Степень сжатия         86%
Размер кластера        512
Реальный размер        554,023,424
Остатки кластеров      15,619,848 (2%)

Размер файлов, < Y байт5127001 0241 5362 0482 5603 0723 5844 0968 19216 38432 76865 536131 072262 144524 2881 048 5762 097 1524 194 304> 4МБВсего
Количество файлов, 0..Y байт17 8472036823 56127 12031 01034 57637 24739 48941 39351 70760 46665 01667 38568 11768 29468 33968 37268 39168 39968 402-
X, Y=512,1024… X<Y17 8472 5213 1933 5593 8903 5662 6712 2421 90410 3148 7594 5502 3697321774533198368 402
Доля файлов размером от X до Y26,09%3,69%4,67%5,20%5,69%5,21%3,90%3,28%2,78%15,08%12,81%6,65%3,46%1,07%0,26%0,07%0,05%0,03%0,01%0,00%100%

Подсчет проводился, с помощью поиска Far.
Как известно, файлы малого размера в NTFS хранятся напрямую в MFT.
Ради интереса решил узнать какие именно.
Для этого использовал встроеную команду в WinXP fsutil и плагин для Far NTFS File Information.
Код:
fsutil file createnew test.txt 700
Кстати, те кто используют Far можно упростить - нажмите F2-> Вставить команду заполните поля гор. клавиши, и описания в качества команды укажите
Код:
fsutil file createnew !?Имя файла?"(!\)test.txt"! !?Длина файла,байт?1000!

Я создавал файлы размеров от 500 до 1000 байт (размер выбирал по дихотомии) и проверял их расположение на диске с помощью плагина NTFS File Information.
Как оказалось для файлов, размер которых менее 680-700 байт (почему точной границы нет, я не понял, на разных разделах получалось по разному) информации о занимаемом размере на диске не было, соотвественно остается предположить что они находятся в MFT.
Как видно из таблицы/графика (см. приложенный рисунок) почти треть (26,09% + 3,69%) файлов в моём кеше оказалась в MFT. Другой пик 15,08% оказался для файлов размером от 8 192 до 16 384 байт.

Моё мнение, заключается, что лучше кеш располагать на отдельном разделе (лучше конечно на отдельном жестком диске Улыбка ) , либо на виртуальном диске, или у кого кеш не большой на флеш-диске (в таком случае его и дефрагментировать не надо, и с переносимостью проблем не будет).
Преимущества заключаются в следующем. Получается, что в случае использования NTFS часть кеша оказывается в MFT (по-умолчанию, в разделе где находиться система), увеличивая её размер, и возможно приводя к её фрагментации. Если пользоваться дефрагментаторами, то печального здесь ничего нет. Однако если оценить путь, который описывают головки жесткого диска, при чтении данных из кеша  (30% времени в MFT, остальное по разделу без учета остальной работы), то оптимальнее отдать под кеш отдельный раздел в эксклюзивное использование.
Как пример, в файле File_in_Cache.jpg белыми точками (указаны стрелками) отмечено как расположились файлы из папки handycache.ru/images/manual в кеше у меня (расположен на виртуальном диске) (по данным UltimateDefrag).
p.s. в CacheHC_stat.zip лист excel, где проводились расчеты.

* Stat-Cache.png (11.64 Кб, 656x397 - просмотрено 57 раз.)
* CacheHC_stat.zip (3.66 Кб - загружено 21 раз.)

* File_in_Cache.jpg (51.58 Кб, 422x468 - просмотрено 69 раз.)
Сообщить модератору   Записан
HandyCache RC2 1.0.0.103
Mozilla Firefox 3.0.1
Opera 9.52
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #27 : 14 сентября 2007, 16:08:20 »
Вот результаты моих измерений папки "Cache" на данный момент:   
   
Папок15 948
Файлов51 773
Размер файлов, байт412 950 476
Фактический размер на диске, байт552 714 240
Размер кластера, байт4 096
Остатки кластеров, байт139 763 764 (25%)
NTFS-сжатие не используется

Распределение файлов по размерам:

Максимальный размер файла (Y), байт5127001 0241536204825603072358440968192163843276865536131072262144524288>524288Всего
Количество файлов от 0 до Y байт132401555118764240492798630015319053313834129392424529748519508605165751753517715177351773
Количество файлов в интервале (Yn-1;Yn) 13240231132135285393720291890123399151136055322223417979618251773
Доля файлов в интервале (Yn-1;Yn)25,57%4,46%6,21%10,21%7,60%3,92%3,65%2,38%1,91%9,88%11,70%6,22%4,52%1,54%0,19%0,03%0,00%100%

Как можно заметить, мой кэш содержит мало больших файлов, т.к. их загрузка (сохранение) ограничено соответствующими настройками HC, либо они просто грузятся качалкой и в кэш не попадают.

NTFS-сжатие я не использую, т.к. его необходимость вызывает у меня сомнения. Подробности в теме: "Стоит ли задействовать NTFS-сжатие файлов кэша?"

Да, еще размер кластера у меня составляет 4 кб, хотя под кэш обычно рекомендуются диски с кластером 512 или 1024 байт. Причин для этого несколько:
1. Свободного места у меня девать некуда, т.к. крупные архивы, музыку и видео имею привычку хранить на CD/DVD.
2. Кроме собственно кэша с его маленькими файлами на том же логическом диске у меня также лежат файлы побольше размером до гигабайта. А также не стоит забывать, что сверхмалые файлы до 700 байт, которых в моем кэше около 30%, хранятся прямо в MFT, т.е. для них размер кластера не имеет значения!
3. Самое главное - уменьшение размера кластера кроме блага в виде экономии дискового пространства еще таит в себе и увеличение фрагментации диска и размера MFT. Хоть это будет не так заметно на NTFS, но физически заставит диск и его головки работать с большей нагрузкой, что в итоге не может не сказаться на производительности и сроке службы (надежности) дискового накопителя.
Если я заблуждаюсь, развейте мои опасения... Подмигивающий

* Graph-2.png (5.21 Кб, 616x307 - просмотрено 41 раз.)
* CacheHC-2.zip (3.78 Кб - загружено 20 раз.)
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #28 : 14 сентября 2007, 18:45:26 »
Небольшая ложка дегтя к первому посту:

Цитата: Casm от 14 сентября 2007, 02:04:22
у кого кеш не большой на флеш-диске (в таком случае его и дефрагментировать не надо...).

Почему же не надо? Разве флеш-носитель не подвержен фрагментации?

Цитировать
Получается, что в случае использования NTFS часть кеша оказывается в MFT (по-умолчанию, в разделе где находиться система), увеличивая её размер, и возможно приводя к её фрагментации.

Немного теории: размер 1 записи MFT постоянен и равен обычно 1 кб. Если 1 записи для атрибутов файла мало, то используется 2, 3 и т.д.
Так вот, тело файла помещается в MFT только в том случае, если оно умещается в 1 MFT запись! Таким образом, MFT никуда "не раздувается", а наоборот используется более эффективно, т.к. в свободное место MFT-записи о файле записывается его тело. Это не только экономит место на диске, но и ускоряет чтение таких файлов!

С тем, что кэшу не место в системном разделе, полностью согласен...
Сообщить модератору   Записан
Casm
Новичок
*

Репутация: +0/-0
Offline Offline

Сообщений: 23
« Ответ #29 : 14 сентября 2007, 23:20:03 »
Цитата: DenZzz от 14 сентября 2007, 18:45:26
Почему же не надо? Разве флеш-носитель не подвержен фрагментации?
Подвержен, но думаю, в отсутствии механических частей здесь фрагментация не имеет большого значения.
Цитировать
Таким образом, MFT никуда "не раздувается", а наоборот используется более эффективно

согласен, но в том абзаце я пытался доказать, что кеш лучше располагать на отдельном разделе, с чем собственно, вы и согласились
Сообщить модератору   Записан
HandyCache RC2 1.0.0.103
Mozilla Firefox 3.0.1
Opera 9.52
Wonderboy
Новичок
*

Репутация: +0/-1
Offline Offline

Сообщений: 27
« Ответ #30 : 03 октября 2007, 17:43:50 »
Вижу, многие используют контейнеры для хранения кеша, я не исключение. Интересует, кто какую программу использует. Например, я VDFcrypt, но когда попробовал поставить 64-битку на машину, программа не заработала. Кто пользовался VDFcrypt и Truecrypt, они отличаются в плане скорости/удобства ? Может перейти на Truecrypt?
Сообщить модератору   Записан
Casm
Новичок
*

Репутация: +0/-0
Offline Offline

Сообщений: 23
« Ответ #31 : 04 октября 2007, 03:07:58 »
Wonderboy
Использовал как VDFcrypt так и Truecrypt (только на 32бит машине).
Если оценивать только как хранилище для кеша, то в Truecrypt есть такая особенность, что для монтирования вирт. диска требуется указать пароль. Но это можно обойти через ключи (например создать ярлык и поместить его в автозагрузку), вот пример из TrueCrypt User Guide (идет вместе с программой)
Цитировать
Mount a volume called myvolume.tc using the password MyPassword, as the drive letter X.
TrueCrypt will open an explorer window and beep, mounting will be automatic:
Код:
truecrypt /v myvolume.tc /lx /a /p MyPassword /e /b
/v - путь к образу (в примере предполагается, что он в той же папке, что и программа)
/lx - диску назначить букву X:
/a - монтировать автоматически
/p MyPassword - собственно пароль
/e - открыть подключенной диск в Проводнике (нафиг не нужно, но пример не мой)
/b - пропищать после подключения
Полный список параметров в TrueCrypt User Guide стр. 54
Сообщить модератору   Записан
HandyCache RC2 1.0.0.103
Mozilla Firefox 3.0.1
Opera 9.52
crackcrack
Новичок
*

Репутация: +0/-0
Offline Offline

Сообщений: 23
« Ответ #32 : 03 мая 2008, 05:39:00 »
какой оптимальный и максимальный размер кэша HC?
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #33 : 03 мая 2008, 15:02:13 »
Цитата: crackcrack от 03 мая 2008, 05:39:00
какой оптимальный и максимальный размер кэша HC?

Это зависит только от диска и файловой системы! HC все равно какого размера у него кэш - это впрямую не сказывается на его быстродействии. Главное, чтобы файловая система не тормозила!
Сообщить модератору   Записан
Forest
Новичок
*

Репутация: +0/-0
Offline Offline

Сообщений: 6
« Ответ #34 : 25 июня 2008, 19:08:13 »
Наверное размер кластера в 1024 более оправдан, так как у больший процент мелких файлов попадут в MFT.
Или не обязательно?
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #35 : 25 июня 2008, 21:26:28 »
Не вижу взаимосвязи. Размер MFT-записи может быть один, а размер кластера - другой.
Сообщить модератору   Записан
Forest
Новичок
*

Репутация: +0/-0
Offline Offline

Сообщений: 6
« Ответ #36 : 25 июня 2008, 21:40:35 »
Цитата: DenZzz от 25 июня 2008, 21:26:28
Не вижу взаимосвязи. Размер MFT-записи может быть один, а размер кластера - другой.
А тут где-то писали, что размер записи, куда должен поместиться файл, чтобы он попал в МФТ, ровно 1кб.
Или это тоже настраивается?
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #37 : 25 июня 2008, 22:35:14 »
Цитата: Forest от 25 июня 2008, 21:40:35
Или это тоже настраивается?

1 кб - это дефолтный размер записи MFT. Чтобы уместить туда файл, он должен быть размером примерно до 700 байт.

Размер записи MFT настраивается на этапе форматирования диска и может быть равен от 1 до 4 кб. Размер кластера настраивается отдельно и может быть равен от 512 байт до 64 килобайт.
Сообщить модератору   Записан
Forest
Новичок
*

Репутация: +0/-0
Offline Offline

Сообщений: 6
« Ответ #38 : 25 июня 2008, 23:21:15 »
Цитировать
Размер записи MFT настраивается на этапе форматирования диска и может быть равен от 1 до 4 кб.
А чем надо для этого форматировать? А то формат у ХР такого параметра не знает Грустный
Или это под Вистой так?
Если все таки так можно, то мб самым эффективным вариантом будет размер кластера=размеру записи=4096?..
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #39 : 26 июня 2008, 08:09:00 »
Цитата: Forest от 25 июня 2008, 23:21:15
А чем надо для этого форматировать?

Чем-нибудь не из комплекта Windows. Но лучше, имхо, оставить стандартный размер записи в MFT...

Цитировать
Если все таки так можно, то мб самым эффективным вариантом будет размер кластера=размеру записи=4096?..

Не думаю. В MFT останется много полупустых записей, под которые будет занято место на диске, особенно, если сами файлы не влезут в MFT.
Сообщить модератору   Записан
Страниц: 1 [2] 3  Все   Вверх
  Отправить эту тему    Печать  

« предыдущая тема следующая тема »
 
Перейти в:  



Powered by SMF 1.1.3 SMF © 2006, Simple Machines LLC
Joomla Bridge by JoomlaHacks.com