If you are talking about
SSD patent application in another thread, that is
US20170097897A1 https://patents.google.com/patent/US20170097897A1/en
- that's not actually "file system
internal to the SSD". It's just a custom flash-aware file system on a separate disk or partition. SSDs know nothing about file systems, they work with blocks/sectors.
That figure describes their
software stack for disk access, where the
SSD partiton uses a
custom file system to access read-only, protected game level data. This filesystem makes use of
large 64 KB blocks (clusters), and the NVMe SSD controller supports
hardware decompression of these 64 KB blocks, while contiguous allocation and data compression is handled in the software stack. The latter also implements a
custom lightweight API (i.e. without HDD-based 'abstractions' ) to read data from this SSD partition.
Of course the software stack also supports
standard file systems typical for USB media and optical/hard disk drives
and SSDs, with full read-write access.
If loading times are not improved, which problem this additional RAM actually solves?
First, I doubt the patent will be granted. They basically describe an integrated 4-channel flash memory controller with a NVMe (PCIe) interface, and an address translation layer implemented with multi-core ARM processors and dedicated look-up caches. There are already dozens of such integrated chips from several vendors like Phison, Silicon Motion, Samsung, Intel, SandForce, Marvel, and others.
Also, hardware compression has already been implemented by SandForce and probably a few others, to limited succes; major vendors chose to completely ignore it. Compression can increase read throughput for lower-end flash memory parts, but only as long as your data is compressable with a decent rate. It cannot substitute for flash-aware filesystems and device IO patterns based on large blocks.
And custom API layer for accessing flash memory storage is not such a novelty either.