Скорость работы с IDE дисками

Drive subsystem, filesystem drivers
  • CleverMouse
    А сейчас возможна ситуация, что буфер при вызовах DISKFUNC.read/write не будет непрерывным физически ?
  • Serge, да, там kernel_alloc для промежуточного буфера, который может и не быть непрерывным физически.
    Сделаем мир лучше!
  • CleverMouse
    Непрерывен, если размер кратен 8. Вот гарантировать выравнивание сложнее. Видимо всё драйвер должен отслеживать порядок страниц и границы 64К.
  • Размер необязательно кратен 8. Запись 18 секторов, которую не получилось сделать из кэша напрямую, пойдёт через буфер на две страницы.
    Сделаем мир лучше!
  • Ладно, начнём с PIO, раз уж он есть. Отключил DMA, старые вызовы fs работали нормально, новые вешали систему сразу после успешного копирования, то-есть несколько чтений, несколько записей, disk_synk, зависание. После перехода на FFFF секторов стало только хуже. Но возможно проблема не в драйвере, а в кешировании; в любом случае, я почти не знаю, как оно работает, чего ожидает и какие там ещё уровни. CleverMouse?
  • В новом hd_drv.inc я сходу никаких проблем не вижу, кроме разве что безусловного LBA48 без предварительной проверки, что он вообще поддерживается.
    "Старые" и "новые" - это fs_read32*/fs_write32* и fs_read64*/fs_write64* соответственно? Если да, то давай код с fs_read64*/fs_write64*, надо разбираться.
    Сделаем мир лучше!
  • А там и не было проверки, LBA48 использовалось если адрес не влазил в 28 бит. А в LBA28 только один байт под количество, сильно замедлит младшие сектора.
    Сейчас зависает почти сразу же. Мне кажется, что в теме "KolibriOS freezes while accessing hdd" та же проблема - наверно никто не проверял, как кеширование работает с PIO.
    В крайнем случае можно сделать disk_cache.inc с отключённым кешированием.
  • Кэширование можно отключить на уровне драйвера устройства, прописать ramdisk_adjust_cache_size последним элементом в структуру функций драйвера, не залезая в disk_cache.inc.

    Я позже посмотрю, в чём дело.
    Сделаем мир лучше!
  • Если на диске вообще есть адреса, не влезающие в 28 бит, то и LBA48 там быть должен. Так что на текущее поведение не кивай.

    Под Bochs не зависает. По симптомам похоже на interrupt storm, когда диск генерирует прерывание, обработчик ничего не делает, прерывание возникает снова и снова. Для начала проверки можно раскомментировать первые строчки с DEBUGF в IDE_irq_14_handler, IDE_irq_15_handler, IDE_common_irq_handler и загрузиться с дублированием отладочного вывода прямо на экран - если в момент зависания повторяющиеся строчки заполнят экран, проблема в этом.
    Сделаем мир лучше!
  • Проблема в обратном: при обращении к младшим секторам всегда будет использоваться LBA28, что означает падение скорости в несколько раз по текущей причине.
    Под Bochs не зависает
    Мой hd_drv.inc? Совсем весело... Я же не использую DMA, откуда прерывания?
    А если да, то что тогда делать?
  • PIO тоже генерирует прерывания.
  • Serge, может всё-таки по-подробней? Я когда свой драйвер писал, прерываниями не пользовался. И сейчас ничего не удалял, выходит они и раньше не обрабатывались.
  • Да, interrupt storm, но судя по "Preempting/Preventing IRQs from firing", может не получится их уверенно отключить - сейчас вроде используется Regular Status port. Но их можно и обрабатывать. Что лучше?
  • Who is online

    Users browsing this forum: No registered users and 2 guests