Partitions-Layout, Zuständigkeiten & Dateisystem

[ICS]

Hallo,

aus Interesse, welche Partitionen es auf einem Android-Handy gibt, habe ich mir folgenden Artikel durchgelesen. Dort wird beschrieben, dass es 6 Standardpartitionen gibt (boot, system, recovery, data, cache, misc).

Anschließend ließ ich mir im Terminal via „ls -al /dev/block/platform/dw_mmc/by-name“ die Partitionen meines SGS2 anzeigen.
Anstatt 6, sah ich 12 Partitionen:

CACHE
DATAFS
EFS
FACTORYFS
HIDDEN
KERNEL
MODEM
PARAM
RECOVERY
SBL1
SBL2
UMS

Das heißt, dass jedes Smartphone ein unterschiedliches Partitionslayout hat.
1) Würde ich nun die Standardpartitionen mit denen meine SGS2 vergleichen, würde diese Zuteilung stimmen?

CACHE --> /cache
DATAFS --> /data
EFS --> /misc
FACTORYFS --> /system
KERNEL --> /boot
RECOVERY --> /recovery

2) Welche Aufgaben erfüllen die einzelnen Partitionen?
Stimmt dies soweit:

HIDDEN --> handelt es sich hierbei um eine Preload-Partition, welche vorinstallierte Apps von Dritten beinhaltet.
KERNEL --> beinhaltet den Kernel.
PARAM --> Einstellungen für den Bootvorgang, Debug-Einstellungen, Triangle-Status, wie oft eine Custom ROM geflasht wurde.
SBL1 --> zweiter Bootloader
SBL2 --> Backup des zweiten Bootloaders
UMS --> Interne SD

3) Wo würde in diesem Fall der Bootloader liegen, auf der Kernel-Partition?

4) Gibt es via ADB oder Terminal eine Möglichkeit, dass ich mir anzeigen lasse, welches Dateisystem die einzelnen Partitionen haben?
Ich habe das jetzt mit DiskInfo gemacht.

CACHE --> ext4
DATAFS --> ext4
EFS --> ext4
FACTORYFS --> ext4
HIDDEN --> ext4
KERNEL --> keines
MODEM --> keines
PARAM --> j4fs
RECOVERY --> keines
SBL1 --> keines
SBL2 --> keines
UMS --> vfat

5) Warum haben manche Partitionen ein Dateisystem und andere nicht?

6)Warum kommen 3 verschiedene Dateisysteme zur Anwendung?






Vielen Danke und einen schönen Abend!

 

[Blinderhund]

Keine Ahnung .

Android hatte bei Version 2.y noch hauptsächlich yaffs2 als Haupt-Datei-System .

Jetzt bei Version 4.y ist es ext4 geworden .

yaffs2 mußte an den Kernel-Quellcode von außen ange-patch-t werden , da yaffs2 nicht zum Standard Quellcode des Linux Kernels gehört .

Ähnlich ist es mit den Union-Dateisystemen "unionfs" und "aufs" , welche auch nicht zum Quellcode des Linux-Kernels gehören , aber in vielen Linux-Live-Cds werkeln .

"yaffs2" steht für "Yet-Another-Flash-Friendly-File-System" .

Es gibt neuerdings noch "f2fs" , was auch ein Flash-Friendly-File-System sein soll , und zum Standard Kernel-Quellcode gehört .

linux-x.y.z/Documentation/filesystems/f2fs.txt :

================================================================================
WHAT IS Flash-Friendly File System (F2FS)?
================================================================================

NAND flash memory-based storage devices, such as SSD, eMMC, and SD cards, have
been equipped on a variety systems ranging from mobile to server systems. Since
they are known to have different characteristics from the conventional rotating
disks, a file system, an upper layer to the storage device, should adapt to the
changes from the sketch in the design level.

F2FS is a file system exploiting NAND flash memory-based storage devices, which
is based on Log-structured File System (LFS). The design has been focused on
addressing the fundamental issues in LFS, which are snowball effect of wandering
tree and high cleaning overhead.

linux-x.y.z/Documentation/filesystems/ext4.txt :

Ext4 Filesystem
===============

Ext4 is an an advanced level of the ext3 filesystem which incorporates
scalability and reliability enhancements for supporting large filesystems
(64 bit) in keeping with increasing disk capacities and state-of-the-art
feature requirements.

Mailing list: linux-ext4@vger.kernel.org
Web site: http://ext4.wiki.kernel.org

Ich weiß nicht, was dies "DiskInfo" ist .
In der Regel mss die Dateisystem-Info in Programme gecodet werden , sprich deren Superblock-layout .

Es gibt Programme, die wenn sie ein File-System nicht erkennen können , keinerlei Daten außer nicht-NULL an den Anfrager zurückgeben , und andere sagen so etwas wie "unknown" zusätzlich zum Return-Code .

openSUSE zum Beispiel ist von "squashfs3" einst zu "clickfs" gewechset für die Live-Cds .
Dies clickfs ist ein ext3.img Image in einem fuse-Dateisystem-Container oder so ähnlich .
Dies reicht schon aus , um Erkennungsprogramme zu täuschen , und alles , was diese sagen können ist maximal "Data" .
Und einfacher and den Kern des "clickfs" Behälters von außerhalb SUSE zu kommen ist es auch auch nicht geworden .
Man kann zwar in Quell-Code schauen, aber man muß aufpassen, daß man keine Hirnschäden davonträgt .

Google Suche "Datei-System Patente" hat mir zum Beispiel diesen Treffer gegeben :

Distributed File System with multicast recovery
DE 10085311 B3

Patente DE10085311B3 - Verteiltes Dateisystem mit Multicast-Wiedergewinnung Distributed File System ... - Google Patentes

Der ursprüngliche Beitrag von 19:51 Uhr wurde um 20:18 Uhr ergänzt:

Hier die Infos von einem Blaupunkt Tablet Endeavour 785 über adb shell :

bash-3.00# ./adb shell
shell@BARM865FD:/ $ 

shell@BARM865FD:/ $ cat /proc/partitions
major minor  #blocks  name

  31        0       4096 mtdblock0
  31        1       4096 mtdblock1
  31        2      20480 mtdblock2
  31        3      32768 mtdblock3
  31        4      65536 mtdblock4
  31        5     131072 mtdblock5
  31        6       4096 mtdblock6
  31        7       4096 mtdblock7
  31        8    1048576 mtdblock8
  31        9   14016512 mtdblock9
 179        0   30748672 mmcblk0
 179        1   30744576 mmcblk0p1

shell@BARM865FD:/ $ cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00400000 00004000 "misc"
mtd1: 00400000 00004000 "kernel"
mtd2: 01400000 00004000 "boot"
mtd3: 02000000 00004000 "recovery"
mtd4: 04000000 00004000 "backup"
mtd5: 08000000 00004000 "cache"
mtd6: 00400000 00004000 "metadata"
mtd7: 00400000 00004000 "kpanic"
mtd8: 40000000 00004000 "system"
mtd9: 357800000 00004000 "userdata"

shell@BARM865FD:/ $ cat /proc/filesystems
nodev    sysfs
nodev    rootfs
nodev    bdev
nodev    proc
nodev    cgroup
nodev    tmpfs
nodev    devtmpfs
nodev    debugfs
nodev    sockfs
nodev    usbfs
nodev    pipefs
nodev    anon_inodefs
nodev    devpts
    ext3
    ext2
    ext4
nodev    ramfs
    vfat
nodev    fuse
    fuseblk
nodev    fusectl
nodev    selinuxfs
nodev    mtd_inodefs

shell@BARM865FD:/ $ cat /proc/mounts
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,seclabel,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,seclabel,relatime 0 0
selinuxfs /sys/fs/selinux selinuxfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
none /sys/fs/cgroup tmpfs rw,seclabel,relatime,mode=750,gid=1000 0 0
none /sys/fs/cgroup/memory cgroup rw,relatime,memory 0 0
tmpfs /mnt/secure tmpfs rw,seclabel,relatime,mode=700 0 0
tmpfs /mnt/asec tmpfs rw,seclabel,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,seclabel,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/mtd/by-name/system /system ext4 ro,seclabel,noatime,nodiratime,user_xattr,barrier=1,data=ordered,noauto_da_alloc,discard 0 0
/dev/block/mtd/by-name/cache /cache ext4 rw,seclabel,nosuid,nodev,noatime,nodiratime,user_xattr,barrier=1,data=ordered,noauto_da_alloc,discard 0 0
/dev/block/mtd/by-name/metadata /metadata ext4 rw,seclabel,nosuid,nodev,noatime,nodiratime,user_xattr,barrier=1,noauto_da_alloc,discard 0 0
/dev/block/mtd/by-name/userdata /data ext4 rw,seclabel,nosuid,nodev,noatime,nodiratime,user_xattr,barrier=1,data=ordered,noauto_da_alloc,discard 0 0
/sys/kernel/debug /sys/kernel/debug debugfs rw,relatime 0 0
/dev/fuse /mnt/shell/emulated fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
/dev/block/vold/179:1 /mnt/external_sd vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1023,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
shell@BARM865FD:/ $

Ich persönlich vermute, dass die unerkannten Dateisysteme iso9660 sind - Standard-CD filesystem oder UDF .
Wenn ein iso9660 Abbild auf ein normales Flash-USB-Gerät mit "dd" geschrieben wird

dd if=/pfad/zu/irgendeier_bootbaren_cd.iso of=/dev/sdd

müsste dieses USB-Flash-Gerät bootbar sein .

Und dies vermute ich bei den boot- und recovery- Partitionen .

Später braucht der kernel diese iso9660 Low-Level-Treiber nicht mehr .
Wenn die Dateisystem-Treiber als Module kompilliert wurden und in der initrd Initialen-RAM-Disk vorhanden ,
können diese Treiber später entladen werden .
Und um aud diese Treiber später wieder zurückgreifen zu können , müßten diese Treiber aus der Initialen RAM-Disk in das Betriebssystem kopiert werden .
Wenn dieses kopieren nicht geschieht , gibt es keine Treiber und somit weiß der demente Kernel nichts mehr von irgendwelchen Dateisystemen von vor einigen Sekunden .

shell@BARM865FD:/ $ busybox find -name modules.dep 2>/dev/null               

1|shell@BARM865FD:/ $ busybox modprobe -l                                      

shell@BARM865FD:/ $ cat /proc/modules                                          
rk29_ipp 9957 1 - Live 0x00000000 (C)
mali 152212 35 - Live 0x00000000
ump 27958 19 mali, Live 0x00000000
rk30xxnand_ko 162075 0 - Live 0x00000000

shell@BARM865FD:/ $ busybox uname -r
3.0.36+

shell@BARM865FD:/ $ ls /lib/modules
/lib/modules: No such file or directory
1|shell@BARM865FD:/ $

 

[Blinderhund]

ext2 16GB formattierte µ-SD-Karte :

6 GB Dateien raufgespielt , zwischenzeitlich Frühstück geholt, und als ich wieder zuhause war, immer noch am kopieren ...

Android 2.3.5 behauptet , daß die SD-Karte leer wäre .

Android 4.2.2 behauptet, daß die SD-Karte beschädigt wäre .

In Linux funktioniert sie einwandfrei ...

 

[Nick Knight]

Hmm ext2 für Micro-SD. Im S2 I9100 bieten die Recoverys nur vfat, exfat, ntfs, ext3, ext4, an. Nunja bin auch erst spät zum Androiden gekommen. Hier war schon 4.1.2 drauf was ich nur kurz genutzt habe da schon 4.4.2 alltagstauglich lief und atm 5.02. Windows oder Apple User können ext filesystem eh nicht gebrauchen.

Gruß Nick