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

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

Сообщений: 4
« : 23 июня 2007, 17:24:03 »
Вот мои параметры папки:
size 3.97G
size of disk 4,73G
326200 files, 174460 folders
---

Вероятно там больше всего картинок, которые просто не жмутся и эффект нулевой.

HandyCache делает отчистку только по ресурсам целиком, а не по отдельным файлам.

Стоит ли включать ntfs compress в винде?
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589
« Ответ #1 : 23 июня 2007, 22:28:26 »
Цитата: Madsly от 23 июня 2007, 17:24:03
Стоит ли включать ntfs compress в винде?

Было много разных мнений, но однозначного ответа на этот вопрос нет...

Кто включил сжатие, утверждают, что экономится 15-20% дискового пространства без заметного снижения скорости работы с кэшем. Хотя теоретически, процедура компрессии/декомпрессии должна потреблять больше ресурсов, чем без ее использования...

Цитировать
Вероятно там больше всего картинок, которые просто не жмутся и эффект нулевой.

В том и суть! Многие файлы несжимаемые, а процедура компрессии будет работать впустую, потребляя ресурсы...
Поэтому в ToDo даже было внесено предложение о выборочной установке средствами HC атрибута сжатия только для определенных файлов:
Цитировать
Выставлять для (текстовых) данных, записываемых в кэш, атрибут "Compressed", если файловая система NTFS (опционально). В качестве критерия использовать расширения файлов и/или инфу "Content-Type"
Возможно, это будет реализовано в будущем...

Приличную экономию дискового пространства еще можно получить на остатках кластеров, разместив кэш на диске с размером кластера 512 или 1024 байт, т.к. многие файлы в кэше имеют размер, меньший стандартного размера кластера в 4 кб.


Цитировать
HandyCache делает отчистку только по ресурсам целиком, а не по отдельным файлам.

Это неверно! HC производит очистку "по отдельным файлам"!
Сообщить модератору   Записан
Madsly
Новичок
*

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

Сообщений: 4
« Ответ #2 : 23 июня 2007, 23:17:38 »
Это неверно! HC производит очистку "по отдельным файлам"!
Возможно я спутал с удалением директорий меньше указанного размера. Ведь в списках не выводятся файлы.. только директории.

Хотел поудалять много мелких файлов чтобы уменьшить общее кол-во и небольшую экономию в размере.

Да пожалуй экономия места от NTFS сжатия будет низкая... меня больше не размер беспокоит а крайне медленная загрузка файлов, когда в автономном режиме в maxthon грузится 100-200 страниц... возможно это баги браузера... да и файлов грузится крайне много, скорость от фрагментации падает.
Сообщить модератору   Записан
mzr
Новичок
*

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

Сообщений: 17
« Ответ #3 : 27 июня 2007, 19:01:44 »
Виртуальный диск TrueCrypt
Size: 4500,0  MB
Used: 3815,1  MB
Free: 684,9  MB
512 Bytes per Cluster (NTFS)


Size: 3302,1  MB
Allocated: 3225,8  MB
Files: 344566
Wasted: 83,3  MB
Compr: 2,3%

Почти все занимают jpg, gif, png.
Сообщить модератору   Записан
Дем
Постоялец
***

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

Сообщений: 167
« Ответ #4 : 28 июня 2007, 16:23:50 »
Собственно, сжатие можно включать не на весь кеш, а для конкретных папок.
В которые попадает много легкожмушегося контента, например форум или ещё что.
А при желании сжать ещё сильнее - можно и гзипом по кешу пройтись
Сообщить модератору   Записан
Сергей
Beta tester
*****

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

Сообщений: 621
« Ответ #5 : 29 июня 2007, 10:34:17 »
Цитата: Дем от 28 июня 2007, 16:23:50
можно и гзипом по кешу пройтись

А это неплохая идея  Отлично!
Можно написать внешнюю утилитку, которая бы искала текстовые файлы и сжимала их в gz.
Но только не всегда можно достоверно распознать тип файла.
Лучше конечно реализовать это как я предлагал - чтобы HC сам выставлял атрибут сжатый для данных с типом text/html. По заголовкам сервера это узнать легче.
Тогда бы не пришлось сжимать все подряд. А то итак скорость доступа к кэшу хромает.
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589
« Ответ #6 : 29 июня 2007, 11:56:29 »
Цитата: Сергей от 29 июня 2007, 10:34:17
чтобы HC сам выставлял атрибут сжатый для данных с типом text/html.

Только за исключением уже сжатых текстовых данных, т.е. с gzip (deflate и т.д.) в "Content-Encoding", т.к. повторно сжимать уже сжатое не имеет смысла...


P.S. А кто-нибудь анализировал в своем кэше, сколько процентов сайтов не применяют GZIP-сжатие? И какой объем в кэше занимают несжатые тексты? Стоит ли вообще овчинка с NTFS-сжатием выделки?

P.P.S. Видимо, более заметный выигрыш от сжатия кэша получат пользователи Проксомитрона и прочих сетевых прог, разжимающих трафик перед отдачей HC...
Сообщить модератору   Записан
Сергей
Beta tester
*****

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

Сообщений: 621
« Ответ #7 : 29 июня 2007, 17:26:23 »
Забыл сказать -  желательно чтобы HC расжимал gzip данные и потом ставил аттрибут сжатия.
Так намного удобнее копаться в кэше Улыбка
Сообщить модератору   Записан
Дем
Постоялец
***

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

Сообщений: 167
« Ответ #8 : 30 июня 2007, 14:11:17 »
Цитировать
Но только не всегда можно достоверно распознать тип файла.
Ну тогда можно попробовать их сжать. Если эффект есть - то сохранять Улыбка
Цитировать
чтобы HC сам выставлял атрибут сжатый для данных с типом text/html.
Это да, интересное предложение. Хотя экономия места не очень большая - например 333Мб хтмлок ужались всего в 146М. гзип ужимает раза в два лучше.
Цитировать
Забыл сказать -  желательно чтобы HC расжимал gzip данные и потом ставил аттрибут сжатия.
А мне лучше наоборот - чтобы он в гзип зажимал Улыбка
Сообщить модератору   Записан
NothingAnother
Beta tester
*****

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

Сообщений: 434

Spoiler
« Ответ #9 : 30 июня 2007, 15:50:50 »
Цитата: Дем от 30 июня 2007, 14:11:17
можно попробовать их сжать. Если эффект есть - то сохранять
Да больно уж  эта операция (сжать) ресурсоёмкая (используется в большинстве тестов производительности системы), и если только ради "попробовать" - не очень как-то...
Сообщить модератору   Записан
Мы тоже не всего читали Шнитке!..
© В. Вишневский
Дем
Постоялец
***

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

Сообщений: 167
« Ответ #10 : 01 июля 2007, 13:41:07 »
Ну, во-первых, гзип - "нетяжёлый" алгоритм, а во-вторых - если этим будет заниматься какая-нибуть прога в фоновом режиме - мешать не будет...
Сообщить модератору   Записан
NothingAnother
Beta tester
*****

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

Сообщений: 434

Spoiler
« Ответ #11 : 01 июля 2007, 14:32:25 »
Цитата: Дем от 01 июля 2007, 13:41:07
гзип - "нетяжёлый" алгоритм
По сравнению с чем "нетяжёлый"? 7Z, RAR? Непонимаю При чём здесь это - сравнивать-то приходится с отсутствием оного ваще, а в таком случае как раз - "тяжёлый" Показывает язык
Цитировать
если этим будет заниматься какая-нибуть прога
Ну а тогда при чём здесь HC? Смущен Да и как в таком случае синхронизировать доступ к файлам?
Сообщить модератору   Записан
Мы тоже не всего читали Шнитке!..
© В. Вишневский
Кирилл
Beta tester
*****

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

Сообщений: 124
« Ответ #12 : 01 июля 2007, 15:19:29 »
NothingAnother
Ну gzip вполне позволяет сжимать текстовый трафик в реальном времени и как опция для держателей персонального кеша (особенно на FAT32 на флешке) это будет полезно.
Но у распакованных файлов куча преимуществ в плане просмотра другими программами и поиска по содеримому.
Сообщить модератору   Записан
NothingAnother
Beta tester
*****

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

Сообщений: 434

Spoiler
« Ответ #13 : 01 июля 2007, 18:53:27 »
Цитата: Кирилл от 01 июля 2007, 15:19:29
gzip вполне позволяет сжимать текстовый трафик в реальном времени
Вообще-то, GZip сам по себе не может позволить/не позволить - это определяется именно ресурсами, которые система может под это выделить (что в свою очередь зависит как от харда, так и от софта, выполняющегося в это же время). Так что, если у кого-то доп. нагрузка (даже и при более эффективных алгоритмах сжатия) будет просто незаметной, то у кого-то напротив - заставит систему поразмышлять. Поэтому, могу лишь повторить: если это только ради "попробовать" - не очень как-то...
Сообщить модератору   Записан
Мы тоже не всего читали Шнитке!..
© В. Вишневский
Сергей
Beta tester
*****

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

Сообщений: 621
« Ответ #14 : 02 июля 2007, 11:41:05 »
Цитата: Дем от 30 июня 2007, 14:11:17
Ну тогда можно попробовать их сжать. Если эффект есть - то сохранять Улыбка
Мы не можем сжимать все подряд. Браузер нас не поймет Грустный
Сообщить модератору   Записан
NothingAnother
Beta tester
*****

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

Сообщений: 434

Spoiler
« Ответ #15 : 02 июля 2007, 12:14:10 »
Цитата: Сергей от 02 июля 2007, 11:41:05
Мы не можем сжимать все подряд. Браузер нас не поймет
Ну, почему же - это решаемо, другое дело - а оно надо?
Сообщить модератору   Записан
Мы тоже не всего читали Шнитке!..
© В. Вишневский
Сергей
Beta tester
*****

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

Сообщений: 621
« Ответ #16 : 02 июля 2007, 13:14:06 »
Цитата: NothingAnother от 02 июля 2007, 12:14:10
Ну, почему же - это решаемо, другое дело - а оно надо?

Мне не надо. GZip в кэше только мешает.
А вот избирательное сжатие NTFS позволило бы эффективнее расходовать место на диске без потери производительности.
Сообщить модератору   Записан
Rick
Администратор
*****

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

Сообщений: 868


WWW
« Ответ #17 : 02 июля 2007, 13:19:34 »
Цитата: Сергей от 02 июля 2007, 13:14:06
сжатие NTFS позволило бы эффективнее расходовать место на диске без потери производительности.
За счет энергии космоса?
Сообщить модератору   Записан
NothingAnother
Beta tester
*****

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

Сообщений: 434

Spoiler
« Ответ #18 : 02 июля 2007, 13:21:22 »
Цитата: Сергей от 02 июля 2007, 13:14:06
сжатие NTFS позволило бы эффективнее расходовать место на диске без потери производительности
Корректнее было бы сказать - "без ощутимой потери производительности", да то - не у каждого юзера...
Сообщить модератору   Записан
Мы тоже не всего читали Шнитке!..
© В. Вишневский
Rick
Администратор
*****

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

Сообщений: 868


WWW
« Ответ #19 : 02 июля 2007, 13:36:52 »
Сжатие _всегда_ требует ресурсов системы. Одно дело файл читается с диска и сразу отдается клиенту, другое - файл читается в память, потом происходит его разархивирование (промежуточныей результат так же помещается в память) и лишь затем передается клиенту.
Лично я негативно отношусь к сжатию. Большинство файлов в кэше - мелкие файлики немалая часть из которых несжимаема (т.е. их сжатие - пустая трата системных ресурсов). На мой взгляд оптимальный шаг - выделить для кэша отдельный раздел и отформатировать его с размером кластера 512B.
Подчеркиваю: это лично мое мнение.
Сообщить модератору   Записан
Сергей
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.
Сообщить модератору   Записан
Villi
Старожил
****

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

Сообщений: 347


WWW
« Ответ #40 : 01 октября 2008, 05:25:48 »
Я храню кеш НС на съемном диске, у него скорость чтения и записи выше, чем у моих жестких дисков.
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589
« Ответ #41 : 01 октября 2008, 11:04:58 »
Цитата: Villi от 01 октября 2008, 05:25:48
Я храню кеш НС на съемном диске, у него скорость чтения и записи выше, чем у моих жестких дисков.

У тебя съемный диск по USB подключается? Если да, то у него предел скорости чтения/записи - до 60 МБ/сек. Реально же у меня выходит не больше 30 МБ/сек.
А у внутреннего диска на SATA-300, к примеру, предельная скорость в теории - до 300 МБ/сек, т.е. на порядок больше, чем у внешнего винта!
« Последнее редактирование: 01 октября 2008, 11:10:33 от DenZzz » Сообщить модератору   Записан
Villi
Старожил
****

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

Сообщений: 347


WWW
« Ответ #42 : 01 октября 2008, 16:53:48 »
Съемный диск по USB подключается.
Надо поэкспериментировать еще раз со скоростями.
А если создать виртуальный PGP диск, то скорость чтения-записи будет та же что и на том диске, на котором находится образ этого виртуального диска?
Сообщить модератору   Записан
wiser
Новичок
*

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

Сообщений: 15
« Ответ #43 : 01 октября 2008, 16:59:00 »
Вроде все перечитал и все-таки не нашел "официальной" рекомендации по поводу "урезания" кеша! Вариантов высказано много, вот только экспериментировать не очень хочется!
Сообщить модератору   Записан
zed
Постоялец
***

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

Сообщений: 141
« Ответ #44 : 01 октября 2008, 17:54:18 »
Кэш HC храню на диске созданном TrueCrypt:
Размер диска: 4,29 Гб
Занято: 1.90 Гб (на диске занимает 1,95 Гб)
Файлов: 218 тыс.
Папок: 70 тыс.
Файловая система: NTFS
Размер кластера: 512 байт
Опция Разрешить индексирование включена.
HC при этом работает одинаково быстро, что с полным кэшем, что с пустым. Но в папку с полным кэшем проводником (тоталом) лучше не соваться - пока прочитает все папки, повеситься можно....
Единственный недостаток этого метода: когда диск наполниться под завязку - нужно будет в TrueCrypt создавать новый диск большего размера и переносить на него все файлы со старого кэша (часа 2 точно уйдёт на перенос), т.к. в TrueCrypt нет опции Увеличить размер существующего диска.
Зато диск с кэшем лежит под паролем, и никто посторонний моим кэшем не воспользуется. 
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589
« Ответ #45 : 01 октября 2008, 19:01:26 »
Цитата: Villi от 01 октября 2008, 16:53:48
А если создать виртуальный PGP диск, то скорость чтения-записи будет та же что и на том диске, на котором находится образ этого виртуального диска?

Нет, меньше, т.к. данные еще и шифровать придется.

Цитата: wiser от 01 октября 2008, 16:59:00
Вроде все перечитал и все-таки не нашел "официальной" рекомендации по поводу "урезания" кеша!

А что ты подразумеваешь под "урезанием кеша"? Ограничение его размера на диске? Создай под кэш отдельный раздел, тогда больше него кэш не разрастется.
Сообщить модератору   Записан
Nicolas1000
Гость
« Ответ #46 : 23 ноября 2008, 21:01:55 »
Вопрос: увеличится ли скорость доступа и считывания информации, если местом хранения кеша указать не жесткий диск, а флешку?
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589
« Ответ #47 : 23 ноября 2008, 22:30:06 »
Скорость чтения/записи в кэш уменьшится в разы!
Сообщить модератору   Записан
Страниц: 1 2 3 [Все]   Вверх
  Отправить эту тему    Печать  

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



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