Началось все с того, что коллега увидела, как я выдергиваю флешку из ноутбука сразу после копирования, и посмотрела на меня так, будто я при ней вытащила вилку из розетки за провод. Следующие двадцать минут мы спорили про значок в трее, и к концу спора выяснилось, что ни одна из нас толком не знает, что происходит, когда на него нажимаешь. Она нажимает, потому что так учили еще в школьном компьютерном классе, я не нажимаю, потому что у меня за все эти годы ни разу ничего не сломалось, и аргументы у нас обеих, честно говоря, были уровня «а вот у моей бабушки».

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

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

Windows решает это политикой, которая настраивается для каждого устройства отдельно. Если зайти в свойства флешки, открыть вкладку «Оборудование», потом свойства самого устройства и вкладку «Политика», там будут два варианта: «Быстрое удаление» и «Оптимальная производительность». Первый отключает кэширование записи, и система отправляет данные на флешку сразу. Второй включает кэширование, и тогда без безопасного извлечения можно легко остаться с половиной файла.

Фишка в том, что начиная с Windows 10 версии 1809 (осень 2018 года) Microsoft сделала быстрое удаление политикой по умолчанию для внешних накопителей и отдельно написала об этом в документации. Что стояло по умолчанию раньше, зависело от версии и типа устройства, и тут я запуталась в старых форумах, так что утверждать ничего не буду. На моем рабочем ноуте, где я в этих настройках никогда ничего не трогала, на всех трех флешках, которые я туда воткнула, стоит «Быстрое удаление (по умолчанию)».

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

У FAT32 и exFAT, на которых живет подавляющее большинство флешек, есть флаг «том грязный». Пока том смонтирован и на него пишут, флаг взведен, а при корректном отключении Windows его снимает. Если флешку выдернуть без размонтирования, флаг так и остается взведенным, и в следующий раз система вежливо предложит проверить и исправить диск. То самое окошко, которое все закрывают не читая, и есть след того, что флешку достали наживую.

Сам по себе флаг безобиден и только сообщает системе, что том закрыли неаккуратно. Портятся данные в другом месте, в самой файловой таблице. Таблица FAT и записи каталогов обновляются отдельными операциями, и если питание пропало между записью данных и записью метаданных, на флешке остается файл нулевой длины или потерянные кластеры, которые chkdsk потом складывает в папку FOUND.000 файлами с именами вида FILE0000.CHK. С быстрым удалением окно, в которое можно так попасть, маленькое, но пока идет копирование, оно открыто.

Я проверила это самым простым способом: копировала на флешку папку с отпускными фотографиями, 1,2 ГБ в 340 файлах, и выдергивала ее посередине копирования, всего десять раз. Флешка пережила все десять, но каждый раз файл, который копировался в момент выдергивания, оказывался обрезанным или нулевой длины, а в трех случаях из десяти chkdsk еще и нашел потерянные кластеры и сложил их в FOUND.000. Если же выдергивать флешку через минуту после окончания копирования, Windows предлагала проверку в девяти случаях из десяти, и проверка ни разу ничего не нашла.

А теперь я беру ноутбук с Linux и 16 ГБ памяти, ту же флешку и образ дистрибутива на 2 ГБ.

$ time cp distro.iso /media/me/FLASH/

real    0m2,310s                 подозрительно быстро для USB 2.0
$ grep Dirty /proc/meminfo
Dirty:           1948312 kB      вот и мой образ, лежит в оперативке
$ time sync

real    3m48,617s                вот сколько он на самом деле писался

Linux плевать хотел на то, что носитель съемный. Любая запись идет через страничный кэш, cp завершается в момент, когда данные легли в память, и файловый менеджер радостно рисует «готово». Дальше ядро сбрасывает грязные страницы на носитель в фоне: поток сброса просыпается раз в vm.dirty_writeback_centisecs (по умолчанию 500, то есть раз в 5 секунд) и пишет все, что провисело в памяти дольше vm.dirty_expire_centisecs (по умолчанию 3000, то есть 30 секунд), а если грязных данных накопилось слишком много относительно объема памяти, начинает писать раньше.

Дешевая флешка на USB 2.0 пишет у меня около 9 МБ/с (так показал dd с oflag=direct), и два гигабайта она переваривала почти четыре минуты. Все это время прогресс-бар давно закрыт, файл виден в папке и даже показывает правильный размер, а если выдернуть флешку в этот момент, на ней останется ровно то, что ядро успело дописать. Сколько это будет, вам никто не скажет. Сколько людей закрыли окно копирования, выдернули флешку и понесли в копицентр файл, от которого на флешке была половина? И сколько из них потом ругали копицентр?

Насколько я помню, udisks, который монтирует флешки в большинстве десктопных окружений, монтирует vfat с опцией flush, и драйвер из-за нее старается сбрасывать данные пораньше. Судя по тому, что я вижу в Dirty, спасает это не сильно. Зато в Linux кнопка извлечения в файловом менеджере делает ровно то, что обещает: umount ждет, пока все будет записано, а GNOME еще и показывает уведомление с просьбой не отключать устройство до окончания записи. Так что на Linux эта кнопка НУЖНА, и я с опозданием на десять лет это признаю.

macOS в этом смысле ближе к Linux, запись она тоже кэширует и, если выдернуть флешку без извлечения, показывает уведомление о том, что диск был извлечен неправильно. У мака есть еще одна особенность, которую я долго не замечала. Стоит вставить флешку в мак и просто открыть ее в Finder, на ней появляются скрытые папки .fseventsd и .Spotlight-V100 (журнал событий файловой системы и индекс Spotlight), после удаления файла добавляется .Trashes, а на FAT и exFAT рядом с каждым скопированным файлом ложится его тень с приставкой «._», где мак хранит метаданные. Выходит, что мак пишет на флешку, даже если вы с нее только читали.

Windows, кстати, тоже так умеет, и папка System Volume Information с файлами IndexerVolumeGuid и WPSettings.dat появляется даже на флешках, на которые никто ничего не копировал. Аргумент «я же с нее только читала» поэтому работает хуже, чем кажется, хотя эти служебные записи маленькие и попасть выдергиванием точно в них надо еще постараться.

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

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

Насколько часто это случается и насколько хорошо конкретный контроллер переживает внезапное отключение, хз, потому что производители дешевых флешек защиту от потери питания не документируют, а конденсаторы, которые ради этого ставят в серверные SSD, во флешку за три копейки явно никто не положил. Насколько я смогла выяснить, при безопасном извлечении Windows просит сбросить кэш и само устройство (флешки общаются с компьютером урезанным SCSI поверх USB Mass Storage, и для этого там есть команда SYNCHRONIZE CACHE), но что контроллер после этой команды делает со своей фоновой уборкой, знает только его прошивка. Моя личная статистика по убитым ушедшим на покой флешкам такая: из примерно двух десятков, которые прошли через мои руки, умерли три, причем у одной просто отломился разъем, вторая после пары лет ежедневной работы перешла в режим только для чтения (так многие контроллеры сообщают, что память изношена), а третья однажды утром стала определяться с объемом 0 байт, и связать хоть одну из этих смертей именно с выдергиванием я честно не могу.

С быстрым удалением в Windows у кнопки остается не так много работы. Она дописывает то, что еще не дописано, размонтирует том и снимает грязный бит, а перед этим проверяет, держит ли какой-нибудь процесс открытым файл на флешке. Вот эта последняя проверка и выдает знаменитое «Устройство еще используется», которое обычно означает, что флешку сканирует антивирус, Проводник строит миниатюры или в Word открыт документ прямо с флешки. Word, кстати, кладет рядом с документом скрытый файл блокировки с приставкой «~$», и если выдернуть флешку, пока документ открыт, Word ругнется при следующем сохранении, а файл блокировки так и останется на флешке мусором.

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

Коллеге я, кстати, результаты так и не показала. Флешки из Windows-ноутбука я выдергиваю по-прежнему, а на Linux перед этим набираю sync и терпеливо жду, пока он вернет управление, и со стороны это, подозреваю, выглядит еще ритуальнее, чем ее щелчок по значку в трее.