I've created a single primary Ext2 partition in my phone's external SD card but Android refuses to mount it automatically. Whenever I attempted to mount it manually it kept throwing the error "mount operation not supported on transport endpoint".
How can I mount it?
Using (SlimKat) Android 4.4.2.
EDIT: I'm now able to mount it only manually but have to specify ext4 as its filesystem -- why and will it make a difference since ext2 is non-journalled? Also, I tried adding a mount entry in /fstab.smdk4x12 but it was deleted upon reboot; does this mean no manual entries are allowed in that file and I will instead have to hack my own /init-xx.rc file to manually mount the partition at boot time?
miguelg_ said:
I've created a single primary Ext2 partition in my phone's external SD card but Android refuses to mount it automatically. Whenever I attempted to mount it manually it kept throwing the error "mount operation not supported on transport endpoint".
How can I mount it?
Using (SlimKat) Android 4.4.2.
EDIT: I'm now able to mount it only manually but have to specify ext4 as its filesystem -- why and will it make a difference since ext2 is non-journalled? Also, I tried adding a mount entry in /fstab.smdk4x12 but it was deleted upon reboot; does this mean no manual entries are allowed in that file and I will instead have to hack my own /init-xx.rc file to manually mount the partition at boot time?
Click to expand...
Click to collapse
Why not just reformat to ext4?
es0tericcha0s said:
Why not just reformat to ext4?
Click to expand...
Click to collapse
Ultimately that's what I'll need to do but was hoping to use the non-journalled ext2. Is it not supported by Android or it the case that only some versions support it (in which case, what idiocy!)?
Have to say I'm beginning to truly hate Android. They might as well build their own kernel such that Linux (and by implication UNIX) is removed from the mix for they have completely butchered this OS. I suppose this is what happens when egos larger than the world are responsible for designing software; NIH syndrome.
Answering myself: if anyone is wondering how to automount a partition at boot time, you'll have to create your own init script and place in /system/etc/init.d/.
Well, realistically, the amount of people that have any use for mounting ext2/3/4 etc partitions is a very small % of users. Most people with android phones don't even know what Linux is, much less know about different kinds of partitions and what they are used for - or have a need for it. 99% of things you would NEED to do on a phone would be covered by the fat32 and exFat types. Of course, here on XDA, you'll find plenty of posts, guides, complaints about it, etc but there's obviously a certain type of user that seeks out or finds XDA and are more inclined to know of or have use for more technical things like this.
As far as auto-mounting the script on boot, you have to be rooted with init.d enabled and not all phones have full /system RW capabilities to even add stuff like that even when rooted. This is rare, but there's some HTCs and others like that. Often times there are ways around, but just saying, it's not a universal thing.
es0tericcha0s said:
Well, realistically, the amount of people that have any use for mounting ext2/3/4 etc partitions is a very small % of users. Most people with android phones don't even know what Linux is, much less know about different kinds of partitions and what they are used for - or have a need for it. 99% of things you would NEED to do on a phone would be covered by the fat32 and exFat types. Of course, here on XDA, you'll find plenty of posts, guides, complaints about it, etc but there's obviously a certain type of user that seeks out or finds XDA and are more inclined to know of or have use for more technical things like this.
Click to expand...
Click to collapse
That doesn't excuse the fact that they've deliberately crippled the OS. As an example, the FAT filesystems don't support symbolic links, which means that if you want to move any data outside of internal storage for whatever reason, you pretty much need an extX partition. Besides, those people (the vast majority) who don't know and don't care about the internals of their devices aren't the ones creating software for said devices in the first place. We are. And so these technical aspects matter and are relevant to us, not the masses.
es0tericcha0s said:
As far as auto-mounting the script on boot, you have to be rooted with init.d enabled and not all phones have full /system RW capabilities to even add stuff like that even when rooted. This is rare, but there's some HTCs and others like that. Often times there are ways around, but just saying, it's not a universal thing.
Click to expand...
Click to collapse
Didn't know about that limitation. Can you not remount the rootfs with RW privileges? And do you mean to say that some devices don't even support init.d; if so, what mechanism do they have in place?
miguelg_ said:
That doesn't excuse the fact that they've deliberately crippled the OS. As an example, the FAT filesystems don't support symbolic links, which means that if you want to move any data outside of internal storage for whatever reason, you pretty much need an extX partition. Besides, those people (the vast majority) who don't know and don't care about the internals of their devices aren't the ones creating software for said devices in the first place. We are. And so these technical aspects matter and are relevant to us, not the masses.
Didn't know about that limitation. Can you not remount the rootfs with RW privileges? And do you mean to say that some devices don't even support init.d; if so, what mechanism do they have in place?
Click to expand...
Click to collapse
Well, cripple might be a bit of hyperbole considering it's not something most people would need. I get your point though, it is weird that it's not native since it works with Linux generally. You can link symbolically to FAT systems while rooted with something like this:
https://play.google.com/store/apps/details?id=com.devasque.fmount
And yes, the tech people are creating software for these devices, but they are made for the general public, because that's who buy 90% of these things.
Could you please clarify what you said earlier on the read-only init.d and even some devices not supporting it? Again, thanks for your input, es0tericcha0s.
miguelg_ said:
Could you please clarify what you said earlier on the read-only init.d and even some devices not supporting it? Again, thanks for your input, es0tericcha0s.
Click to expand...
Click to collapse
Sure. Most android devices, actually I can't think of any of the top of my head, don't come with native init.d support or even have init.d that is not accessible. It's just not there. It's enabled in almost all custom roms, or you can add it yourself to many stock roms via a couple different ways like this:
https://play.google.com/store/apps/details?id=com.androguide.universal.init.d
As far as the system RW issue, some phones, like many newer HTCs, have the system protected so that you can make changes to the /system while booted, no problem, but once you reboot, all the changes will get undone. Very annoying. Example:
https://www.youtube.com/watch?v=KV3YaMBnEYI
Related
Since the bootloader is bypasased, is it possible to change the partition layout of the internal storage?
Shaumux said:
Since the bootloader is bypasased, is it possible to change the partition layout of the internal storage?
Click to expand...
Click to collapse
may i ask why exactly?
btw... wrong section...
why is not a good question, for android,
a partial answer would be because its possible on other phones.
i thought this is related to android devlopment and the bootloader dev so this would be the right section
i'm sorry if its not.
anyway the question is still unanswered
Shaumux said:
why is not a good question, for android,
a partial answer would be because its possible on other phones.
i thought this is related to android devlopment and the bootloader dev so this would be the right section
i'm sorry if its not.
anyway the question is still unanswered
Click to expand...
Click to collapse
i am not sure if it will work... are u thinking about changing sizes of internal partitions or something like that?
can u guide me to the links where they have changed partition layout on other androids? will read up on the advantages/etc...
Here http://alpharev.nl/ and
here http://forum.cyanogenmod.com/topic/10726-how-to-increase-desire-internal-storage/
The biggest advantage i can think of would be to reallocate wasted space to where its really need, which will depend on the user i guess.
This brings up another interesting thing to my mind.
Changing the filesystem.
It is possible in android, can't say about X10 though.
maybe just for the fun of it or maybe another filesystem may give better performance.
What about support for ext2 filesystem ? That would help wont it ?
Sent from my X10 TripNMiUI
Shaumux said:
Here http://alpharev.nl/ and
here http://forum.cyanogenmod.com/topic/10726-how-to-increase-desire-internal-storage/
The biggest advantage i can think of would be to reallocate wasted space to where its really need, which will depend on the user i guess.
This brings up another interesting thing to my mind.
Changing the filesystem.
It is possible in android, can't say about X10 though.
maybe just for the fun of it or maybe another filesystem may give better performance.
Click to expand...
Click to collapse
Just became a little slow on fs ques. I hope it is possible.
Sent from my X10 TripNMiUI
@realunited123: well i can't say if ext2 will really help or not, its quite outdated now and i also don't think that it would be a good choice for fs on flash.
But btrfs or ext4 would be different.
btrfs specially has many features for flash memory.
But the main question is can these things be really done since the bootloader isn't cracked just bypassed, so would it still search the original partitions?
Lol i meant ext4. Damn swiftkey changes it automatically.
Sent from my X10 TripNMiUI
And also certain parts of nand can not be accessed/written without bricking the device. So there is a big chance it is not possible.
Sent from my X10 TripNMiUI
ext4
Shaumux said:
Since the bootloader is bypasased, is it possible to change the partition layout of the internal storage?
Click to expand...
Click to collapse
that would be big performance boost for our device.
with samsung galaxy s my mate using ext4, and file system performance went hight!
i am waiting for a sollution to change from ext2 (old very old) to ext4 !
anyway : i am using linux as desktop, and server , and PHONE! and only my pgone is locked to ext2....
actually currently we are on yaffs2 and not ext2
tiborprogmed said:
that would be big performance boost for our device.
with samsung galaxy s my mate using ext4, and file system performance went hight!
i am waiting for a sollution to change from ext2 (old very old) to ext4 !
anyway : i am using linux as desktop, and server , and PHONE! and only my pgone is locked to ext2....
Click to expand...
Click to collapse
We are not on ext2. The reason the SGS sees such an improvement is because the original filesystem sucks. The X10's is yaffs2, which is good to begin with, so we would only see minimal gains, if any. zdzihu has had those modules for a long time and doesn't waste our time with them for that reason.
ext4 is not a good idea. While performance under ext4 may be better, yaffs2 is optimized for wear leveling and error correction under flash memory. Those people running ext4 on their internal flash are wearing out their NAND storage at up to twice as fast, possibly faster. Their phone will die much quicker.
This is possible yes. But we would need to have a modified flashtool to support it, and we would need a modified recovery build and some other firmware files for the modified flashtool to use. This is because we cannot access the boot partition or the kernel via recovery, so we can't run a fancy script like the brilliant CustomMTD script/patcher (for example - mainly for HTC phones if I remember correctly).
While I'm nearly certain that's the rough idea of what has to be done, I could still be wrong because it's beyond my ability.
jonusc said:
ext4 is not a good idea. While performance under ext4 may be better, yaffs2 is optimized for wear leveling and error correction under flash memory. Those people running ext4 on their internal flash are wearing out their NAND storage at up to twice as fast, possibly faster. Their phone will die much quicker.
This is possible yes. But we would need to have a modified flashtool to support it, and we would need a modified recovery build and some other firmware files for the modified flashtool to use. This is because we cannot access the boot partition or the kernel via recovery, so we can't run a fancy script like the brilliant CustomMTD script/patcher (for example - mainly for HTC phones if I remember correctly).
While I'm nearly certain that's the rough idea of what has to be done, I could still be wrong because it's beyond my ability.
Click to expand...
Click to collapse
Yeah but we may still use UBIFS or whatever.
The main thing here is that the users gets a choice and i don't see any problem if its through flashtool atleast for now.
and i think the ability to resize the partitions would also be a very useful thing since the rom partiitons seems to be excessively sized than required especially with custom roms.
The vold provided by Motorola can't mount sdcards formatted to other filesystems than FAT, even though the kernel supports it.
I would like the ability to format my SDcard to EXT4 which our kernel supports.
To do this we would have to patch the vold source and rebuild it.
I have tested to already patched volds, one pure Android and one CM7. Witch didn't work so I suspect that Motorola have modified vold and because vold is GPL the source should be in the sources they have published. But I can't find it, can somebody help me?
It's not about compiling vold. It's about compiling it with the same libraries Moto have used to compile the one that you can find on the RAZR...
...OR...
You can modify vold so that it will use different libraries (if it's using lib.so, you'll modify it so it will use newlib.so). You would have to copy the alternative libs with the alternative names on your device, too.
wow - does that mean the internal SD is FAT? That's hard to believe as EXT4 is easily 2x as fast, much more crash resistant, corruption proof and no file size limitations. Why in H*(@&# didn't motorola link EXT4?
You know, the more I use this phone the more I think it was readied around July and sat around in warehouses until the Nov release. They could have at least field tested it to reveal those stupid plastic buttons etc.
Oh well, this phone is still a remarkable piece of work. In comparison, my Samsung's have a bug list about 3 pages long now, so all phones have engineering/build negligence. Again other than the 3 breakable buttons on the Razr that can be impossible to push, some bluetooth issues, and it's menu buttons aren't really ready for ICS, it's a really good phone. The radios on this phone blow AWAY the Samsungs
@kholk
Do you have any more info about that?
Previously i have read that we just need to modify it to mount with filesystem set to auto instead of vfat which I thought sounded very plausible because vold shouldn't need to be able to read from the filesystem.
@buckwheat.phd
unfortunately yes, internal storage is also FAT.
Hi!
I know, that this question has been asked many times, so I'll try to formulate it a little different. I know, that Google wants to abandon USB Mass Storage (UMS) with Ice Cream Sandwich (ICS) and focus on MTP / PTP.
This is however a pain in the @ss for most users. Since the Transformer Prime (TF-201) has only 1 partition, which can not be "exported" via UMS - because it has the system on it - would it be possible to modify ICS so, that the internal storage will be partitioned? Let's say 5GB for ICS and Apps, the rest on a separate partition. And the second partition could act like an "SD Card", like it's on most phones?
Would this somehow be possible?
I prefer UMS over MTP/PTP, since the latter 2 are not usable on Linux, and even in Windows Total Commander does not show the MTP/PTP devices (no official support, no plugins that work...) and I'm "forced" to use Windows Explorer
Thats what i though too when i connected my prime to the pc.
Was expecting to connect it in UMS.
Usually partitions are defined by the bootloader, so this would need a bootloader edit which nobody really wants to try due to the lack of nvflash access
Would it be possible with root?
brantje said:
Would it be possible with root?
Click to expand...
Click to collapse
No, because UMS would require having an actual "sdcard" partition on the device, and this is not the case. As Diamondback said, to change the partitioning of the storage would require full bootloader access which is not possible without the likes of nvflash.
Personally I think you are better to figure out a way to use the MTP. I use Linux so ?I know what a pain it is, but for the very occasional times I need to access sdcard from my PC MTP works "well enough".
Android 4.0 Compatibility Definition at 7.6.2. Application Shared Storage says
Regardless of the form of shared storage used, device implementations MUST provide some mechanism to access the contents of shared storage from a host computer, such as USB mass storage (UMS) or Media Transfer Protocol (MTP). Device implementations MAY use USB mass storage, but SHOULD use Media Transfer Protocol.
Click to expand...
Click to collapse
I read that as saying the method used is down to the developer. I think if mtp was required then the word "MUST" would be used and "SHOULD" is "do this unless there are valid reasons not to do it"
peterk-1 said:
Android 4.0 Compatibility Definition at 7.6.2. Application Shared Storage says
I read that as saying the method used is down to the developer. I think if mtp was required then the word "MUST" would be used and "SHOULD" is "do this unless there are valid reasons not to do it"
Click to expand...
Click to collapse
I don't think it is down to the "developer" as in the ROM chef. Your quote clearly says "Device implementations" - i.e. the way the device is set up. So, a device manufacturer who is creating an ICS device could either configure the device with a separate partition or card for /sdcard and use UMS or they have a single shared partition and use MTP.
The problem with UMS as I understand it is that it requires a dedicated partition, and when that partition is mounted on the host PC, it cannot be accessible to Android (remember all the issues with widgets which were installed on the sdcard on previous android versions not working ?).
The MTP method, on the other hand, does not have this restriction and also allows the dynamic sharing of a single partition between /data and /sdcard which makes much more efficient use of available storage.
So basically this was a design decision which the manufacturer made at design time. In order for a ROM developer to change that, they would need access to be able to split the current /data partition into two chunks: one for /data and one for /sdcard. That capability does not exist with the Prime.
Then again, I could be totally wrong
barryflanagan: Quite right in what you say. It's such an easy mistake to type developer instead of manufacturer!!
Cheers
Diamondback said:
Usually partitions are defined by the bootloader, so this would need a bootloader edit which nobody really wants to try due to the lack of nvflash access
Click to expand...
Click to collapse
barryflanagan said:
No, because UMS would require having an actual "sdcard" partition on the device, and this is not the case. As Diamondback said, to change the partitioning of the storage would require full bootloader access which is not possible without the likes of nvflash.
Personally I think you are better to figure out a way to use the MTP. I use Linux so ?I know what a pain it is, but for the very occasional times I need to access sdcard from my PC MTP works "well enough".
Click to expand...
Click to collapse
Hi Guys!
First, thanks for the answers.
Second: "well enough" is not what I would aim for in a high quality and premium device like the TF Prime...
So, if I'm interpreting this right, "we" (the geeks & developers at XDA) need only nvflash for the Prime. That doesn't sound too hard. Personally I don't know nvflash, or how to get it working on the Prime (I'm not a developer), but since we already have root access and an unlocked bootloader it should be no problem.
I ran into the following site after a quick Google search: http://androidroot.mobi/2011/06/13/nvflash-on-asus-transformer/
I think I'm not alone, when I say, that UMS is better than MTP/PTP. Personally I don't care about a shared storage. When I want to copy music or movies to my phone or tablet I'm prefer the UMS method (umount on device, mount on PC).
<rant>On another note, why I dislike MTP: many years ago I had a Creative Zen Touch (20GB), which used MTP. On 2 out of 3 PC's I could not get it work, no matter what I had done, and even the rare times it worked, I could not copy bigger file (I think 1GB or larger) to the device, the transfer always broke up.
After I got the TF Prime, I was really disappointed to see, that ASUS chose this path too (since it's not mandatory, only recommended - I think some ICS Phones have a partitioned internal storage, where 1 partition can act like an SD card). The first thing that happened to me after I got the Prime: I copied a directory from my work notebook on the TF Prime. After some time I deleted that directory (I used the File Manager that came with the device). Then (after the directory was deleted) I connected the Prime to my home PC (the TF Prime was *never* connected to that PC before), and the first thing I saw, was the previously deleted directory - though I did *not* see the directory in the File Manager anymore! So that's why I'm against MTP/PTP. </rant>
drunken_m said:
Hi Guys!
First, thanks for the answers.
Second: "well enough" is not what I would aim for in a high quality and premium device like the TF Prime...
So, if I'm interpreting this right, "we" (the geeks & developers at XDA) need only nvflash for the Prime. That doesn't sound too hard. Personally I don't know nvflash, or how to get it working on the Prime (I'm not a developer), but since we already have root access and an unlocked bootloader it should be no problem.
Click to expand...
Click to collapse
If only it were that simple. Let me know when you have it ready
As for the whole MTP issue, I agree with you but the reality is it ain't going to change any time soon, at least not in the Prime.
The Galaxy Nexus (Google's own flagship device) I think shows the strategy being pursued, which is not only MTP-only, but also has no storage expansion. What Google, Apple and the rest want is to force us all onto the dreaded Cloud and wean us off local storage all together.
BTW, even on the GNex, I am not aware of any ROMs which have implemented UMS, and that phone IS totally unlocked, unlike the Prime.
Sent from my Galaxy Nexus using Tapatalk 2 Beta-4
I've been very frustrated with this issue, but it does make a bit of sense. It sounds like the underlying issue here, going forward, is that what we really need better support across the board. If MTS is going to be the future, it will need to be much more robustly supported on other devices, and we'll need android tools to manage what is available on those devices.
I'm currently looking into other methods of network file access, which will allow me to transfer what I want where I want it, to and from TF201, files of large size and small, with decently high throughput. Running an SFTP server on my tablet looks to be the most likely candidate for what I'm trying to do.
The worst part for me is that MTP volumes are not detected in file recovery programs.. I recently accidentally lost a small lot of pictures and couldn recover them as a result of MTP...
OK, I am starting this thread for a general discussion related to some development work I am currently doing. It involves some fairly low level components of the Android architecture.
I am basing this on CM9, CM being my preferred flavour of Android, but it applies to other flavours too. It will be developed first for an Allwinner A10 tablet (A Momo9 clone) as this is the least important Android device I have lying around, the one which I am least bothered about breaking, but I plan to make these updates as generic as possible to allow easy porting.
OK, on to my objectives:
Make a flexible boot environment system, allowing a device to be booted into different ROMs/configurations, using LVM as a base. This would also allow more flexible use of internal memory, snapshots, and non-persistent data configurations.
*EDIT* By the way, the first part of this (getting LVM2 onto Android) has been completed already by steven676 (see his github repo)
Make additions to CWM recovery to allow management of LVM volumes and boot environments. I have no idea where to start on this one, seeing as I can't even find the source for CWM, but it is necessary to make the project work well.
Make additions to vold and the Android storage settings to allow management of volumes and boot environments from within Android, and to recognise logical volumes for use as internal "SD card". This will probably have to be accomplished using an additional daemon due to license incompatibilities between vold (Apache) and LVM (GPL), but I would like the main interface to my work to be within vold as it is the logical place.
The idea would be that you create an LVM volume group using your internal storage (probably system, data, cache and internal SD partitions), and then define your sys/data/cache/sd etc. as logical volumes within this group. As stated above in objective 1, this gives you flexibility (you can size them as you wish) and access to the snapshot functionality. Snapshots would be great in testing software (you can easily get your device back to a known good config), and would also allow a non-persistent configuration (all changes discarded on reboot, great for handing a device to another person e.g. your kids).
The reason I wish to do this is as a base for my next project, which needs the kind of flexibility this will bring, but I want to keep this discussion on track, so I wont muddy the waters with the details of it yet. However, it will also aid those with small system partitions, developers, and those with small children (or partners... ) who install loadsa rubbish and screw up your device.
The mods I plan to make in CWM should also make it much easier to make update packages for different devices, as I plan to include methods for the updater-script to determine where things should be going (where the system/data/boot etc. devices live), rather than having to hard code them in the script.
So: Thoughts? Advice? Please don't just leave comments of "This is a good/bad idea", I am looking for a constructive discussion.
Thanks in advance
Mouse
I'm not quite following you. Are you planing to boot from an LVM volume? If so, you'll more or less require GRUB2, and does GRUB2 support ATAGS? I believe you'll need 'em both for this to succeed.
Hi
Not quite.
The plan is to use the standard Android boot mechanism to load the kernel and initrd. Within this initrd, the mounting of filesystems (system/data/cache etc) is moved into a separate daemon which chooses them from LVM (or anywhere really). This is limitted, of course, to using just one kernel & initrd (unless kexec can be used, which is beyond the scope of what I need for this project), but it allows much greater flexibility.
drmouse81 said:
The plan is to use the standard Android boot mechanism to load the kernel and initrd. Within this initrd, the mounting of filesystems (system/data/cache etc) is moved into a separate daemon which chooses them from LVM (or anywhere really). This is limitted, of course, to using just one kernel & initrd (unless kexec can be used, which is beyond the scope of what I need for this project), but it allows much greater flexibility.
Click to expand...
Click to collapse
Ah, ok, you are making it easy for you. I do something similar myself. After I boot my custom initramfs, it performs a switchroot to the SDcard, continuing the execution of the real init there. This gives about the same flexibility you are seeking, but also with the same limitation the kernel must stay the same for all systems. This way I can change the system by replacing the SDcard, without the need of LVM.
Yes, this is very similar to what I am in the process of doing. I just think that, especially in devices with large amounts of internal storage (my tab has 16GB) as well as an SD card slot, LVM is a much more flexible solution. Snapshots are the main benefit, but I also plan to use LVM for another project.
Really, the LVM part is pretty simple. The project mentioned on github has the majority of the work done, I am simply extending it at the moment to include some additional features. The majority of the work involved here will be integrating it more closely with both Android and CWM (I expect a steep learing curve: I already develop in both C/C++ and Java, but am not very familliar with the internal workings of Android, and can't even find the sources for CWM).
I do believe it is worth the effort, however. Who knows, it may even make it into CM, or even official Android, at some point... Doubt it, but it is possible
Hi,
I recently got to know, that my tab is using UBIFS as file system...what are the advantages compared to the normal ext2-ext4?
I thought about migrating to the ext filesystems, but if someone tells me that UBIFS is better, I'd stay on UBIFS...
Regards
Hi,
TheSSJ said:
Hi,
I recently got to know, that my tab is using UBIFS as file system...what are the advantages compared to the normal ext2-ext4?
I thought about migrating to the ext filesystems, but if someone tells me that UBIFS is better, I'd stay on UBIFS...
Regards
Click to expand...
Click to collapse
the problem running ext2/3/4 on flash is - sooner or later you will kill the flash. One might not notice it say, on a USB stick, when data is just copied from one place to another occasionally, but things look different if you use it as your root file system where things get written onto it all the time.
I am sure there are more of them around, I am only familiar wit JFFS2 and UBIFS, both are designed for flash media and implement wear leveling routines to make sure that the flash lasts longer.
JFFS2 is somewhat old now, UBIFS is newer and from what I know - better.
I use devices with UBIFS at work and it proved itself very robust, during development I often simply plug off mains without a clean shutdown and I still never ran into a file system corruption or anything like that. So, good to know that our tablets use it
Kind regards,
Jin
Thanks for the clarification. Another question:
Does any kernel support UBIFS or do I normally need to insmod the corresponding module?
TheSSJ said:
I recently got to know, that my tab is using UBIFS as file system...what are the advantages compared to the normal ext2-ext4?
I thought about migrating to the ext file systems, but if someone tells me that UBIFS is better, I'd stay on UBIFS...
Click to expand...
Click to collapse
Different things, different usages.
UBIFS, YAFFS2 etc are file systems for NAND flash devices. Those memories are not block devices.
EXT3, EXT4, VFAT etc are file systems for block devices, and can not use non block devices such as NAND flash devices.
To be able to use a block device file system on a NAND device, you'll need a Flash Translation Layer (FTL). In every USB memory stick, SSD, SDcard etc, you are viewing the NAND flash via such a translation integrated into the device itself, hence you are able to format is using an ordinary file system such as FAT or EXT4. In GNU/Linux (hence Android as well), you've got such a translation layer in the MTD device (look in /proc/mtd).
TheSSJ said:
Thanks for the clarification. Another question:
Does any kernel support UBIFS or do I normally need to insmod the corresponding module?
Click to expand...
Click to collapse
Theoretically it should be doable if you compile the ubifs modules for your kernel, I did not try that yet, when I was using it for some non tablet ARM9 boxes I simply compiled it into the kernel:
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_RESERVE=1
CONFIG_UBIFS_FS=y
CONFIG_UBIFS_FS_XATTR=y
kuisma said:
Different things, different usages.
UBIFS, YAFFS2 etc are file systems for NAND flash devices. Those memories are not block devices.
EXT3, EXT4, VFAT etc are file systems for block devices, and can not use non block devices such as NAND flash devices.
To be able to use a block device file system on a NAND device, you'll need a Flash Translation Layer (FTL). In every USB memory stick, SSD, SDcard etc, you are viewing the NAND flash via such a translation integrated into the device itself, hence you are able to format is using an ordinary file system such as FAT or EXT4. In GNU/Linux (hence Android as well), you've got such a translation layer in the MTD device (look in /proc/mtd).
Click to expand...
Click to collapse
It turned out that TrekStor Ventos 9.7 tablet uses ext4 file systems, does that mean that this is because of the way how they integrated the flash?
As far I know that for USB sticks / SDcards you can not get around the FTL, would be interesting if this is also the case for the Ventos tablet or if switching to UBIFS would be possible there. Main problem with FTL in my opinion is, that it is usually optimized for specific use cases and mostly those use cases do not include write patters that you have when the device is used as a root file system. That's where UBIFS does a much better job at preserving the flash.
Jin^eLD said:
It turned out that TrekStor Ventos 9.7 tablet uses ext4 file systems, does that mean that this is because of the way how they integrated the flash?
Click to expand...
Click to collapse
Somewhere you'll need the FTL. If using MMC technology, it's in the memory device itself.
Jin^eLD said:
As far I know that for USB sticks / SDcards you can not get around the FTL, would be interesting if this is also the case for the Ventos tablet or if switching to UBIFS would be possible there.
Click to expand...
Click to collapse
If FTL in software, such as in the MTD case, this would be possible, yes.
Jin^eLD said:
Main problem with FTL in my opinion is, that it is usually optimized for specific use cases and mostly those use cases do not include write patters that you have when the device is used as a root file system. That's where UBIFS does a much better job at preserving the flash.
Click to expand...
Click to collapse
Android places its root file system in RAM, not in flash.
The FTL is what differs the flash memory (SSDs, MMCs etc) vendors from each other. Some manufacturers priorities read speed, other write speed, and yet other random access etc. Some uses more spare chips extending the life of the device, at the cost of a more expensive unit. Other throttles the write speed to guarantee the functionality during the warranty period. Basically you'll get what you pay for.
kuisma said:
Android places its root file system in RAM, not in flash.
Click to expand...
Click to collapse
Oh.. OK, I did not know that, I'm still quite new to Android. So far I've been playing around with ARM9 devices, building root file systems with OpenEmbedded, but just starting with Android now.
kuisma said:
The FTL is what differs the flash memory (SSDs, MMCs etc) vendors from each other. Some manufacturers priorities read speed, other write speed, and yet other random access etc. Some uses more spare chips extending the life of the device, at the cost of a more expensive unit. Other throttles the write speed to guarantee the functionality during the warranty period. Basically you'll get what you pay for.
Click to expand...
Click to collapse
-> "Basically you'll get what you pay for."
That's what I fear I had very positive experiences with UBIFS so I'd rather rely on it doing the job than on an FTL, which I know nothing about, that is used in my el-cheapo tablet.
Jin^eLD said:
Oh.. OK, I did not know that, I'm still quite new to Android. So far I've been playing around with ARM9 devices, building root file systems with OpenEmbedded, but just starting with Android now.
Click to expand...
Click to collapse
Also, once booted, it remounts root as read-only, so I wouldn't worry too much about wear leveling.
Jin^eLD said:
-> "Basically you'll get what you pay for."
That's what I fear I had very positive experiences with UBIFS so I'd rather rely on it doing the job than on an FTL, which I know nothing about, that is used in my el-cheapo tablet.
Click to expand...
Click to collapse
Sure, if you know what you are doing, controlling the FTL, and you can optimize the performance for the particular task you are using the device for. Buying a ready-to-use device using an integrated FTL, and the manufacturer have no other choice than adjusting the FTL parameters for the average customer usage. Still, in most cases I would say this is good enough and the risk of manually creating an even worse profile is quite likely for a noob such as myself.
kuisma said:
Different things, different usages.
UBIFS, YAFFS2 etc are file systems for NAND flash devices. Those memories are not block devices.
Click to expand...
Click to collapse
Oh, this explains why I got a corrupted recovery by dumping /dev/block/mtdblock3 on my uImage/ubifs powered tab...It worked when I dumped /dev/mtd/mtd3 though...
Thanks for the explanation!
need help !!!!!!!!!!!!!!!!!!!!!!!!!!!
hey bro
how can i take backup of my ubifs rom
and flash ubifs rom on my mt6572 ( in case needed)
TheSSJ said:
Hi,
I recently got to know, that my tab is using UBIFS as file system...what are the advantages compared to the normal ext2-ext4?
I thought about migrating to the ext filesystems, but if someone tells me that UBIFS is better, I'd stay on UBIFS...
Regards
Click to expand...
Click to collapse
Hey bro, you said youll migrate to ext4 if it is better. How can you that? Ive been searching for a way to format my ubifs phone to ext4. I hope you can help me