exFAT microSD card access very slow

fbakan · February 25, 2025, 4:32pm

Hi,
I have a 256GB SanDisk Ultra connected to the ThinkPad T490 microSD-card slot
(tried also connect via external USB2.0 Cardreader but this makes no difference)
Reading or writing files from/to the disc seems normal, but opening
the disc and get the directories listed (first time only) is extremely slow.
Also getting the ‘properties’ of the disc takes about 1 hour.
(but after this process all directories open immediatly)
The disc contains about 25000 mp3 files in about 2200 directories,
110 GB used, 128 GB free

fsck.exfat says ‘clean’

accessing the directories with windows 11 works without this initial delay,
so I don’t think it’s a physical problem of the card.

exfatprogs gives this info:

# dump.exfat /dev/mmcblk0p1
exfatprogs version : 1.2.7
-------------- Dump Boot sector region --------------
Volume Length(sectors): 		499679232
FAT Offset(sector offset): 		32768
FAT Length(sectors): 			32768
Cluster Heap Offset (sector offset): 	65536
Cluster Count: 				975808
Root Cluster (cluster offset): 		4
Volume Serial: 				0x64643438
Bytes per Sector: 			512
Sectors per Cluster: 			512

----------------- Dump Root entries -----------------
Volume label entry position: 		0x20801a0
Volume label character count: 		5
Volume label: 				Musik
Upcase table entry position: 		0x2080020
Upcase table start cluster: 		3
Upcase table size: 			5836
Bitmap entry position: 			0x2080000
Bitmap start cluster: 			2
Bitmap size: 				121976

---------------- Show the statistics ----------------
Cluster size:  				262144
Total Clusters: 			975808
Free Clusters: 				531785
# fsck.exfat /dev/mmcblk0p1
exfatprogs version : 1.2.7
/dev/mmcblk0p1: clean. directories 2525, files 22396

Is this a known problem? / Is there anything I could try to solve the problem?

Franz

myswtest · February 26, 2025, 12:19pm

Yea, I have a similar experience. I mostly use:

SanDisk Ultra Dual Drive Go USB Type-C Flash Drive

… so not a microSD type.

It has USB Type-C and USB Type A connectors … you can rotate the body to use whichever you need to connect. We mostly use these to backup our smartphones (USB C). They are default formatted with exFAT filesystem.

Anyway, yea, if I plug it into my Dell laptop (running Leap 15.6), mount it, then do a “Properties” selection … it takes a very long time to calculate the storage used.

I clicked on “Stop” after 15 minutes and it was barely 1/3 of calculating the total usage. (using Dolphin on my Plasma KDE desktop).

The problem is, for an accurate file and directory count, plus overall drive stat, a complete scan of the device is required. These devices are not speedy, access-wise

Svyatko · February 26, 2025, 12:45pm

Do not calculate properties of folders (number of elements, etc.). Use simple file browser.

fbakan · February 26, 2025, 1:48pm

Hi,
sure i could avoid ‘properties’ but that’s not a solution.
Describing what happens when I open properties was more
meant as an example for the problem.

My directory structure is like this:

A
AA
BB
AB
AC
…
B
AB
AC
CD
…
C
…

When I open A it takes about 30 seconds if A contains 30 directories
so about 1 second delay for every directory when accessing for the first time.
I think this is not normal and I suppose there is some bug/missing feature
in the exFAT filesystem driver in linux or there is a misconfiguration in tumbleweed.

Franz

marel · February 26, 2025, 8:09pm

Not easy to interpret the results but in this strace could help

strace -t -T -f -o strace.log <command to access the microSD>

That likely gives the system call that takes very long time the first time.

You can share the strace.log here using https://paste.opensuse.org/

fbakan · February 26, 2025, 9:23pm

ok,
after entering the directory L I executed
strace -t -T -f -o strace.log ls
There was no delay to get the directory listed,
but when I then immediately afterwards executed
ls
(without strace -t -T -f -o strace.log in front)
it took about 30 seconds to get the result
very strange…
subsequent executions of ls
worked without delay.

I uploaded strace.log to paste.opensuse.org

Franz

marel · February 26, 2025, 9:28pm

An strace log file without the delay is not really worth to have a look at but it can be nicely used to diff against a log with the problem.

So please try some more to get a strace log where you capture the ~30 seconds delay.

I uploaded strace.log to paste.opensuse.org

I believe you but can you share the link where we can find it? That should be something like

https://susepaste.org/293ece675a70

fbakan · February 26, 2025, 9:55pm

https://paste.opensuse.org/pastes/886e2a82a6cc

I’ll try to get the delay using strace…

Franz

fbakan · February 26, 2025, 10:13pm

sorry no idea to get the delay when using strace
without strace the delay is easy to reproduce.
a simple cd can also reproduce the delay, but

strace -t -T -f -o strace.log cd O only produces
strace: Cannot find executable 'cd'

Franz

fbakan · February 26, 2025, 10:55pm

Using
strace -t -T -f -o strace.log ls -la
I get at least some suspicious delay. I uploaded the diff
between the first and the second call of the same command to

https://paste.opensuse.org/pastes/8a8699929621

Perhaps this gives a hint
Franz

marel · February 27, 2025, 7:33am

For this kind of log it is better to upload the two logs instead of a diff as I typically do some pre-processing on the logs to make the easier to compare. I also use an editor with good colour highlighting.

Still the diff file is useful as 100% is different (because of the timestamps and PID’s) so I did split it in two and used that.

Log1 is from 23:32:07 to 23:32:07, I guess that is long
Log2 is from 23:32:58 to 23:32:58, that is short

If you look at the timestamps of Log1 you see that there are significant delays getting the directory entries, for example:

23:32:13 statx(AT_FDCWD, "Artist 1", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW|AT_NO_AUTOMOUNT, STATX_MODE|STATX_NLINK|STATX_UID|STATX_GID|STATX_MTIME|STATX_SIZE, {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFDIR|0755, stx_size=262144, ...}) = 0 <0.950309>
23:32:14 llistxattr("Artist 1", "", 152) = 0 <0.000093>
23:32:14 statx(AT_FDCWD, "Artist 2", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW|AT_NO_AUTOMOUNT, STATX_MODE|STATX_NLINK|STATX_UID|STATX_GID|STATX_MTIME|STATX_SIZE, {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFDIR|0755, stx_size=262144, ...}) = 0 <2.490539>
23:32:17 llistxattr("Artist 2", "", 152) = 0 <0.000168>
23:32:17 statx(AT_FDCWD, "Artist 3", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW|AT_NO_AUTOMOUNT, STATX_MODE|STATX_NLINK|STATX_UID|STATX_GID|STATX_MTIME|STATX_SIZE, {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFDIR|0755, stx_size=262144, ...}) = 0 <0.059748>
23:32:17 llistxattr("Artist 3", "", 152) = 0 <0.000154>

For what takes a long time you can scroll to the end of the line and see it is the statx that takes a long time:

23:32:14 statx(AT_FDCWD, "Artist 2", ...}) = 0 <2.490539>

So statx.

No sure now how to get more information, the most likely problem is something is wrong/slow with the microSD. What would be good if you can capture a problem once more to see if the problem happens always with the same directory entries that will narrow down the problem.

fbakan · February 27, 2025, 9:09am

Thank you marel for looking into the issue!

Here the problem captured once more:

first call of ls -la openSUSE Paste
second call of ls -la openSUSE Paste

Franz

fbakan · February 27, 2025, 3:20pm

Hi,

two more logfiles that may help to figure out the reason for the delays

I started

strace -p 36170 -t -T -f -o first-ls.log

(https://paste.opensuse.org/pastes/5fcf607a3ce8)

as SU in a second terminal and then executed

ls

in the first terminal (PID 36170)
and waited (about half a minute) until ls showed it’s result

Then I stopped strace and started it again

strace -p 36170 -t -T -f -o second-ls.log

(https://paste.opensuse.org/pastes/64438ad72b83)

and executed ls again. After this second execution I get the directory listed
without any delay.

Franz

marel · February 27, 2025, 9:46pm

Puzzling logs: The last two logs run as su are much larger then the logs before and I see nothing that looks like retrieving the directory.

I did compare your two “slow” logs and what I do not get is that not the same entries are read:

What is before this screenshot is largely the same and is running normal, only left reads 38 directory entries, right 84 entries.

The second part of this diff shows ls trying to get the attributes for those directory entries but why is that on the left only for names starting with “b” and on the right names only starting with “c”???

fbakan · February 27, 2025, 10:27pm

I only have the delay when I first ls the directory.
All subsequent ls commands in this directory don’t have the delay.
Even when I leave the directory and enter again.
So to get two slow logs I have to ls in different directories. That’s why the left side contains the directories starting with B and the right the ones starting with C.
If I should reproduce the delay in the same directory I would have to eject the microSD card and attach it again.

myswtest · February 27, 2025, 10:53pm

No doubt because it’s cached during the “1st”.

fbakan · February 27, 2025, 11:23pm

In both large logs you find
read(11, "\0\33[0m\33[01;34mFado_Ao_Centro\
Fado_Ao_Centro This is name of the first directory in the F dircetory

The ppoll(... call 2 lines above seems to take 32.759005 seconds in the slow log.

Svyatko · February 28, 2025, 1:29pm

Which T490?
Post

inxi -aFz

Use USB 3.x devices.

fbakan · March 1, 2025, 4:41pm

System:
  Kernel: 6.13.4-1-default arch: x86_64 bits: 64 compiler: gcc v: 14.2.1 clocksource: tsc
    avail: acpi_pm parameters: BOOT_IMAGE=/boot/vmlinuz-6.13.4-1-default
    root=UUID=abcad866-1203-4079-9780-67c761dab959 splash=silent quiet security=apparmor
    kvm.enable_virt_at_load=0 mitigations=auto
  Console: pty pts/1 DM: LightDM v: 1.32.0 Distro: openSUSE Tumbleweed 20250227
Machine:
  Type: Laptop System: LENOVO product: 20N3S5DV0Y v: ThinkPad T490 serial: <filter> Chassis:
    type: 10 serial: <filter>
  Mobo: LENOVO model: 20N3S5DV0Y v: SDK0J40697 WIN serial: <filter>
    part-nu: LENOVO_MT_20N3_BU_Think_FM_ThinkPad T490 uuid: c944354c-30d2-11b2-a85c-e54993742b40
    UEFI: LENOVO v: N2IETA5W (1.83 ) date: 06/20/2024
Battery:
  ID-1: BAT0 charge: 40.1 Wh (100.0%) condition: 40.1/50.5 Wh (79.3%) volts: 12.8 min: 11.6
    model: LGC 5B10W13905 type: Li-poly serial: <filter> status: full cycles: 449
CPU:
  Info: model: Intel Core i5-8265U socket: BGA1528 (U3E1) note: check bits: 64 type: MT MCP
    arch: Comet/Whiskey Lake note: check gen: core 8 level: v3 note: check built: 2018
    process: Intel 14nm family: 6 model-id: 0x8E (142) stepping: 0xC (12) microcode: 0xFC
  Topology: cpus: 1x dies: 1 clusters: 4 cores: 4 threads: 8 tpc: 2 smt: enabled cache:
    L1: 256 KiB desc: d-4x32 KiB; i-4x32 KiB L2: 1024 KiB desc: 4x256 KiB L3: 6 MiB desc: 1x6 MiB
  Speed (MHz): avg: 400 min/max: 400/3900 base/boost: 1600/1800 scaling: driver: intel_pstate
    governor: powersave volts: 0.9 V ext-clock: 100 MHz cores: 1: 400 2: 400 3: 400 4: 400 5: 400
    6: 400 7: 400 8: 400 bogomips: 28800
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  Vulnerabilities:
  Type: gather_data_sampling mitigation: Microcode
  Type: itlb_multihit status: KVM: VMX disabled
  Type: l1tf status: Not affected
  Type: mds status: Not affected
  Type: meltdown status: Not affected
  Type: mmio_stale_data mitigation: Clear CPU buffers; SMT vulnerable
  Type: reg_file_data_sampling status: Not affected
  Type: retbleed mitigation: Enhanced IBRS
  Type: spec_rstack_overflow status: Not affected
  Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl
  Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2 mitigation: Enhanced / Automatic IBRS; IBPB: conditional; RSB filling;
    PBRSB-eIBRS: SW sequence; BHI: SW loop, KVM: SW loop
  Type: srbds mitigation: Microcode
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: Intel WhiskeyLake-U GT2 [UHD Graphics 620] vendor: Lenovo driver: i915 v: kernel
    arch: Gen-9.5 process: Intel 14nm built: 2016-20 ports: active: eDP-1 empty: DP-1, DP-2,
    HDMI-A-1, HDMI-A-2 bus-ID: 00:02.0 chip-ID: 8086:3ea0 class-ID: 0300
  Device-2: IMC Networks Integrated Camera driver: uvcvideo type: USB rev: 2.0 speed: 480 Mb/s
    lanes: 1 mode: 2.0 bus-ID: 1-8:5 chip-ID: 13d3:56bc class-ID: 0e02 serial: <filter>
  Display: x11 server: X.org v: 1.21.1.15 compositor: xfwm4 driver: X: loaded: modesetting
    unloaded: vesa alternate: fbdev,intel dri: iris gpu: i915 tty: 132x50
  Monitor-1: eDP-1 model: InfoVision Optronics/Kunshan 0x057d built: 2018 res: 1920x1080
    dpi: 158 gamma: 1.2 size: 309x174mm (12.17x6.85") diag: 355mm (14") ratio: 16:9 modes: 1920x1080
  API: OpenGL Message: GL data unavailable in console for root.
  API: Vulkan v: 1.4.304 layers: 1 device: 0 type: integrated-gpu name: Intel UHD Graphics 620
    (WHL GT2) driver: N/A device-ID: 8086:3ea0 surfaces: N/A
  Info: Tools: api: glxinfo,vulkaninfo de: xfce4-display-settings x11: xprop,xrandr
Audio:
  Device-1: Intel Cannon Point-LP High Definition Audio vendor: Lenovo driver: snd_hda_intel
    v: kernel alternate: snd_soc_avs,snd_sof_pci_intel_cnl bus-ID: 00:1f.3 chip-ID: 8086:9dc8
    class-ID: 0403
  API: ALSA v: k6.13.4-1-default status: kernel-api with: aoss type: oss-emulator
    tools: alsactl,alsamixer,amixer
  Server-1: PipeWire v: 1.3.83 status: n/a (root, process) with: 1: pipewire-pulse
    status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin 4: pw-jack
    type: plugin tools: pactl,pw-cat,pw-cli,wpctl
Network:
  Device-1: Intel Cannon Point-LP CNVi [Wireless-AC] driver: iwlwifi v: kernel bus-ID: 00:14.3
    chip-ID: 8086:9df0 class-ID: 0280
  IF: wlp0s20f3 state: up mac: <filter>
  Device-2: Intel Ethernet I219-V vendor: Lenovo driver: e1000e v: kernel port: N/A
    bus-ID: 00:1f.6 chip-ID: 8086:15be class-ID: 0200
  IF: enp0s31f6 state: down mac: <filter>
  Info: services: NetworkManager,wpa_supplicant
Bluetooth:
  Device-1: Intel Bluetooth 9460/9560 Jefferson Peak (JfP) driver: btusb v: 0.8 type: USB rev: 2.0
    speed: 12 Mb/s lanes: 1 mode: 1.1 bus-ID: 1-10:8 chip-ID: 8087:0aaa class-ID: e001
  Report: btmgmt ID: hci0 rfk-id: 1 state: up address: <filter> bt-v: 5.1 lmp-v: 10 status:
    discoverable: no pairing: no class-ID: 7c010c
Drives:
  Local Storage: total: 715.24 GiB used: 257.37 GiB (36.0%)
  ID-1: /dev/mmcblk0 maj-min: 179:0 model: SD256 size: 238.3 GiB block-size: physical: 512 B
    logical: 512 B type: Removable tech: SSD serial: <filter> scheme: MBR
  SMART Message: Unknown smartctl error. Unable to generate data.
  ID-2: /dev/nvme0n1 maj-min: 259:0 vendor: Innovation IT model: N/A size: 476.94 GiB
    block-size: physical: 512 B logical: 512 B speed: 31.6 Gb/s lanes: 4 tech: SSD serial: <filter>
    fw-rev: T0918A0L temp: 21.9 C scheme: GPT
  SMART: yes health: PASSED on: 62d 18h cycles: 927 read-units: 8,850,368 [4.53 TB]
    written-units: 10,572,919 [5.41 TB]
Partition:
  ID-1: / raw-size: 290.96 GiB size: 290.96 GiB (100.00%) used: 148.72 GiB (51.1%) fs: btrfs
    block-size: 4096 B dev: /dev/nvme0n1p6 maj-min: 259:6
  ID-2: /boot/efi raw-size: 100 MiB size: 99.2 MiB (99.21%) used: 33.7 MiB (34.0%) fs: vfat
    block-size: 512 B dev: /dev/nvme0n1p2 maj-min: 259:2
  ID-3: /home raw-size: 290.96 GiB size: 290.96 GiB (100.00%) used: 148.72 GiB (51.1%) fs: btrfs
    block-size: 4096 B dev: /dev/nvme0n1p6 maj-min: 259:6
  ID-4: /opt raw-size: 290.96 GiB size: 290.96 GiB (100.00%) used: 148.72 GiB (51.1%) fs: btrfs
    block-size: 4096 B dev: /dev/nvme0n1p6 maj-min: 259:6
  ID-5: /var raw-size: 290.96 GiB size: 290.96 GiB (100.00%) used: 148.72 GiB (51.1%) fs: btrfs
    block-size: 4096 B dev: /dev/nvme0n1p6 maj-min: 259:6
Swap:
  Kernel: swappiness: 60 (default) cache-pressure: 100 (default) zswap: no
  ID-1: swap-1 type: partition size: 2 GiB used: 0 KiB (0.0%) priority: -2 dev: /dev/nvme0n1p7
    maj-min: 259:7
Sensors:
  System Temperatures: cpu: 31.0 C mobo: N/A
  Fan Speeds (rpm): fan-1: 0
Info:
  Memory: total: 16 GiB note: est. available: 15.28 GiB used: 2.61 GiB (17.1%) igpu: 64 MiB
  Processes: 278 Power: uptime: 0h 11m states: freeze,mem,disk suspend: deep avail: s2idle
    wakeups: 0 hibernate: platform avail: shutdown, reboot, suspend, test_resume image: 6.1 GiB
    services: upowerd,xfce4-power-manager Init: systemd v: 257 default: graphical tool: systemctl
  Packages: pm: rpm pkgs: N/A note: see --rpm tools: yast,zypper pm: flatpak pkgs: 6 Compilers:
    gcc: 14.2.1 alt: 13 Shell: Sudo (sudo) v: 1.9.15p5 default: Bash v: 5.2.37 running-in: pty pts/1
    inxi: 3.3.37

fbakan · March 1, 2025, 8:32pm

Some more information about the problem:

It’s not a physical problem with the microSD card because the same card connected via USB2.0 using an adapter to my old Thinkpad X32 also running Tumbleweed works without delay. And as I wrote before, using the Card with Windows 11 on the T490 also works without the problem.
Earlier I wrote that a simple cd could reproduce the problem. This is not true. (It’s only true if I use cd in a nortoncommander clone (mc or FC/L) environement probably because this automatically invokes a directory listing). cd in a terminal doesn’t have the delay.
If I call ls via strace (strace -t -T -f -o strace.log ls) there is no delay
If I call ls without the strace -t -T -f -o strace.log in front I get delay
If I call ls via strace (strace -t -T -f -o strace.log ls -la) I also get the delay
delay means about 1 second for every subdirectory. So if I have only two directories listed I have a little bit more than 2 seconds delay, when I have 30 directories there is over 30 seconds delay.
The delay only is present for the first call of ls in each directory I enter after mounting the card.
Using an external USB2 adapter for the card connected to the T490 instead of the internal slot of the T490 doesn’t make a difference. Same delays.
lshw gives the following information:

*-pci:0
   description: PCI bridge
   product: Cannon Point-LP PCI Express Root Port #1
   vendor: Intel Corporation
   physical id: 1c
   bus info: pci@0000:00:1c.0
   version: f0
   width: 32 bits
   clock: 33MHz
   capabilities: pci pciexpress msi pm normal_decode bus_master cap_list
   configuration: driver=pcieport
   resources: irq:120 memory:cd600000-cd6fffff
 *-generic
    description: MMC Host
    product: GL9750 SD Host Controller
    vendor: Genesys Logic, Inc
    physical id: 0
    bus info: pci@0000:01:00.0
    logical name: mmc0
    version: 01
    width: 32 bits
    clock: 33MHz
    capabilities: pciexpress msi pm bus_master cap_list
    configuration: driver=sdhci-pci latency=0
    resources: irq:134 memory:cd600000-cd600fff
  *-device
     description: SD Card
     product: SD256
     vendor: SanDisk
     physical id: aaaa
     logical name: /dev/mmcblk0
     version: 8.5
     date: 03/2023
     serial: 2314306781
     size: 238GiB (255GB)
     capabilities: sd partitioned partitioned:dos
     configuration: logicalsectorsize=512 sectorsize=512
   *-volume
      description: HPFS/NTFS partition
      physical id: 1
      logical name: /dev/mmcblk0p1
      logical name: /run/media/franz/Musik
      capacity: 238GiB
      capabilities: primary
      configuration: mount.fstype=exfat mount.options=rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro state=mounted

Perhaps this info helps to find the culprit…