Not sure if you are confusing nitroFS (more colloquially the DS file system, what you pack into ROMs but can and is often also extensively used in homebrew*) and DLDI (libfat, what you use to access SD cards or possibly NAND in those few, of flash carts. Though technically there is also a method of bundling DLDI reads into a read only nitroFS setup, see FCSR). They speak much the same thing in the end, albeit with DLDI aspects possibly having some extra fun to signal to the flash cart and possibly the flash cart going the other way -- some will in house CRC write verification rather than leaving it to the console).
*some older flash carts having a size limit here as they treated it like a GBA ROM. I tended to encounter it when pointing people at tetris grand masters (a hard to find homebrew port of tetris grand masters by meraman, packed in a bunch of low compression at best background images which knocked it over the limit for some older carts). There was a more recent discussion on its limits as well around here.
On ARM7 stuff I should probably also point at DS video. It is/was a wavelet based compression scheme for video on the DS (pretty good quality actually when compared with moonshell/DPG) that kicked IO and most things to the ARM7 leaving the ARM9 as a workhorse. This included recompiling (sometimes with tweaks) a whole bunch of DLDI patches to use the ARM7 (some of which did go on to do things for the ever rarer GBA DLDI).
I am not sure if multiple reads at once is a reasonable thing to ask of the hardware (DS cart read protocol is fairly single minded/content unaware,
https://problemkaputt.de/gbatek.htm#dscartridgeprotocol ). At best you might have workarounds for known conflicts like identifiers every however many bytes to in turn direct things, or more serious... call it push-pop type setups where things note where they are at every read in case it is interrupted and wants to return. Don't know if DS linux did anything to handle this.
Writing your own code is well within reason though, about the only thing I might note is some older versions of ndstool did not necessarily consider file order like some ROMs do (New Super Mario Brothers being a notable one here, see also history of nitro explorer) but that is maybe less of a concern in this as you would presumably be handling that (in the commercial thing guess it is potentially quicker to say fetch me file 42 than do a lookup and then fetch).
