On a133p TrimUI systems (brick, Smart Pro), muOS uses the FUSE filesystem for accessing the sdcard if it’s formated exfat. This results in constant OS hangs under large I/O where the kernel locks up and only a hard reboot can be performed. Here’s the cause:
- When a lot of I/O is performed, the kernel expands it’s buffers/cache memory usage to fill available RAM, especially if a slow sdcard can’t keep up with write veolcity.
- At a certain point, the kernel decides to commit that write buffer, such as when files are created or shell redirects are encountered.
- Since the FUSE filesystem is in userspace, the kernel informs it that it needs to do a BIG write.
- The FUSE filesystem then has to malloc a ton of space to ingest the buffers/cache but there’s not enough RAM so the malloc fails.
- The kernel freaks out that RAM is tight so it decides to flush all pending writes.
- GOTO 3
So what’s the solution? Normally there isn’t kernel-level exfat support in 4.X kernels in linux, but it just so happens that the a133p has some Samsung patches that enable it. There’s no need to use FUSE at all. On standard muOS install for a133p, /sbin/mount.exfat is symlinked to /mount/exfat-fuse but you don’t need to do that. To test, just rm -f /sbin/mount.exfat
Yes I know that sounds insane but the muOS scripts all invoke mount -t exfat and if there’s no helper binary it just uses the regular kernel driver and viola … no fuse.
Anyways, I’m not sure what the best solution to this is, so I just want to kindly request that the good muOS developers stop using FUSE on a133p and stop symlinking mount.exfat to the fuse version. Thanks!
