Braucht man noch eine sd-ext Partition?

Stimmt, habe bemerkt, dass durch die Partitionierung unter CWM eine ext4 Partition erstellt wurde. Ich hatte es nur über ADB unter CWM probiert um eigene Partitionsgrößen erstellen zu können, da gab es aber kein mkfs.ext4.

Vorher hatte ich vom CM7-Rom aus mit ADB alles unmounted und per USB die SD-Karte von Linux aus partitioniert und mit vfat + ext4 formatiert. Nach einem Reboot wurde die ext4 Partition als /mnt/sdcard gemounted, nicht die fvat. Nach einem erneuten Reboot wurde die ext4 zwar als /sd-ext gemountet, aber die vfat Partition immer noch nicht, auch nicht nach erneutem Reboot.

Es klappt nun aber, wenn ich einfach mit CWM das ganze partitioniere.
 
Mkfs.ext4 gibt es auch in dem Sinne nicht. Man erstellt ext3 und erweitert dessen Umfang mit tune2fs.
 
sollte man ext3 oder ext4 erstellen?

ich nutze s2e und frage mich ob ich das nächste mal das System auf ext4 konvertiren sollte.

Ich habe meinem sd mit der recovery eine 2gb partition gegeben.

Ist das eigentlich ext2 oder ext3?

Und womit kann man das prüfen?
 
Mit dem 'mount' Befehl.

Die Partition sollte von vornherein ext4 formatiert sein, bevor irgendwelche Daten darauf gespielt werden, um bestmögliche Leistung zu erzielen.

Kann man z.B. so machen:

Partition im CWM erstellen:
mke2fs -b 4096 -E stride=32,stripe-width=32 -m0 /dev/block/mmcblk0p2
tune2fs -c0 -i0 -j /dev/block/mmcblk0p2
e2fsck -yf /dev/block/mmcblk0p2
tune2fs -O extents,uninit_bg,dir_index /dev/block/mmcblk0p2
e2fsck -yf /dev/block/mmcblk0p2
tune2fs -o journal_data_writeback /dev/block/mmcblk0p2
tune2fs -O ^has_journal /dev/block/mmcblk0p2
e2fsck -yf /dev/block/mmcblk0p2
Stammt hauptsächlich aus dem S2E Script selbst (/data/local/userinit.d/simple2ext) und das mit den 4096/32 Strides kommt aus der 128KB Flashmemory erase block size Optimierung (>Google), wobei das an sich ein Komplementär zum SSD Alignment ist (fdisk -H 224 -S 56 [...]).


Falls es Probleme im CWM beim Restore mit dem ext4 Archiv gibt, manuell entpacken (vorher /sd-ext mounten):
tar -xvf /sdcard/clockworkmod/backup/<date>/sd-ext.ext4.tar -C /
x = extract
v = verbose
f = file <name>
-C / = Das gleiche wie ein vorangehendes 'cd /'. Der Ordner '/sd-ext' ist im tar Archiv mit drin, daher wird nach root entpackt.


/sd-ext mounten:
(Vorsicht bei copy&paste. Die Forensoftware ist buggy und fügt willkürlich Leerstellen ein, siehe 'errors=conti nue').
'noatime' impliziert 'nodiratime'.
mount -t ext4 -o commit=19,barrier=0,nobh,nouser_xattr,errors=continue,noatime,nosuid,nodev,data=writeback /dev/block/mmcblk0p2 /sd-ext


S2E Overlays erstellen (vorher /sd-ext mounten):
mount -o bind /sd-ext/app/ /data/app
mount -o bind /sd-ext/data /data/data
mount -o bind /sd-ext/dalvik-cache/ /data/dalvik-cache
mount -o bind /sd-ext/download/ /cache/download


Alles unmounten:
umount /data/app
umount /data/data
umount /data/dalvik-cache
umount /cache/download

umount /sd-ext
 
Zuletzt bearbeitet:
@maniaxx

Das ist mir zu kompliziert. Ich habe per AcronisDiskDirector die 2GB partition in eine ext3 formatiert.

Das Recovery konnte es irgendwie nicht sauber machen und S2E konnte somit nicht richtig funktionieren. Ich versucher es seit Tagen aber das Recovery kann das nicht. Mit mehreren SD karten versucht. Ich habe noch 3 Google ones und damit geht es. Weiß nicht was dieses aktuelle handy für ein Problem hat beim Formatieren. Vielleicht ist der Kartenleser im Gerät kaputt. Sonst geht ja alles super.

Schade das Acronis noch keine ext4 erstellen kann. Sonst hätte ich das gemacht.

Wenn ihr eine webbasierende möglichkeit habt ext4 ohne Befehle wie oben zu erstellen bin ich interessiert.
 
Nochmal eine Frage. Ich habe mittlerweile eine ext4 Partition, die ich mit CWM erstellt hatte. Unter CM7 habe ich mit S2E dorthin fast alles bis auf den Dalwik-Cache ausgelagert:
# mount |grep ext4
/dev/block/mmcblk0p2 on /sd-ext type ext4 (rw,nosuid,nodev,noatime,nodiratime,commit=19,barrier=0,nobh,data=writeback)
/dev/block/mmcblk0p2 on /data/app type ext4 (rw,nosuid,nodev,noatime,nodiratime,commit=19,barrier=0,nobh,data=writeback)
/dev/block/mmcblk0p2 on /data/app-private type ext4 (rw,nosuid,nodev,noatime,nodiratime,commit=19,barrier=0,nobh,data=writeback)
/dev/block/mmcblk0p2 on /data/data type ext4 (rw,nosuid,nodev,noatime,nodiratime,commit=19,barrier=0,nobh,data=writeback)
/dev/block/mmcblk0p2 on /cache/download type ext4 (rw,nosuid,nodev,noatime,nodiratime,commit=19,barrier=0,nobh,data=writeback)
Ich frage mich nun, was passiert, wenn ich per USB diese ext4 Partition mounte. Das ist neben der vfat nämlich auch möglich. Vorteil der ext4 Partition war ja, dass die Apps, die auf SD ausgelagert sind, nicht anhalten müssen, wenn man die SD-Karte (zumindest die vfat-Partition) mountet. Müssen nun die Apps auf ext4 auch anhalten, wenn ich diese ext4 Partition mounte?

Hintergrund ist, dass ich nun den LUKS-Manager verwende, um eine verschlüsselte Loop-Disk zu erstellen, die ich sowohl innerhalb von Android als auch von außerhalb per USB mounten kann. Diese liegt derzeit auf der vfat-Partition und hat deshalb leider die 4G Filesystem-Grenze. Da ich dies eh nur von Linux aus durchführe, könnte die Loop-Disk genausogut auch auf ext4 liegen. Dann würde ich beim nächsten Mal die ext4 Parition entsprechend größer wählen.
 
Wenn du das Speichermedium, egal mit welchem Dateisystem, "extern" mountest, hat das Android keinen Zugriff mehr darauf. D.h. alle "Apps" müssen anhalten.

Noch ein paar Kleinigekeiten:
Ext4 mit Journal (das ist Standard) ist schlecht für einfache Flash Speicher wie SD Karten. Das hat damit eine hohe Schreibfrequenz und verschleißt dir damit die Karte deutlich schneller als ohne Journal.
Eine verschlüsselte Datei ist auch sehr schlecht für die Lebensdauer, weil eben die gesamten Schreibzyklen nur auf den gleichen paar Sektoren stattfinden.

PS: Du kannst eine komplette Partition per luks verschlüsseln, damit wäre es sauberer vom Rest getrennt, und zusätzlich deine SD ext Partition.
 
Die Sache mit dem Journal weiß ich ja. Daher habe ich in S2E die Option gewählt "[x]Als ext4 mounten (sd-ext als ext4 ohne Journaling mounten)".
Nur sehe ich an meiner ADB Ausgabe nun auch, dass dies wohl nicht greift. An den mount Parametern sehe ich nichts, dass das Journal deaktiviert sein soll.

Übrigens habe ich aber auch schon gehört, dass heutige Flash-Speicher die Zyklen selbst verteilen, also auch bei Journal nicht immer die gleichen Sektoren beschreiben.

Ob nun eine verschlüsselte Datei oder eine verschlüsselte Partition: Der Inhalt wird beidemal an dieselbe Stelle geschrieben. Bei der Datei bin ich nur etwas flexibler und könnte die später vergrößern, ohne gleich die ganze SD-Card neu partitionieren zu müssen. Das Partitionieren war, wie in den vorhergehenden Diskussionen hier, auch gar nicht so einfach. Ich konnte scheinbar nicht einfach über USB die Karte vom externen Linux aus partitionieren und formatieren, es ging am Ende nur mit CWM.

Komplette Partition, damit meinst du wohl insgesamt 3 Partitionen, oder? 1. vfat, 2. ext2/3/4 für /sd-ext und 3. meine verschlüsselte Partition? Ich glaube, das kann LUKS-Manager nicht.
 
mass schrieb:
Die Sache mit dem Journal weiß ich ja. Daher habe ich in S2E die Option gewählt "[x]Als ext4 mounten (sd-ext als ext4 ohne Journaling mounten)".
Nur sehe ich an meiner ADB Ausgabe nun auch, dass dies wohl nicht greift. An den mount Parametern sehe ich nichts, dass das Journal deaktiviert sein soll.
Prüfe das mit tune2fs.

Übrigens habe ich aber auch schon gehört, dass heutige Flash-Speicher die Zyklen selbst verteilen, also auch bei Journal nicht immer die gleichen Sektoren beschreiben.
Wear Leveling nennt sich das.

Ob nun eine verschlüsselte Datei oder eine verschlüsselte Partition: Der Inhalt wird beidemal an dieselbe Stelle geschrieben. Bei der Datei bin ich nur etwas flexibler und könnte die später vergrößern, ohne gleich die ganze SD-Card neu partitionieren zu müssen.
Dafür hast du den Overhead vom darunterliegenden Dateisystem und dessen Beschränkungen.

Das Partitionieren war, wie in den vorhergehenden Diskussionen hier, auch gar nicht so einfach. Ich konnte scheinbar nicht einfach über USB die Karte vom externen Linux aus partitionieren und formatieren, es ging am Ende nur mit CWM.
Das wundert mich. Zumindest über einen CardReader sollte das kein Problem sein.

Komplette Partition, damit meinst du wohl insgesamt 3 Partitionen, oder? 1. vfat, 2. ext2/3/4 für /sd-ext und 3. meine verschlüsselte Partition? Ich glaube, das kann LUKS-Manager nicht.
cryptsetup luksOpen etc.. ;)

Edit: prinzipiell kann man die sd ext auch verschlüsseln und spart sich damit eine Partition. Eine Fat Partition brauchst du ohnehin nicht, wenn du bevorzugt Linux nutzt, da tuts auch Ext2/3/4.
 
Ungewiss schrieb:
Prüfe das mit tune2fs.
Code:
# tune2fs -l /dev/block/mmcblk0p2 |head
tune2fs 1.41.12 (17-May-2010)
Filesystem volume name:   BladeMo_sdext
Last mounted on:          /sd-ext
Filesystem UUID:          9df626da-205e-4c41-874e-6b9c662166c5
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      dir_index filetype extent sparse_super uninit_bg
Filesystem flags:         unsigned_directory_hash 
Default mount options:    journal_data_writeback
Filesystem state:         not clean
Features scheint also kein has_journal und damit kein Journal zu haben. ext4 sollte also ok sein?
Ungewiss schrieb:
Wear Leveling nennt sich das.
Und ist es damit heute noch ein Thema, Filesysteme mit Journal auf Flash? Abgesehen davon, dass man Journal wohl nicht benötigt. Obwohl ich mir da schon Gedanken mache, denn auch mit Batteriebetrieb fährt das Handy nicht immer sauber runter und macht einen umount, z.B. wenn das Ding mir auf den Boden fällt und die Batterie rausspringt. Schon vorgekommen hin und wieder...
Ungewiss schrieb:
Das wundert mich. Zumindest über einen CardReader sollte das kein Problem sein.
Ok, damit sollte es vlt. gehen. Ich wollte bei dem hakligen Handy nur nicht so oft die Klappe entfernen und wollte den Vollzugriff auf die SD-Karte per USB. Ich hab das nun länger nicht mehr probiert. Damals war mkfs.ext4 in der ADB-Shell nicht verfügbar, und nachdem ich die Formatierung "extern" gemacht habe, mountete CM7 nach dem Boot diese leider als /mnt/sdcard statt sd-ext..., ich hatte es dann aufgegeben.
Ungewiss schrieb:
cryptsetup luksOpen etc.. ;)

Edit: prinzipiell kann man die sd ext auch verschlüsseln und spart sich damit eine Partition. Eine Fat Partition brauchst du ohnehin nicht, wenn du bevorzugt Linux nutzt, da tuts auch Ext2/3/4.
Ohne Luks Manager weiß ich aber nicht, wie /mnt/sd-ext nach dem boot direkt für die Apps verfügbar sein soll. Ich warte ja schon lange auf nativen Support für Verschlüsselung in Android, ab 4 soll es da auch etwas geben, schön wäre es halt, wenn es auch LUKS ist und ich darauf per USB mit externem LUKS zugreifen kann.
Was mich beim Luks Manager noch wundert, die behaupten Binaries für Arm7 zu installieren, dennoch läuft es auf meinem Arm6 Gerät. Bin gerade die cipher am Ausloten. twofish-cbc-essiv ist scheinbar nicht im CM7.2 Kernel, nur twofish-plain, xts sowieso nicht.
 
Ungewiss schrieb:
Edit: prinzipiell kann man die sd ext auch verschlüsseln und spart sich damit eine Partition. Eine Fat Partition brauchst du ohnehin nicht, wenn du bevorzugt Linux nutzt, da tuts auch Ext2/3/4.
Früher oder später werde ich die vfat Partition auch aufgeben.
Ich habe eben getestet, was passiert, wenn ich die ext-Partition über USB mounte: In der ADB Shell bleibt /sd-ext weiterhin gemountet, auch wenn ich ich diese per USB mounte von extern mounte und obwohl darauf Apps ausgelagert sind. Ist das sicher oder fehlt hier der Sicherheitsmechanismus, dass erst alles angehalten wird wie bei der vfat Partition?

Wie würdest du die komplette ext-Partition auf SD-Karte verschlüsseln? Wie wird diese beim Booten dann geöffnet? Schick wäre es, wie auf meinem Linux, das LUKS-Passwort an das User-Passwort zu binden mit pam_mount. Bei Android wäre es dann an den Login-Key gebunden. Besser/Sicherer als nichts. Solange das Gerät läuft, ist der Container halt offen und die Sicherheit hängt am Lock bzw. am ADB, das in dem Fall besser ausgeschaltet sein sollte..
 
Maniaxx schrieb:
tune2fs -l /dev/block/mmcblk0p2 |head
Hallo, woher hast Du denn die busybox mit tune2fs? meine (v.1.19.0) hat das nicht.
 
Sollten eigentlich alle Recoveries (CWM, TWRP..) mit an Board haben.
 
die aktuelle binary von busybox bekommt man hier her: Klick!
oder als Direkt-Download: Klick!
oder über eine App: Klick!
 
Zuletzt bearbeitet:
busybox 1.20 hatte ich mir schon geholt, hat es aber auch nicht.
@Maniaxx: ich habe das Stock-ROM
 
Zuletzt bearbeitet:
Also ich habe Version 1.21.0 und da ist tune2fs bei.
 
ElTonno schrieb:
Also ich habe Version 1.21.0 und da ist tune2fs bei.
Das ist interessant, aber woher? bei Index of /downloads/binaries gehts nur bis zur 1.20

interessant wäre auch das resize2fs, mit dem man filesysteme vergrößern kann - ohne die Daten sichern und wieder einspielen zu müssen.
 
Gute Frage, dachte bei busybox.net müsste man auch die aktuelle bekommen - sollte man zumindest annehmen.
Bei github hab ich sie noch gefunden: https://github.com/Gnurou/busybox-android

resize2fs ist übrigens auch enthalten
 
Zuletzt bearbeitet:
  • Danke
Reaktionen: regn
Bei github gibts wirklich eine 1.21, aber resize2fs ist da nicht drin:
./busybox-1.21 resize2fs
applet not found


Habe es aber inzwischen auf der /sbin entdeckt, heißt da allerdings resize2fs_s.
Das tune2fs habe ich auf einer polnischen Seite gefunden.

was ist github eigentlich?
 
  • Danke
Reaktionen: regn

Ähnliche Themen

J
Antworten
2
Aufrufe
4.048
rob239
rob239
ShadySteveO
  • ShadySteveO
Antworten
2
Aufrufe
3.212
steve8x8
S
M
Antworten
3
Aufrufe
2.614
steve8x8
S
Zurück
Oben Unten