Долговечность флешки в Iphone - PullRequest
Новая
       40

Долговечность флешки в Iphone

2 голосов
/ 30 ноября 2009

Из руководства по программированию iPhone

При создании файлов или записи данные файла, сохраните следующее руководящие принципы:

  1. Минимизируйте объем данных, которые вы записываете на диск. Файловые операции выполняются относительно медленно и включают запись на флэш-диск, срок службы которого ограничен. Вот некоторые конкретные советы, которые помогут вам свести к минимуму операции с файлами:
    1. Записывать только те части файла, которые изменились, но объединять изменения, когда это возможно.
    2. Старайтесь не записывать весь файл просто для изменения нескольких байтов.
    3. При определении формата файла группируйте часто изменяемый контент вместе, чтобы минимизировать общее количество блоков, которые необходимо записывать на диск каждый раз.
    4. Если ваши данные состоят из структурированного контента, доступ к которому осуществляется случайным образом, сохраните его в постоянном хранилище Core Data или в базе данных SQLite. Это особенно важно, если объем данных, которыми вы манипулируете, может вырасти до нескольких мегабайт.
  2. Избегайте записи файлов кэша на диск. Единственное исключение из этого правила - когда ваше приложение закрывается, и вам нужно записать информацию о состоянии, которую можно использовать, чтобы вернуть ваше приложение в то же состояние при следующем запуске.

Некоторое время назад я читал статью о твердотельных накопителях Intel (которые, к сожалению, пока не могу найти), в которых упоминалось, что основной проблемой долголетия было то, что ОС фактически не удаляла данные, а просто помечала блокирует как свободные, вызывая довольно болезненное замедление, когда эти «свободные» блоки записываются (вызывая чтение-изменение-хранение, а не просто сохранение). Это касается и iPhone, т. Е. Будет ли диск более подвержен замедлению при более частом удалении файлов?

Я рассматриваю формат файла, основанный на журнале повторов, таким образом я могу поддерживать отмену между сеансами, и у меня также нет случайных записей (всегда добавляются), но в какой-то момент я предполагаю, что мне придется консолидировать хотя бы часть журнала, чтобы сохранить размер файла на разумном уровне. Мой вопрос в этом случае, который был бы более эффективным (с точки зрения долговечности привода)? У меня есть пара путей, которые я рассмотрел

  1. Перезаписать тот же файл и
    1. обрезать пространство, которое мне не нужно
    2. или оставьте это место (заполненное старыми данными) и перезапишите его, когда мне это понадобится снова
  2. или напишите новый файл и удалите старый

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

1 Ответ

2 голосов
/ 30 ноября 2009

Вам не нужно беспокоиться об этой конкретной проблеме. Как и многие встраиваемые устройства, iPhone напрямую взаимодействует с чипами флэш-памяти, используя интерфейс, похожий на то, что использует чип контроллера SSD (что-то вроде ONFI). FTL (слой трансляции флэш-памяти) на iPhone - это программное обеспечение, управляемое ОС, которое полностью знает, какие блоки используются.

Хотя Apple не документирует это поведение, вы можете косвенно увидеть доказательства этого в общедоступном исходном коде xnu, который (в течение достаточно долгого времени) имеет поддержку HFS + для сообщения на уровне блоков, что определенные блоки больше не являются полезными , Ни одно блочное устройство с открытым исходным кодом ничего не делает с этой информацией, но если вы возьмете взломанный iPhone и разберете его ядро, вы увидите, что оно используется на iPhone.

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

...