Formatting SD card as internal unter CM13 MM 6.0.1

[mtrc]

Hallo,

ich möchte das Thema mal einzeln diskutieren, finde leider keinen generellen Thread zum Thema SD als Interner Speicher unter MM, auch nicht auf xda-developers.com, wo wahrscheinlich mehr ROM-Entwickler mitlesen. Meist wird das nur Device-spezifisch besprochen.

Wie ich hier (Titanium Backup Fehler: Nicht genügend freier Speicherplatz) bereits bemerkt habe, scheint das Speicher-Management wenig durchdacht:
Nach dem Lesen von Let's clear up the confusion regarding storage in Android once and for all, including adoptable storage in Marshmallow. • /r/Android wird zwar einiges klarer, es macht auch Sinn, dass nicht ein großer Interner Speicher fusioniert wird aus dem Internen+SD, wie man es z.B. mit einem overlayfs machen könnte...
Man bekommt lediglich einen neuen Mount erstellt unter /mnt/expand:

$ mount |grep dm-
/dev/block/dm-0 on /data type f2fs (rw,seclabel,nosuid,nodev,noatime,nodiratime,background_gc=on,user_xattr,inline_xattr,acl,inline_data,nobarrier,active_logs=6)
/dev/block/dm-1 on /mnt/expand/???18fac-2c42-42af-9c45-4830cdab9??? type f2fs (rw,seclabel,nosuid,nodev,noatime,background_gc=on,user_xattr,acl,inline_data,active_logs=6)

Das bedeutet, man muss immer noch explizit pro App einrichten, dass diese auf die "SD-Karte" verschoben wird, so wie es eigentlich schon sehr lange auf den mobilen Speicher möglich war. Das habe ich schon unter 2.3.7 mit s2e so gemacht. Vorteil ist natürlich, dass die SD-Karte verschlüsselt wird und ein vernünftiges Filesystem erhält. Verschlüsselung war auch mein Anliegen, das überhaupt zu tun.

Möchte man nun große Daten wie Bilder, Musik oder Backups dort speichern, fangen die Probleme an. TitaniumBackup kann dort überhaupt nicht hinschreiben, wie im anderen Thread erwähnt. Andere Apps wie die Kamera können zwar auf Externe SD-Karten schreiben, finden diese aber nicht mehr, weil nicht mehr existent. Wählt man dort nun "Internen Speicher" schreiben diese weiter munter nach /storage/emulated/0 geschrieben, was immer noch der alte Interne Speicher ist, nämlich /data/media/0... Es gibt also keine Möglichkeit mehr, die SD-Karte überhaupt mit diesen Apps zu verwenden. Dabei wurde suggeriert, dass mit einer SD-Karte als Internem Speicher viele Beschränkungen gelockert würden, wie z.B. dass TitaniumBackup nur nach /storage/emulated/0/Android/data/com.keramidas.TitaniumBackup/, aber nicht daneben schreiben darf [1].

 

[ooo]

Titanium Backup schreibt unter CM 13 MM 6.0.1 bei einer adopted SD Card auf die SD Card in ein beliebiges Verzeichnis.

Titanium Backup > Einstellungen > Ort des Sicherungsordners > In Zeile

Speicherorte: <ORT> => ändern <= ​

den Text "ändern" antippen.

​

___

Die Kamera App legt per default die Photos auf der adopted SD Card im Verzeichnis DCIM ab.
(... wenn die Dateien migriert wurden. - Siehe dort Posting #7 für Details ...)

Die genannten Verzeichnisse (unter /data/media/0/) sind nach einer dortigen initialen (Komplett-)Löschung *nicht* mehr unter /data/media/0/ zu sehen bzw. werden dort nicht mehr angelegt (also wird der "echte" interne Speicher nach der Daten-Migration - s. o. - nicht mehr benutzt).

​

___

/sdcard/ bzw. /storage/emulated/0/ *ist* die adopted SD Card, also der identische Speicherbereich (der aktive interne Speicher).

(s. a. Screenshots dazu)

Edit: xda ist inzwischen zu 99 % anstrengende, ineffiziente "Folklore" ohne Nährwert ...

 

[mtrc]

Auf meinem Asus TF700T mit KatKiss (6.0.1) ist es tatsächlich so, dass /storage/emulated/0/ die adopted SD card ist. Auf meinem MotoG2 (thea) hier scheint das nicht der Fall. Oder muss ich immer erst die Daten migrieren?

Ich hab eben ein Foto gemacht, Datei ist hier gelandet:

root@thea:/mnt # find /mnt /storage -name IMG_20160804_073233.jpg  
/mnt/runtime/write/emulated/0/DCIM/Camera/IMG_20160804_073233.jpg
/mnt/runtime/read/emulated/0/DCIM/Camera/IMG_20160804_073233.jpg
/mnt/runtime/default/emulated/0/DCIM/Camera/IMG_20160804_073233.jpg
/storage/emulated/0/DCIM/Camera/IMG_20160804_073233.jpg

root@thea:/ # ls -al /mnt/expand/????8fac-2c42-42af-9c45-4830cdab????/media/0/DCIM
ls: /mnt/expand/????8fac-2c42-42af-9c45-4830cdab????/media/0/DCIM: No such file or directory

Außerdem ist das, was TitaniumBackup hier anzeigt, immer noch der interne Speicher, nicht die SD-Card:

root@thea:/ # ls -al /mnt/expand/????8fac-2c42-42af-9c45-4830cdab????/media/0/
total 72
drwxrwx--- 3 media_rw media_rw 4096 2016-08-03 14:33 .
drwxrwx--- 3 media_rw media_rw 4096 2016-08-03 12:56 ..
drwxr-xr-x 4 root  root  4096 2016-08-03 14:33 TitaniumBackup

 

[ooo]

Oder muss ich immer erst die Daten migrieren?

Ja.

(Von der adopted SD Card aus den Menüpunkt "Daten migrieren" ausführen, holt die *kompletten* Daten vom "echten" internen Speicher auf die SD Card, wenn noch nicht erfolgt. - Auch z. B. das Titanium Backup-Verzeichnis ...)

 

[mtrc]

Zum Thema, ob der echte Interne Speicher danach ungenutzt bleibt.... auf meinem Asus hatte ich mir bisher keine Gedanken darüber gemacht und die SD-Karte als intern formatiert. Dennoch gibt es Apps, die auf dem Internen Speicher liegen und andere, die auf der SD-Karte liegen. Wer entscheidet das? Ich habe hier nicht manuell Apps verschoben.

 

[ooo]

(Anwender-)Daten und Apps (mit deren internen/eigenen Nicht-Anwender-Daten) sind zwei unterschiedliche Dinge. - Diese sind voneinander unabhängig ...

Anwender-Daten werden hier (click) unter Punkt 1. behandelt, die Apps und deren eigenen Daten unter Punkt 2.
(Das ist Android-Standard-Verhalten und hat nichts mit dem Device zu tun. - Hersteller einer ROM können das natürlich "verbiegen", klar ...)

Wo eine App installiert wird, entscheidet die ROM (also Android). - I. d. R. ist das zunächst der "echte" interne Speicher (/data/app/... bzw. /data/data/...). - Bei manchen ROMs hat man einen Menüpunkt dafür, bei Moto-ROMs nicht ...
App Install Location | Android Developers
Installing to SDCard by default

 

[mtrc]

Oder muss ich immer erst die Daten migrieren?

Ja.

(Von der adopted SD Card aus den Menüpunkt "Daten migrieren" ausführen, holt die *kompletten* Daten vom "echten" internen Speicher auf die SD Card, wenn noch nicht erfolgt. - Auch z. B. das Titanium Backup-Verzeichnis ...)

Ok, hat funktioniert.
Nicht nur, dass die Funktion schwer zu finden ist, es ist auch unklar, was dahinter steckt. Ohne diese Aktion nutzt man die SD-Karte nämlich noch gar nicht. Danke Google.

Es wurde tatsächlich einiges umgestellt dadurch. Das scheint nun wirklich meine SD-Karte zu sein:

root@thea:/ # df -h /storage/emulated/0/  
Filesystem  Size  Used Avail Use% Mounted on
/dev/fuse  58G  1.2G  57G  3% /storage/emulated

Worum handelt es sich bei diesem /storage/emulated, wie verweist das auf die SD-Karte und vorher auf den Internen speicher? Es ist weder ein mount noch ein mount-bind noch ein softlink. Dahinter steckt nur ein FUSE fs?

Der echte Interne Speicher ist nun komplett leergeräumt?

# ls -al /data/media  
total 40
drwxrwx---  2 media_rw media_rw 4096 2016-08-04 09:56 .
drwxrwx--x 36 system  system  4096 2016-08-04 07:32 ..

Was genau liegt denn nun noch auf dem Internen Speicher?

# df  -h /data/  
Filesystem  Size  Used Avail Use% Mounted on
/dev/block/dm-0 4.8G  3.1G  1.6G  66% /data

root@thea:/ # du -s /data/* |sort -nr |head  
1851024   /data/app
759756   /data/data
407100   /data/dalvik-cache
13652   /data/system
2112   /data/misc
1284   /data/anr
208   /data/tombstones
168   /data/property
44   /data/local
44   /data/backup

Liegt der Dalvik-Cache einfach mit auf der /data Partition? Hatte der früher nicht eine eigene Partition /cache?
Ist Dalvkik seit Art überhaupt noch verwendet?

Heisst das, die Apps liegen weiterhin auf dem Internen Speicher, wenn man sie nicht einzeln verschiebt? Wo landen nun neue Apps? Wird automatisch auf den nächsten Speicher geschaltet für App-Installation, falls der erste voll ist?

root@thea:/ # du -sh /mnt/expand/????8fac-2c42-42af-9c45-4830cdab????/app/  /data/app
75M   /mnt/expand/????8fac-2c42-42af-9c45-4830cdab????/app/
1.7G   /data/app

Sry für die vielen Fragen, aber in diesem Thread über SD-Karten als Internem Speicher wollte ich das neue Handling von MM mal grundlegend verstehen. Es scheinen auch noch nicht so viele Leute verwendet zu haben.


Eine andere Frage noch zur Verschlüsselung: Die SD-Karte als interner Speicher wird scheinbar immer verschlüsselt, auch wenn das Gerät nicht "verschlüsselt" wurde? Oder passiert das Verschlüsseln der SD erst, wenn man das gesamte Gerät verschlüsselt?

 

[ooo]

Vorsicht:
/data/ == gesamte data-Partition
/data/media/<n>/... == emulierte "SD Card" (nur ein kleiner Teil der data-Partition)
(für den Haupt-Nutzer = Owner = "0" ist das dann /data/media/0/ <= die Inhalte dort kann man - wie ich oben - komplett löschen (= Internal Storage) nach der Daten-Migration, sonst bitte nichts ...)
[doublepost=1470299550,1470298971][/doublepost]

Liegt der Dalvik-Cache einfach mit auf der /data Partition?

Ja.
(Nicht bei allen ROMs aller Hersteller, kann auch eine eigene "echte" Partition sein, data ist performanter.)

Hatte der früher nicht eine eigene Partition /cache?

s. o. (/cache und /data/dalvik-cache sind zwei verschiedene Dinge)

Ist Dalvkik seit Art überhaupt noch verwendet?

Ja.

Heisst das, die Apps liegen weiterhin auf dem Internen Speicher, wenn man sie nicht einzeln verschiebt?

Ja.

Wo landen nun neue Apps?

s. o. Vorposting.

Wird automatisch auf den nächsten Speicher geschaltet für App-Installation, falls der erste voll ist?

Nein. (bzw., kommt auf die ROM an)

Die SD-Karte als interner Speicher wird scheinbar immer verschlüsselt, auch wenn das Gerät nicht "verschlüsselt" wurde?

Ja, das ist absolut unabhängig voneinander.
Full Disk Encryption | Android Open Source Project

Oder passiert das Verschlüsseln der SD erst, wenn man das gesamte Gerät verschlüsselt?

Nein.
[How-To] Daten retten von als intern eingebundener SD Karte

 

[mtrc]

Super. Dann ist der interne Speicher doch nicht ungenutzt...

Zum Cache, hier gibt es allerdings sowohl /cache als auch /data/dalvik-cache:

root@thea:/ # ls -al /data/dalvik-cache/   
total 136
drwxrwx--x  4 root  root  4096 2016-07-27 18:13 .
drwxrwx--x 36 system system  4096 2016-08-04 07:32 ..
drwx--x--x  2 root  root  24576 2016-08-03 12:56 arm
drwx--x--x  2 system system 20480 2016-08-03 14:30 profiles
root@thea:/ # ls -al /cache/   
total 6192
drwxrwx---  6 system cache  4096 2016-07-27 18:18 .
drwxr-xr-x 19 root  root  0 1970-06-15 02:15 ..
drwx------  3 system system  4096 2016-07-27 18:18 backup
drwxrwx---  2 root  root  4096 1970-06-09 04:40 lost+found
-rw-------  1 root  root  3145728 2016-08-04 07:45 pds-dump.img
drwxrwx---  2 system cache  4096 1970-06-14 19:32 recovery
drwxrwxrwx  2 root  shell  4096 1970-06-09 04:40 trace

 

[ooo]

Difference between Dalvik Cache vs Normal Cache

Spoiler

Dev stuff:
ART and Dalvik | Android Open Source Project
Configuring ART | Android Open Source Project

WITH_DEXPREOPT_PIC
In post-L AOSP, WITH_DEXPREOPT_PIC can be specified to enable position-independent code (PIC). With this, compiled code from the image doesn’t have to be relocated from /system into /data/dalvik-cache, saving space in the data partition. However, there is a slight runtime impact because it disables an optimization that takes advantage of position-dependent code. Typically, devices wanting to save space in /data should enable PIC compilation.

Example usage (in product’s device.mk):

WITH_DEXPREOPT := true
WITH_DEXPREOPT_PIC := true

​

 

[mtrc]

Warum sehe ich von meiner 64G SD-Karte nur 58G?

root@thea:/data # fdisk -l /dev/block/dm-1
Disk /dev/block/dm-1: 62.7 GB, 62712167936 bytes
255 heads, 63 sectors/track, 7624 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device /dev/block/dm-1: doesn't contain a valid partition table

root@thea:/data # df |grep expand
/dev/block/dm-1  61240300 1506992  59733308  3% /mnt/expand/????8fac-2c42-42af-9c45-4830cdab????

Oder ist das nur die Faktor 1024 Umrechnung?

 

[ooo]

GNU/Linux Basics?
linux size units at DuckDuckGo
linux size units - Google-Suche
linux size units base 10 at DuckDuckGo

Binärpräfix – Wikipedia

man df
man fdisk
man ...

Edit:
sd card usable storage smaller than - Google-Suche
sd card verfügbarer speicher kleiner als brutto - Google-Suche

Nettokapazität einer Festplatte berechnen

 

[mtrc]

[How-To] Daten retten von als intern eingebundener SD Karte

Noch eine Frage.. ich habe das Howto durchgeführt, um den Schlüssel für den Notfall zu besitzen. Dieser Schlüssel scheint ja auf dem echten internen Speicher zu liegen. Heisst das, wenn man ein Wipe durchführt, dass dann die SD-Karte nicht mehr erkannt wird? Meist führe ich nach einem ROM-Update ja ein Wipe durch, lasse dabei aber die SD-Karte unberührt, da hier ja meine TitaniumBackups liegen.
[doublepost=1470893060,1470892076][/doublepost]Ein weiteres Problem habe ich mit Rechten auf der SD-Karte: Ich dachte, mit der adopted SD-Karte hätte das ganze Rechte-Problem unter Marshmallow ein Ende, früher konnte TitaniumBackup z.B. nur in das Verzeichnis /storage/emulated/0/Android/data/com.keramidas.TitaniumBackup/ schreiben, jetzt geht das auch unter /storage/emulated/0/TB. Außerdem synchronisiere ich mit FolderSync nach /storage/emulated/0/DAV-Cloud. Das geht gut, FolderSync hat allerdings auch Root-Rechte. Nur kann keine andere App die PDFs oder Bilder unter diesem Verzeichnis lesen, daher tippe ich auf ein Berechtigungsproblem.

 

[ooo]

(Ein korrekt implementiertes) TWRP lässt bei einem Factory Reset oder Wipe > Advanced > Data oder Wipe > Advanced > Internal Storage den Schlüssel und die Informationen zu den beteiligten UUIDs der Drives/Partitionen in Ruhe. - Dadurch wird eine als intern formatierte, verschlüsselte SD Card weiterhin benutzbar gehalten. - Das Stock-Recovery macht allerdings alles "platt" und die Inhalte der SD Card sind ohne externe Sicherung verloren.

Mit dem folgenden Befehl kann man sich die relevanten Dateien in einer root shell wegsichern:

tar -czvf /sdcard/adopted-key.tar.gz data/misc/vold data/system/storage.xml -C /

(Allerdings sollte man die .tar.gz-Datei natürlich auf den Rechner wegkopieren, weil man ja ohne Schlüssel nicht mehr an die Inhalte der SD Card kommt == Deadlock ...)

Wieder herstellen kann man sie so:

tar -xzvf /<irgendwo>/adopted-key.tar.gz -C /

___

Das ist kein Berechtigungsproblem, sondern Absicht (und auch gut so. - Sicherheitsaspekt. - Die SD Card soll sich ja so verhalten, wie "echter" interner Speicher == /data/...). - Als Root benutzt man das Phone auch außerhalb des Standards eines User-Builds.
Wenn man *vom Rechner aus* einen Ordner im Stamm-Verzeichnis der SD Card anlegt, können i. d. R. andere Prozesse dort Datei-Operationen ausführen. - Vorher sind bereits existierende, gleichnamige Ordner zu sichern, dann zu löschen.

Alternativ kann man versuchen, die Berechtigungen über eine root shell zu ändern:

chown -R media_rw:media_rw /sdcard/my-folder

(Vor allen Aktionen aber bitte ein TWRP Vollbackup machen und die SD Card komplett sichern.)
___

TWRP Backups bzw. Titanium Backups sollte man übrigens immer via USB-OTG auf einen externen Stick oder eine externe USB-Festplatte machen, wenn es das Phone zulässt ... (siehe Screenshot)

 

[mtrc]

Die Verzeichnisse unter /storage/emulated/0 haben alle

drwxrwx--x  2 root sdcard_rw 4096 2016-08-04 09:55 ...

Die meisten davon hat Android beim migrieren ja selbst erstellt. Was passt denn nicht mit den Rechten? sdcard_rw kann doch lesen und schreiben. Die besagte Datei ist auch lesbar:

# ls -al /storage/emulated/0/sd2dav/Documents/0.NEW/SCN_0001.pdf
-rw-rw---- 1 root sdcard_rw 120089 2016-08-04 11:32 /storage/emulated/0/sd2dav/Documents/0.NEW/SCN_0001.pdf

 

[ooo]

Diese Berechtigungen sind aus der root-Sicht, nicht, wie es eine App | ein Prozess | der "normale" User sieht.

(Ich kann dir hier auch keine Android-/Linux-Einzel-Schulung geben (kostet - je nach Inhalt/Dauer - woanders locker netto EUR 5.000,00 ++), weil das den Rahmen exorbitant hier sprengen würde. - Auch ist das alles nicht mehr Geräte-spezifisch. - Lies bitte selbst im Netz nach, es ist alles da ... und kostet nichts, außer Überwindung ... joke)

 

[Kyle Katarn]

TWRP Backups bzw. Titanium Backups sollte man übrigens immer via USB-OTG auf einen externen Stick oder eine externe USB-Festplatte machen, wenn es das Phone zulässt ...

Danke für deine fundierten Ausführungen zur Sicherung des Keys für internen Speicher und der UUIDs!

Eine Frage nur: Warum Sicherung per USB-OTG?
Ich denke, dass eine Sicherung auf den internen (eingebundenen SD-)Speicher oder die eingebundene (adopted/mixed) SD-Karte ausreichend sein sollte, wenn ich die Datei danach auf ein weiteres, externes Medium wegsichere.
Hat es evtl. damit zu tun, dass dann Berechtigungen für die Sicherungsdatei nicht mehr stimmen?

 

[ooo]

Nein, aber manche Leute wollen auch ihren internen Speicher und/oder ihre externe Speicherkarte sichern.- Wohin soll das dann gesichert werden? - Auf einem USB-OTG Stick oder sogar einer externen USB-OTG Harddisk ist dann vllt. z. B. bis zu 1 Terabyte Platz frei (auch für mehrere Sicherungen parallel/verschiedene Devices). - Außerdem ist ein externes Speichermedium zuverlässiger (Festplatte, außerhalb vom bootloopenden Phone) und leichter in ein LAN/W-LAN einzubinden, wo es viel schneller unterwegs sein kann als jede andere Lösung. - Das ist eine professionellere Lösung, klar. - Man muss es aber nicht machen ...

 

[Kyle Katarn]

Du hast recht, es ist professioneller und dann auch ein Arbeitsschritt weniger als meine Hilfslösung ... danke dir, ich werde mir ein USB-OTG-Kabel zulegen.