exFAT: размер файлов в 10 раз меньше занятого места

[pavel-kv]

Доброго времени суток.
Имею в работе карты памяти с файловой системой exFAT, размер тома 480 ГиБ, кластеры по 512К.
Размер кластера выбран большим не просто так, карты стоят в очень малопроизводительных девайсах, где накладной расход на выделение нового кластера вызывает проблемы с производительностью.

В какой-то момент место на разделах стало заканчиваться при реальной сумме файлов около 25-30 ГиБ. Конечно, я подумал, что скопилось множество мелких файлов, каждый из которых занял кластер, но беглый взгляд показал, что общее число файлов в разделе, умноженное на размер кластера, соответствует результату объема от ncdu.

Интересует инструментарий и вообще подход, чтобы найти, в чем дело.
Пробовал fsck.exfat из exfatprogs и из fuse-exfat, оба не нашли ошибок. Когда-то подобную проблему решал через проверку виндовым чекдиском, но сейчас стоит вопрос именно найти в чем дело, чтобы написать патч для тех девайсов.

Код: [Выделить]

$ sudo ./dump.exfat /dev/sde2
exfatprogs version : 1.2.2
-------------- Dump Boot sector region --------------
Volume Length(sectors): 966656000
FAT Offset(sector offset): 65536
FAT Length(sectors): 8192
Cluster Heap Offset (sector offset): 130048
Cluster Count: 943873
Root Cluster (cluster offset): 4
Volume Serial: 0xf727f235
Sector Size Bits: 9
Sector per Cluster bits: 10

----------------- Dump Root entries -----------------
Volume entry type: 0x83
Volume label: data
Volume label character count: 4
Bitmap entry type: 0x81
Bitmap start cluster: 2
Bitmap size: 117985
Upcase table entry type: 0x82
Upcase table start cluster: 3
Upcase table size: 5836

---------------- Show the statistics ----------------
Cluster size:  524288
Total Clusters: 943873
Free Clusters: 198686


Код: [Выделить]

$ du -h -d 1 -a -c .
18G ./rec
512K ./arc
5,0M ./jrn
1,5M ./opo
8,7G ./.Trash-1000
27G .
27G итого


Код: [Выделить]

$ df -h --total /media/pk/data
Файл.система   Размер Использовано  Дост Использовано% Cмонтировано в
/dev/sde2        461G         364G   98G           79% /media/pk/data
total            461G         364G   98G           79% -


[БТР]

pavel-kv, какой дистрибутив используется? Как подключена карта - через картридер?
Выполнение fstrim поддерживается? Как часто выполняется?

[ALiEN]

Код: [Выделить]

du -shx --apparent-size /media/pk/data
du -shx /media/pk/data

[pavel-kv]

БТР, изучаю проблему из-под Ubuntu 20.04.1 ядро 5.15.0-78-generic. Карта в USB кардридере, скорее всего ни карта, ни кардридер не поддерживают трим. Смогу проверить это после бекапа образа раздела (на usb2.0 кардридере это занимает целый день). 
Встраиваемые девайсы же работают на самописной прошивке без ОС, библиотека файловой системы FATfs R0.15, трим не поддерживается.

ALiEN,

Код: [Выделить]

$ du -shx --apparent-size .
22G .


Код: [Выделить]

$ du -shx .
27G .


[БТР]

трим не поддерживается.

Знаете, что это может означать применительно к занятому объёму ФС? "Пустые" страницы не высвобождаются при удалении файлов, пока не будет выполнена их принудительная очистка.

[pavel-kv]

БТР, спасибо за мысль. Trim не реализовывался, так как раньше проблемы не возникали, да и в доках на FATfs заявлена возможность работы без trim (он же может просто поправить свою таблицу и пометить блоки как незанятые, без физической очистки, а драйверу карты памяти фиолетово, блок очищен или нет, это от нас должен абстрагировать контроллер карты памяти).
К настоящему моменту карточки уже по нескольку раз на сотне устройств перезаписались, и только сейчас начали всплывать проблемы.

[ALiEN]

а если сделать umount-mount?
Mount c ключом -v сделайте - может что интересное напишет.

И еще покажите

Код: [Выделить]

sudo parted /dev/sde print
mount | grep /sde
sudo fsck.exfat -nv /dev/sde2

[pavel-kv]

ALiEN,

Код: [Выделить]

$ sudo mount -v /dev/sdd2 /mnt/sdcard/
FUSE exfat 1.3.0
ERROR: bad date 1980-00-00.
ERROR: bad date 1980-00-00.
ERROR: bad date 1980-00-00.
Дата в ФС такая вероятно потому, что на целевых устройствах не реализованы часы.

Код: [Выделить]

$ sudo parted /dev/sdd print
Модель: Generic STORAGE DEVICE (scsi)
Диск /dev/sdd: 495GB
Размер сектора (логич./физич.): 512B/512B
Таблица разделов: msdos
Флаги диска:

Номер  Начало  Конец  Размер  Тип      Файловая система  Флаги
 1     33,6MB  302MB  268MB   primary
 2     302MB   495GB  495GB   primary


Код: [Выделить]

$ mount | grep sdd
/dev/sdd2 on /mnt/sdcard type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)

exfatfsck не имеет ключа -v

Код: [Выделить]

$ sudo fsck.exfat -n /dev/sdd2
exfatfsck 1.3.0
Checking file system on /dev/sdd2.
ERROR: bad date 1980-00-00.
ERROR: bad date 1980-00-00.
ERROR: bad date 1980-00-00.
WARN: volume was not unmounted cleanly.
File system version           1.0
Sector size                 512 bytes
Cluster size                512 KB
Volume size                 461 GB
Used space                  364 GB
Available space              97 GB
ERROR: bad date 1980-00-00.
# тысячи повторов #
ERROR: bad date 1980-00-00.
Totally 1178 directories and 46609 files.
File system checking finished. ERRORS FOUND: 47783, FIXED: 0.
Нашел информацию, что ошибка связана с битмапом свободного места, и по состоянию на 2018 год решением было либо форматирование, либо проверка виндой.
https://ubuntuforums.org/showthread.php?t=2388105
Исходников на свежий chkdsk от майков я, конечно, не нашел, да и вряд ли портирую его на линуксы и ARM, так как никогда не прогал под винду.
Форматирование и Windows не подходят, так как девайсы не позволяют извлечь карту памяти, как и забекапить куда-то данные.
Пользователь добавил сообщение 02 Мая 2024, 13:44:50:Проверил trim - карточка не поддерживает, разве что CMD32-38 (Erase) можно отправить.

Пользователь добавил сообщение 02 Мая 2024, 14:20:10:Проблема локализована, повторяется так:
1) Берем любую флешку, форматируем в exFAT. Размер кластера побольше.
2) Копируем большой файл, через 10-15 сек вынимаем флешку.
3) Вставляем снова. Если остался обломок от файла, удаляем его (не в корзину).
Готово, теперь поведение как у меня на работе - 0 файлов, 0 папок, занято 25%. Fsck не исправляет.

В душе не знаю, что дальше. Курить спеки на exfat и писать свою утилиту исправления...

[ALiEN]

2) Копируем большой файл, через 10-15 сек вынимаем флешку.

на-горячую что-ли? Без umount'a? Ну эдак на любой ФС будут непредсказуемые глюки.

[pavel-kv]

ALiEN, это просто способ повторить, что там произошло. Под вопросом не то, что горячее извлечение (а в случае с нашими девайсами это аварийная перезагрузка из-за каких-то проблем) вызывает повреждение ФС, а то, что ни перемонтирование, ни очистка (типа rm -rf *), ни даже fsck ничего не могут с этим сделать.
Да, отличным выбором было бы использовать Ext4 или на худой конец LittleFS, но мои же исследования показали, что журналируемые ФС не подходят в среде, где идёт мелкоблочная запись на пределе производительности носителя.

[БТР]

журналируемые ФС не подходят

Журнал на ext4 можно отключить.

[ALiEN]

журналируемые ФС не подходят в среде, где идёт мелкоблочная запись на пределе производительности носителя.

XFS, JFS не журналируют данные. Только метаданные.
Про JFS пишут что она расходует CPU меньше других ФС

Журнал на ext4 можно отключить.

Лучше тогда сразу в ext2 форматировать)
Пользователь добавил сообщение 02 Мая 2024, 16:01:09:

FUSE exfat 1.3.0

поддержка exfat включена в ядро с версии 5.7. Может, получше будет.

[pavel-kv]

Попробовал последний exfatprogs 1.2.2-1, в нем появился флаг -s, восстанавливающий файлы, "потерянные" вышеописанным образом, а главное, исправляющий таблицу на предмет занятого незанятого места.
Это сработало на карте памяти с прода.

Ну что ж, буду его портировать в bare-metal среду. Это всяко проще, чем ковырять виндовый код или изучать подкапотку exFAT и писать с нуля.

Насчет Ext2, JFS и других - на старте проекта я многое попробовал, и даже без журнала ext ФС были крайне неторопливы. Оно может и заработало бы, если бы обеспечивался нормальный файловый и низкоуровневый кеш, но там ОЗУ дай бог 300 КБ. А файлов открыты десятки одновременно, общая скорость записи около 10 МБ/с, IOPS на пределе карточки. Лишнее прерывание потоковой последовательной записи вызывало неприемлемые задержки (карточки так себе по случайному доступу, а запись вообще не зависит от размера чанка, всегда примерно 100-200 мс).
В общем, лучше всего подошли родственники FAT с преаллокацией и огромные кластеры (чтобы не требовалось выделять еще один в процессе записи, тогда всё затыкается). А отсутствие журнала компенсировали мягким "завершением работы" с размонтированием. Но иногда вот сбоит.

Да, городить поддержку SATA/PCIe и их накопителей выходило сильно дороже, как минимум не нужен контроллер с LVDS шинами.