Автор Тема: Делите винт на максимально возможное число партиций - 14  (Прочитано 6437 раз)

Оффлайн yxma

  • Завсегдатай
  • *
  • Сообщений: 684
  • я люблю лИнукс. особенно альт
    • Email
может, я и неправ, но, как будто, головки читают не сами по себе, а параллельно, что как раз таки сильно ускоряет процесс. так же параллельно можно подключить и другие головки, которые могут двигаться не независимо, а как раз в связке и биты тогда будут считываться в разы быстрее. теоретически, конечно. поэтому параллельные головки считать разными не совсем верно - по сути это одна сложная головка.
симплик, он симплик и есть

Оффлайн Balbes

  • alt linux team
  • ***
  • Сообщений: 891
может, я и неправ, но, как будто, головки читают не сами по себе, а параллельно, что как раз таки сильно ускоряет процесс. так же параллельно можно подключить и другие головки, которые могут двигаться не независимо, а как раз в связке и биты тогда будут считываться в разы быстрее. теоретически, конечно. поэтому параллельные головки считать разными не совсем верно - по сути это одна сложная головка.
Читать\писать данные можно по разному, "насквозь" по цилиндрам, а не линейно по дорожкам, кэшируя с упреждением в несколько потоков и много чего еще могут наваять производители. Головки не висят постоянно над разделами  (автопарковка головок между обращениями за "территорию" дисков, термокалибровка, контроль служебных дорожек по которым они позиционируются, считывание инфы и т.д.) поэтому от большого кол. разделов существенного выигрыша в производительности не будет, может даже получиться снижение из-за не оптимального использования расположения инфы (скорость меняется по удаленности от начала хода головок и угловой скорости дисков).  :)
Если хотите "пооптимизировать" - можно поиграть с размерами кластеров под разделы с разными файлами и их упорядочить, мултиконтент и архивы с большими файлами привязать к разделам с большими кластерами, чем больше размер кластера, тем меньше дробление\фрагментация файла и перемещения головок на считывание, но и больше потери полезной емкости. А если задать размер кластера настолько большим, что в него будут влезать все файлы от маленьких до больших, вообще фрагментации не будет, но тогда и использование объема будет ну очень не рациональное. Так что у Вас есть возможность поработать над оптимизацией размера файлов, что-бы они все были примерно одинаковыми и под них делать размеры кластеров. :D

Оффлайн andrew_b

  • Завсегдатай
  • *
  • Сообщений: 535
а у вас как нарезано, поделитесь, пожалуйста, с аргументами. глядишь, будет и мне счастье
Ну как-то так:
/dev/sda1  - swap
/dev/sda2  - / type ext3 (rw)
/dev/sda5  - /tmp type ext3 (rw,noexec,nosuid,nodev)
/dev/sda6  - /var type ext3 (rw,nosuid,nodev)
/dev/sda7  - /usr type ext3 (rw,nodev,noatime)
/dev/sda8  - /home type ext3 (rw,nosuid)
/dev/sda9  - /opt type ext3 (rw,nodev,noatime)
/dev/sda10 - /home/$USER/hasher-workdir type ext3 (rw,nosuid)
/dev/sda11 - раздел для QEMU
/dev/sda12 - /var/media type ext3 (rw,nosuid,nodev,noatime)
Ну какие аргументы? А никаких.  :)

Оффлайн yxma

  • Завсегдатай
  • *
  • Сообщений: 684
  • я люблю лИнукс. особенно альт
    • Email
со свопом, корнем, темпом, переменными и домом все понятно и, наверное, логично.
а как с размерами и заполняемостью разделов?
симплик, он симплик и есть

Оффлайн yxma

  • Завсегдатай
  • *
  • Сообщений: 684
  • я люблю лИнукс. особенно альт
    • Email
хм, может быть большие кластеры при сжатии нтфс и дадут некоторый прирост скорости
симплик, он симплик и есть