Об этом написано много. Но, судя по всему, недостаточно :) Речь об области применимости API высокого уровня, и о том, что происходит, когда разработчик забывает, что внутри простого вызова выполняется (или может выполняться) масса скрытой работы. А также о том, почему важно знать область применения кода до его написания. Все на живых примерых.

Как качественно замучать HDD легальными программными способами

Снимал данные с очередного посыпавшегося жесткого диска. Битый блок аж 1. Но в очень интересном месте - в метаданных файла состояния FireFox. Место интересно тем, что чтение-запись туда происходит постоянно. А так как NTFS по умолчанию обновляет дату последнего обращения, то даже чаще, чем кажется автору программы. Есть статистика (личная) о том, что за данные находились на месте поврежденных секторов. Это постоянно перезапысываемые конфиги и/или файлы сохранения контекста работы, а также файлы СУБД, на которых часто выполняется UPDATE. За год-два непрерывных записей сектор приходит в негодность.
Алгоритм следующий: создали файл и постоянно его перезаписываем, весь или частично:

• open/write/close
• sh make_config.sh > /etc/my.conf

• драйвер диска или стороняя утилита мог бы контролировать состояние поверхности, сообщать об этом драйверу файловой системы (ФС) или самостоятельно инициировать перемежение файла в др. часть диска. Это пока что фантастический сценарий (AFAIK).
• драйвер файловой системы или стороняя утилита мог бы контролировать к-во записей в один и тот же блок и инициировать перемещение файла в др. часть диска. В некоторых драйверах некоторых ФС такая функциональность заложена. Как минимум в последних ревизиях ФС UDF предусмотрен контроль степени износа поверхности. В ZFS равномерный износ достигается за счет алгоритма Copy-On-Write (CoW).
• продуманный алгоритм сохранения данных в программе. Тут есть варианты:
  • создать новый файл, поработать с ним, старый переименовать, новый переименовать на его место, старый удалить.
  • при создании временных файлов сообщать об этом ФС, использовать спец. API или вообще memory disk, тогда есть шанс, что данные на диск записаны вообще не будут.
  • по возможности минимизировать к-во обращений, грамотно пользоваться системным кешированием или применять свое (по обстоятельствам)
  • следить за к-вом обращений и обновлений и своевременно переносить часто обновляемые данные в дрю части диска.
• частично задачу решает дефрагментация, т.к. данные переносятся в др. части диска. Но только частично и как побочный эффект.

Как здорово затормозить крутой комп легальными программными способами

Редакторы, просмотрщики, программы восстановления и обслуживания спец. файлов, почтовые программы часто глубоко задумываются, подвисают или просто глючат при работе с большими файлами. Вот одна из частых причин.
Memory mapping (отображение файла в память). Прекрасное и удобное изобретение. Используется многими программами для редактирования файлов. Также используется подсистемой кеширования - прочитанный фрагмент файла или весь файл отображается в адресное пространство операционки, а дальше в дело идет механизм страничной адресации. Блоки памяти, к которым происходит обращение, автоматически подчитываются с диска, давно неиспользуемые - записываются на диск и память освобождается.
А теперь о накладных расходах: для того, чтобы отобразить файл в память нужно построить карту, в которой будет отмечено, какой фрагмент присутствует в физ. памяти, а какой нет, был ли блок изменен и т.п. Это тоже требует выделения памяти. Кроме того, расходуется адресное пространство, которого в 32-битной системе 4Гб, из которыз для нужд memory mapping'а доступно 1-2Гб. (в 64-битной такой проблемы условно нет, т.к. нет таких объемов данных). Получается, что для того, чтобы открыть файл обычным способом (с вкл. кешированием) или отобразить его в память нужно иметь достаточное к-во памяти для служебных нужд и достаточное незанятое непрерывное адресное пространство. Для относительно небольших файлов проблем нет. А когда речь заходит о сотнях мегабайт и гигабайтах - знакомые утилиты вдруг перестают работать.
Поэтому, если вы планируете работать с очень большими файлами, недостаточно использовать 64-битные числа для указания позиции в файле. Нужно еще продумать алгоритм работы с учетом особенностей работы операционки. Либо же сразу проверять размер и сообщать пользователю, что размер слишком велик. Это намного лучше непредсказуемого поведения.

См. также