Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Начинающим";
Текущий архив: 2008.04.13;
Скачать: [xml.tar.bz2];

Вниз

Упреждающее чтение.   Найти похожие ветки 

 
Riply ©   (2008-03-15 19:09) [0]

Здравствуйте !
Допустим у нас есть два фрагментированных файла.
Они располагаются в кластерах с "номерами" от 0 до 9 (идущих на диске подряд)
FirstFile занимает кластеры: 0, 2, 4, 6, 8.
SecondFile соответственно    1, 3, 5, 7, 9.

Теперь мы открываем на чтение FirstFile при помощи CreateFile
и читаем данные размером в один кластер (чтение идет из кластера с номером 0).
В упреждающем чтении будет считан кластер 2 или кластер 1 ?

P.S.
На размеры и смещения, указанные в примере,
просьба внимание не обращать: они взяты "с потолка".
Интересует что считается следующим блоком для упреждающего чтения:
Следующий блок данных в терминах файла или в терминах диска ?


 
Leonid Troyanovsky ©   (2008-03-15 19:50) [1]


> Riply ©   (15.03.08 19:09)  

> В упреждающем чтении будет считан кластер 2 или кластер 1 ?

1.

--
Regards, LVT.


 
Riply ©   (2008-03-15 20:04) [2]

> [1] Leonid Troyanovsky ©   (15.03.08 19:50)
> 1.

Леонид, я уже давно согласилась, что краткость - сестра :)
Но все же иногда бывают интересны и подробности :)

Данный ответ поняла так:
"Заведущий Упреждающим Чтением" ничего знать не знает ни о файловых системах,
ни, тем более, о расположении объектов в них.
Это правильно ?


 
Игорь Шевченко ©   (2008-03-15 20:29) [3]

Я полагаю, ты имеешь в виду открытие файла с указанием FILE_FLAG_SEQUENTIAL_SCAN.


> FirstFile занимает кластеры: 0, 2, 4, 6, 8.



> FirstFile занимает кластеры: 0, 2, 4, 6, 8.


> В упреждающем чтении будет считан кластер 2 или кластер
> 1 ?


Допустим, что файл занимает кластеры 0,19876,19877,19878,19879

Как ты считаешь, какой смысл упреждающему чтению читать кластеры 1,10, 100 и так далее ?

Руссинович с братом его во Христе Соломоном пишет, что в отличие от других операционных систем, менеджер кеша в Windows кеширует не данные диска, а данные файлов. Следовательно читаться будут данные кластеров файла, а не соседние с диска, неизвестно к чему относящиеся.


 
Leonid Troyanovsky ©   (2008-03-15 21:27) [4]


> Riply ©   (15.03.08 20:04) [2]

> ни, тем более, о расположении объектов в них.

Ну, а откуда б он мог знать о расположении, если
файл фрагментирован.

--
Regards, LVT.


 
Johnmen ©   (2008-03-15 21:31) [5]

К тому же не стОит забывать про кеш диска, куда пишет контроллер диска.
Он, конечно, не так интеллектуален, как виндовый кеш, но очень быстр. Какой у него базовый алгоритм я не знаю, но реально ускоряет при определенных раскладах чтения...


 
Leonid Troyanovsky ©   (2008-03-15 21:43) [6]


> Игорь Шевченко ©   (15.03.08 20:29) [3]

> Руссинович с братом его во Христе Соломоном пишет, что в
> отличие от других операционных систем, менеджер кеша в Windows
> кеширует не данные диска, а данные файлов.

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

Предсказать же оптимальный переход при фрагментации
врядли возможно.

Я б почитал Шрайбера, но, к сожалению, ни то ни другое
ныне мне не доступно.

--
Regards, LVT.


 
Riply ©   (2008-03-15 21:45) [7]

Уфф...
Спасибо большое.
Требуется маленький тайм-аут, для обдумывания и осознания :)


 
guav ©   (2008-03-15 23:12) [8]

А почему бы не проверить на практике ?
Например, посмотреть какие там семещения и размеры приходят в IRP_MJ_READ тома.
Кстати, простой способ создания требуемой в [0] фрагментации - использовать FAT, создать два файла и увеличивать их по очереди.


 
Kolan ©   (2008-03-15 23:38) [9]

Удалено модератором
Примечание: Флудить завязываем. Забаню.


 
Игорь Шевченко ©   (2008-03-15 23:45) [10]

Leonid Troyanovsky ©   (15.03.08 21:43) [6]

А смысл заполнять кэш ненужными данными ? Тут ведь такое дело - данные файла могут располагаться не только не рядом на диске, но и на разных дисках вообще.

Давайте читать:

http://windowsitpro.com/Articles/Index.cfm?ArticleID=3864

"A logical drive resides on a disk partition that"s composed of physical storage units called sectors. When an application accesses data in a particular file, the file system responsible for the drive (e.g., FAT, NTFS) determines which sectors of the disk hold the data in the file. The file system then issues disk I/O requests to read from or write to those sectors. In logical block caching, the OS caches sector data in memory so that the memory associated with the target sectors, rather require disk operations, can satisfy disk I/O requests. Most older variants of the UNIX OS, including BSD 4.3, every Microsoft OS (Windows 98, Win95, Windows 3.x, and DOS) except Windows NT, and Novell NetWare, cache file system data at the logical block level.

Virtual block caching caches data at the file system level rather than the disk level. When an application accesses data in a file, the file system checks to see whether the data resides in the cache. If the data is in the cache, the file system doesn"t need to determine which sectors of the disk store the data and issue disk I/O requests. The file system simply operates on the data in the cache. NT relies on virtual block caching (implementing it in the Cache Manager), as do newer versions of UNIX, including Linux, Solaris, System V, and BSD 4.4. Virtual block caching has a couple of advantages over logical block caching. First, when file data the application is reading is in a virtual block cache, the file system performs no file-to-sector translations. In fact, in some cases, the I/O system can bypass the file system altogether and retrieve requested data directly from the cache. Second, the cache subsystem knows which files and which offsets within the files an application is asking for. The cache subsystem can monitor the access patterns of each file and make intelligent guesses about which data an application is going to ask for next. Using its guesses as guidelines, the cache subsystem reads the data from disk in anticipation of future requests. This slick process is known as read-ahead, and when the cache subsystem"s predictions are accurate, read-ahead boosts system performance. Although read-ahead is possible with logical block caching, virtual block caching makes read-ahead simple to implement. "


 
Leonid Troyanovsky ©   (2008-03-16 12:18) [11]


> Игорь Шевченко ©   (15.03.08 23:45) [10]

> http://windowsitpro.com/Articles/Index.cfm?ArticleID=3864

Не все так просто. Например,
http://support.microsoft.com/kb/837331

Исходная задача напоминает расщепление операции чтения,
и, по сути, опережающее чтение ничего здесь не даст, если,
конечно, система будет читать один кластер.

В жизни же, распознав последовательный доступ, система
будет пытаться читать большими кусками, а какие страницы
зафиксируются в кеше - это уже другой вопрос, может
в очереди запросов кто-то уже ждет и SecondFile.

Во-ще-то, насколько я помню у Р&C про кеш более 100 стр.
которых я, конечно, не помню :)

--
Regards, LVT.


 
Игорь Шевченко ©   (2008-03-16 12:39) [12]

Leonid Troyanovsky ©   (16.03.08 12:18) [11]

Ну да, ну да. Я на статью Руссиновича вышел по этой же ссылке


> http://support.microsoft.com/kb/837331


Там внизу написано: More about cache manager...


 
Riply ©   (2008-03-17 00:45) [13]

Ходила по ссылкам, читала, но так и не сумела
все "прочуствовать до печенок" :(
Давайте попробуем подойти с другой стороны
и конкретизировать задачу ?
Пусть у нас есть N файлов, каждый из которых
задан массивом кластеров. Нам надо всех их считать.
(Не важно для чего, то ли мы собрались счтитать их CRC,
то ли копировать, то ли проверять их на вхождение определенного слова,
или, просто, у нас возникло желание почитать перед сном :)
Так же не рассматриваем вопросы, связанные с памятью.)

Действуем так: составляем один массив кластеров, являющий собой
объединение всех данных массивов.
В наших силах по "номеру" кластера сказать какому файлу он принадлежит.
Ворос: по какому принципу нам надо упорядочить наш массив,
для обеспечения максимальной скорости считывания ?


 
Игорь Шевченко ©   (2008-03-17 00:54) [14]

Riply ©   (17.03.08 00:45) [13]


> Ворос: по какому принципу нам надо упорядочить наш массив,
>
> для обеспечения максимальной скорости считывания ?


Если читать не как файлы, а как секторы диска, то разумеется, стоит упорядочить по номерам кластеров. Только я не совсем понимаю, зачем, не лучше ли довериться менеджеру кэша, читая файлы ? Оно само все упорядочится. К тому же оно читает, а в память проецирует, перекладывая практически весь ввод-вывод на менеджер памяти.



Страницы: 1 вся ветка

Форум: "Начинающим";
Текущий архив: 2008.04.13;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.49 MB
Время: 0.006 c
6-1184599713
yaJohn
2007-07-16 19:28
2008.04.13
ISAPI DLL, файл больше 2 Гб


15-1204454888
Девушка
2008-03-02 13:48
2008.04.13
Классификация проблем при разработки многопользовательских прилож


15-1204391782
omen_77
2008-03-01 20:16
2008.04.13
помогите


2-1205518291
La-la-Land
2008-03-14 21:11
2008.04.13
Интернет и файлы


2-1205676755
Res
2008-03-16 17:12
2008.04.13
Cardinal





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский