[Galaxy S III Android Development] d4fseeker:
The following currently is a research-only project without any working implementation.

It's a known fact that the S3 uses EXT4 for it's internal filesystem, this including the (shared) data and storage partition.

As a result it's only possible to access the device through MTP protocol on most computers and devices. However this intermediary protocol has several important drawbacks:

- Very slow compared to mass storage mode since no direct access to the block device is given

- The phone cannot be used while data is being transferred

- Many appliances with USBhost-capability are only able to use mass-storage devices, not MTP or PTP.

On the other hand we won't want to use a broken-by-design, old and slow filesystem such as Samsung's RFS (glorified FAT32) for internal storage and cripple our phoone.

After some reading and research, I've come to the conclusion that it's possible to wrap a full-fledged FAT32-formatted virtual block device around a mounted filesystem (or any given folder within it) and then export this 'new' device through the s3c-gadget lun so that the host(computer) can mount it. Altough it may even be (much) slower than MTP it will come without any of the other drawbacks. (However it will prove difficult to solve or bypass the issue of concurrent drive access which is an entirely different issue)

There is a Linux- (and by extension also Android-) kernelmodule called NBD (Network Block device) which allows a TCP/IP-capable software to simulate a block device. The protocol is quite simple and straight-forward; Description

For our usage, depending on the implementation, a patch similar to this one may be necessary to prevent the kernel from deadlocking.

Since the FAT32 filesystem is opensource we can now simulate a FAT table and storage location.

FAT32 descriptions can be found:

Very good explanation

Other less-graphical description

Official Microsoft description

At a first implementation stage, one could/should use a given folder of the filesystem and have the provider-application scan it recursively. Based on the gained informations and the FAT32-specification we are now able to build an I-Node location structure which, internally, stores the real filepath in the underlying ext4 filesystem.

When the FS is mounted in the computer, it will read the I-Nodes and attempt to access a range in the virtual storage location which can be translated back to a file, part of a file, several files, no content (0's) or a combination of those.

A first implementation should, to not overcomplicate things, only provide Readonly access.

Possible implementation issues so far:

- When files are modified in the EXT4 filesystem our master process is not aware of these changes. And even if he was, the computer (which caches certain used blocks of the disk and does not expect them to change without having issues corresponding actions) will not know about them.

- The FAT32 system must know the location and contents of any given I-Node since the filesystem might choose to read-ahead in the structure. Thus we WILL need to scan the whole directory hierarchy at each startup. This load may be lessened by keeping a persistent database (SQLite) of all found files and just refresh the folders which have a changed directory mtime. Most folders only very rarely change.

What do you think about this idea/research and are there any show-stopping issues/problems you'd expect to come up?

If it really works as described this _could_ be a (cpu-wise and memory-wise costly) method for allowing forward-going progress in filesystem architecture while not breaking backward-compatibility with the widely-supported FAT32 in mass-storage mode.