# Alternative to MTP: USB Mass Storage

It has been discussed in other threads, but it seems that it did not make it as feature request: I'd like to access the internal SD card, as well as the additional SD card as USB mass storage device and not as MTP device. Just as it was possible on the N9.

When connecting with USB we are asked with which mode we'd like to connect (PC connection, developer, ...). I'd like to see one more option: Mass Storage.

I know that there are so called alternatives, like SCP or Rsync when using the developer mode, but I personally think that these are no real alternatives to the plain old USB mass storage connection.

edit retag close delete

I'd be interested to use it for mounting disk images as usb storage. Same as DriveDroid does on Android.

( 2014-01-04 15:11:19 +0200 )edit
1

I would also like to see mass storage implemented, even if only for the external sdcard. MTP might seem like an alternative, but this neglects the many devices which don't (and might never) support MTP, e.g. TV's, DVD players, routers, printers, etc. Mass storage basically transforms your phone into

( 2014-01-26 20:03:40 +0200 )edit
1

a 'regular' USB-stick, which is the most common format for data interchange, and supported by the largest set of devices.

( 2014-01-26 20:04:46 +0200 )edit
1

afaik when using usb mass-storage there cannot be concurrent access on the device. On the N9 it meant you couldn't access your files on the phone while connected using usb mass-storage. I can certainly understand why Jolla choose mtp, as it doesn't have these issues. But then again isn't Jolla using btrfs? In which case a temporary snapshot could perhaps be served over USB Mass Storage.

( 2014-02-03 21:27:15 +0200 )edit
1

@avdwoude I think if the mass storage is emulated, there shouldn't be a problem with concurrent access, should there?

( 2014-05-22 16:32:29 +0200 )edit

Sort by » oldest newest most voted

The internal SD card will never be exportable over mass storage. There are several reasons:

• There is no single "user data" partition as it was on the N9 (MyDocs) containing the Music, etc. folders. Rather, these are part of the /home partition, and this cannot be unmounted at all.
• The \$HOME partition is in btrfs, not FAT, so Windows/OSX won't make use of it.
• Exporting this btrfs volume risks bricking the device (because if you export it via mass storage you would be able to delete the recovery stuff). For this reason alone I suppose Jolla will never do it.

I can only applaud these decisions because what the N9 (and the N900) did -- splitting system and "user data" into two partitions, with the user data one being FAT for Windows to "peruse" -- was a major source of problems. E.g.

• Why does it say I've run out of free space when I still clearly have more than 30GB free?! (you ran out of space in the system partition, not in the MyDocs one).

• Why can't I use the RSS reader/Maps application/my favourite game/etc when I connect the N9 to the PC? (these programs put their data on the MyDocs partition in order to save valuable system partition space -- so they won't work when the user data partition is exported via USB Mass Storage)

Additionally, using FAT means a bunch of problems, including performance, long file names, and locale/charset ones.

Technically, exporting the externalSD card is possible. I suspect nothing prevents Jolla from adding this in a future upgrade. In fact, it is probably already working if you're comfortable with scripting: http://forum.xda-developers.com/showthread.php?t=1768752 (Note: do not blindly follow these steps -- at least the path where the SD card is mounted is different on Jolla, and possibly the block device node too)

However, in https://together.jolla.com/question/9816/use-alternative-file-systems-for-sd-card/ I am arguing that, because USB mass storage plainly sucks and is not used in Jolla, the requeriment for the SD card to be formatted in FAT should be dropped. This way we can gain some benefits from using alternate filesystems. For example, automatically using the SD card for installing additional programs. You can still export the storage via MTP, Samba, NFS, or SFTP.

Even Android is these days moving away from mass storage. I am not sure if MTP is the answer (albeit it seems to be one of the few ones that works with Windows). But I believe that we should try to improve support for MTP and other alternative methods rather than falling back to Mass Storage.

more

I miss mass storage to and having read tobru's a short Jolla review (thanks Tobias!) I came to upvote for USB mass storage. But I upvoted avispedro's answer - after years of frustration with partly unusable devices -maps/N900, absurd data storing to phone memory/E7/808- I am just glad, that is over.

( 2014-01-05 13:31:17 +0200 )edit
4

This is a very good explanation, thanks a lot. It makes it much easier to understand why there is no mass storage option available. I'll mark this as the resolving answer.

( 2014-01-05 18:20:34 +0200 )edit
2

This finally is a good explanation of the reasoning against usb mass storage.I'm still not happy without it but now i can at least accept it as reasonable. Thanks for the explanation!

( 2014-01-05 21:21:06 +0200 )edit
1

Even Palm OS 5 was supporting Mass Storage via third party apps. Indeed, that was emulated by a third party software.

( 2014-01-13 14:36:53 +0200 )edit
1

@Khertan: I wrote one of the Palm T|X mass storage "emulators" (so I'm wearing my "PalmOS expert" hat). They do not emulate anything at all. They really unmount the SD card and export it.

Other than that there were some RAMDisk programs (which on the Palm, with RAM being persistent, they are more or less loop image files).

( 2014-01-13 14:53:13 +0200 )edit

THIS IS NOT AN OFFICIAL JOLLA SUPPORTED METHOD. USE AT YOUR OWN RISK!

ONLY DO THIS IF YOU KNOW WHAT YOU ARE DOING!

* END OF BIG RED BLINKING WARNING!!!!*

The following instructions will give you RW mass-storage on your device. You need to have developer mode enabled to do this.

as nemo :

dd if=/dev/urandom of=mass-disk bs=1024K count=100 mkdir usb-disk

as root (devel-su):
vi /etc/usb-moded/mass-storage-info.ini

content:

[mountpoints]
mount=/home/nemo/mass-disk

Then: vi /etc/usb-moded/dyn-modes/mass_storage_android.ini

contents:
[mode]
name = mass_storage
module = none
mass_storage = 1

Now. Since we cannot make a vfat device on the device we need to use a pc.
First we need to have usb-moded read the new modes in and the UI to read them, so reboot.
Then plug in and see there is a mass-storage option if you have the settings on ask. This will give you a blank mass-storage device on the pc side.

dmesg shows this:
[1045849.351805] usb 3-2: Product: Sailfish
[1045849.351806] usb 3-2: Manufacturer: Jolla
[1045849.351807] usb 3-2: SerialNumber: DU3AM00210
[1045849.352850] scsi46 : usb-storage 3-2:1.0
[1045850.349140] scsi 46:0:0:0: Direct-Access Linux File-CD Gadget 0000 PQ: 0 ANSI: 2
[1045850.349828] sd 46:0:0:0: Attached scsi generic sg1 type 0
[1045850.352261] sd 46:0:0:0: [sdb] Attached SCSI removable disk

Here it is sdb, might be different for you.

sudo fdisk /dev/sdb (It will give you a warning)

Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0x457c7be0.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): p

Disk /dev/sdb: 104 MB, 104857600 bytes
4 heads, 50 sectors/track, 1024 cylinders, total 204800 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0x457c7be0

Device Boot Start End Blocks Id System

We see it is the same size as we created earlier.

Now we format it. (or other format of choice, I only tried vfat)
sudo mkfs.vfat /dev/sdb -I

Unplug and replug (ignore the error for now) and see an empty vfat partition appear.

Now we fix the error shown on the UI, and at the same time make sure we can use the data in that parition on the phone.

Unplug and back to developer mode

Edit /etc/fstab and add this line:
/home/nemo/mass-disk /home/nemo/usb-disk auto rw,nosuid,nodev,users,umask=0000 0 0`

This will remove the warning and make all the files on your usb disk visible to the OS. So you can store music on it and have it play in your car stereo with mass-storage, and when unplugged from your phone.

There, you should be done. If you want a bigger disk, increase count (100 gives you about 100Mb, so 1000 => 1GB, ...)
You can format it with another fs (ext4, ext3 and btrfs should work)

And again. At your own risk!

more

1

That is a pretty smart hack. Would be lovely to have this builtin (off by default). It would be especially nifty if discard works with loopback (vfat supports it) and it can punch holes through btrfs files. Would need to do fstrim before re-mounting on jolla, I suppose. That way, you could make an 8GB or whatever vfat image and the backing file would grow and shrink as needed. Mass storage may suck, but it's sort of a lowest common denominator: it basically works with everything.

( 2014-05-23 01:12:38 +0200 )edit

@mornfall: Thanks! Actually it is built-in, you just need to add the right config and the disk image. Usb_moded can do quite a lot with regards to the USB handling, just check the docs and git (there are more goodies hidden :)

( 2014-05-23 01:24:21 +0200 )edit
1

Nice I was waiting for this!:) Is it also possible to activate the mass-storage for the SD-card instead the nemo partition? And how to do this? :)

Edit: And if it is possible: Would this also work if I format my SD card as exFAT (with e.g. this package) and enable this mass-storage to my SD card to be able to move files bigger than 4GB?

( 2014-05-23 08:11:55 +0200 )edit
1

What I meant with builtin was "does not require a HOWTO with huge warning signs", sort of. :-) A gui toggle (or a numeric field for the size, defaulting to 0) would be even better. I understand usb_moded as such is around by default.

( 2014-05-23 09:57:19 +0200 )edit
1

@mornfall: Well the warning is there just to make sure that in the really remote case something goes wrong Jolla does not get blamed. To make a GUI and have this working reliably without human intervention is a huge job (despite the instructions being so simple). I decided to share this hack so people/community could take it and use it if they need it. Or even develop their own solution based on the idea.

( 2014-05-23 11:55:33 +0200 )edit

Please do consider using MTP. Providing raw mass storage access to the SD card (or worse, to internal storage) is dangerous for the device's file system.

Consider this: A user copies a large amount of files to your device's internal storage, then un-plugs (i.e. no "safe remove") when the file copy progress on her host claims that it's done. Of course it's not; the host's VFS layer will cache the writes, and the host will still want to write files, and - worse - file system metadata. You will end up with a broken file system. On your mobile phone. Please, let's not go there.

I'm really glad that USB mass storage for accessing file systems on embedded devices is a fading trend. Providing raw block I/O access to embedded storage disables concurrent access (i.e. device-local and remote end) by design. Also, considering all the buffers and file system metadata that needs to be maintained and written by the remote end, and adding the fact that users love to un-plug devices without prior sync, will have you end up with inconsistent file systems by default. It's a real nuisance which requires a lot of device-side extra care. I won't even start to mention less-than-perfect host-side implementations of the file systems on the corresponding embedded storages. Or the complete lack of an implementation, even (think BTRFS on mac/windows, and yes, those are potential Jolla users, too). It is a good thing MTP is around. It's the host-side implementations (primarily on Linux) that cause problems.

If you're on Linux, check out simple-mtpfs; yes, it's only FUSE, but it seems to be quite fast and reliable. If your distribution does not ship the tool, here it is: https://github.com/phatina/simple-mtpfs.

more

"simple-mtpfs", For the reliable part you can still pray ...

( 2014-01-13 14:37:59 +0200 )edit

The draw back with MTP is that it's quite slow and there is no good client for GNU/Linux. The only things that really works on all devices today is masstorage, sure it has it's limitation as it is today, but thinking a bit out of the box, it would be possible to make a well working solution.

( 2014-05-23 20:24:22 +0200 )edit

The problem with USB Mass Storage is that you need to unmount the storage first because you can not mount ordinary filesystems more than once at a time on different computers (And the Jolla is a computer). Before you can unmount the storage you need to close all open files on it, so you have to close (or force close) running applications upon connecting USB Mass Storage.

I don't like MTP either, but I suppose it is the best solution at the moment (I'm a Linux-User, I just took scp/rsync).

more

2

In know, but the N9/MeeGo/Harmattan engineers somehow managed to do this. When connecting the N9 as mass storage, the SD cards are unmounted and in some applications, like the media player, a message appears that the mass storage is not available at the moment.

( 2014-01-04 15:04:10 +0200 )edit

Could work for the SD-Card but not for the internal storage, on my Jolla /dev/mmcblk0p28 is 14GB and used for / (as btrfs, Windows and OSX can't handle btrfs)

On the N900, there were separate partitions for the system and user data (with vfat). I don't own an N9, therefore I can't comment on that.

( 2014-01-04 15:23:20 +0200 )edit

You can mount any filesystem as many times as you wish with the option: --bind or -o bind.

You cannot have raw access to a block device, which is the real issue here, but yuu can if you emulate the device, so that shouldn't be a problem either

( 2014-05-22 16:38:47 +0200 )edit

Mass storage has been working better for a long time for all devices I have owned than MTP currently is for my Jolla. MTP is hackish on lots of linux distros, does not work out of the box on OSX and I have my doubts that it will work flawless on windows. Also, what is the benefit of a 32GB card if file copying is slow with MTP, as people claimed. SE and Nokia were somehow always able to give access to at least the SD Card, which is enough for most people and dumb devices, like TVs, car radios, etc.

( 2014-12-09 10:40:32 +0200 )edit

Duplicate of https://together.jolla.com/question/1480/unable-to-access-internal-storage-or-sdcard-using-usb/ which also has an answer regarding how to access the SD card.

more

I don't agree, this topic is different: It's not the question how to access the SD card, it's a feature request. So please remove the duplicate message and reopen it for discussion. Thanks.

( 2014-01-04 15:32:52 +0200 )edit

You are able to discuss it at this answer which is almost the same as the one you got from @Cmdr_Zod

I'm just trying to keep this place from getting too filled with similar questions/answers

( 2014-01-04 15:58:15 +0200 )edit

Besides that the developers are aware of it. There was - another - question about it, where I believe it was @Stskeeps who mentioned that it is caused partly by a not-so-good decision on how the internal SD card is formatted; or something like that :) I can't find it atm.

( 2014-01-04 16:03:55 +0200 )edit