Heya..
I copied all my apps to my sd card...but im wondering how I can install and run the apps from the sd so they arnt in phone memory?
Can't find any info on this >_< i mite just suck as searching though
Thanks in advance
/bump
anyone?
depends, if you have root, and if your on the T-mobile G1 or the Rogers HTC.
you should read up a bit more before posting, some of this stuff can be found very easily and you don't even specify which phone you have.
either case you still need to root your phone.
if your with rogers dream, than your stuck, it isn't possible yet
oh sorry.
i have a rogers htc dream rooted...so its nto possible? darn, any idea when it mite be available?
D
hmm...didn't know it wasn't possible on the Rogers. I figured he could just root, partition and install the latest Cyanogen ROM
if you can install cyanogen's rom, you can just partition your sdcard to ext3 and cyans rom will automatically set up apps to sd
make sure the fat partition comes first
fat32, ext3 partition
make sure the ext3 partition isnt greater than 1.5gb
use the search function for info on the above
i read you can't use cynaogens roms on rogers though..something about incompatability?
D
What are the chances of being able to ditch all the concerns that go along with Ext2, Ext3, and Ext4 hacks to improve read-write on the Captivate by going with YAFFS or YAFFS2?
http://en.wikipedia.org/wiki/YAFFS
YAFFS is an optimized filesystem for use with NAND flash memory, would it provide the stability and speed we're looking for?
I know this idea has been discussed lightly before in the various "lag fix" threads, but I was wondering if users with knowledge could enlighten the rest of us on the YAFFS filesystem.
I may be way wrong here, but judging by a few commands I've seen regarding busybox install issues, is it possible the stock kernel supports this already?? In which case could we modify the current lag fixes to use it instead?
Since this is related and I already posted this in Nuka's thread:
http://forum.xda-developers.com/showthread.php?t=750663
Those wacky gents over in the I9000 section have managed to get YAFFS2 compatibility into the kernel. This is something we should probably look into once we've figured out the wake-lag issue (maybe sooner )
In other news, assuming we can get YAFFS2 plugged into our kernel, how feasible (albiet probably complicated) would it be to actually REPLACE RFS and then load the OS on top of YAFFS2? There's just something about cascading file systems written on top of each other that sounds like trouble to me.
Zilch25 said:
Since this is related and I already posted this in Nuka's thread:
http://forum.xda-developers.com/showthread.php?t=750663
Those wacky gents over in the I9000 section have managed to get YAFFS2 compatibility into the kernel. This is something we should probably look into once we've figured out the wake-lag issue (maybe sooner )
Click to expand...
Click to collapse
Nice find!
I agree, the wake-up-lag issue is bothersome. Looking forward to mimocan possibly helping us out with his solution that he offered the Samset people.
kennethpenn said:
What are the chances of being able to ditch all the concerns that go along with Ext2, Ext3, and Ext4 hacks to improve read-write on the Captivate by going with YAFFS or YAFFS2?
http://en.wikipedia.org/wiki/YAFFS
YAFFS is an optimized filesystem for use with NAND flash memory, would it provide the stability and speed we're looking for?
I know this idea has been discussed lightly before in the various "lag fix" threads, but I was wondering if users with knowledge could enlighten the rest of us on the YAFFS filesystem.
Click to expand...
Click to collapse
Using a FS designed for Flash media will help with some of the fixes but not all. For example the mimocan fix it should help, as it will reduce overhead and increase the longevity of the Flash. Also since the mimocan fix is on the external card, it is properly un-mounted at shut down so this helps stop corruption.
Conversly it won't really do anything for the ext2 fix because that is a virtual disk sitting on top of another FS, which is not un-mounted at shutdown.
Potentially a custom ROM could replace the FS on the internal flash, but Samsung must have did what they did for a reason. It is hard to tell if they did what they did because they were lazy / didn't know any better, or they knew something we don't.
Bjd223 said:
Potentially a custom ROM could replace the FS on the internal flash, but Samsung must have did what they did for a reason. It is hard to tell if they did what they did because they were lazy / didn't know any better, or they knew something we don't.
Click to expand...
Click to collapse
Samsung use rfs because for some misguided and twisted reason some manager there thinks it is good and proprietary so they have a leg up on the competition. They go on about how quick rfs mounts as a benefit (yaffs and other flash files systems are slow to mount).
RFS isn't exactly terrible in the right places - the /dbdata symlink hack works because RFS-on-NAND is faster than RFS-on-SD, even though raw reads on the internal SD are faster than on the OneNAND partitions. I suspect it simply interacts poorly with devices that already do their own remapping and wear-leveling, or perhaps that the performance hit is a result of using much larger blocks on /data. I wonder what would happen if one just formatted /data with smaller blocks than 16KiB?
kennethpenn said:
YAFFS is an optimized filesystem for use with NAND flash memory
Click to expand...
Click to collapse
That already explains it all. I do not think it can be used on SD. This is copy-paste from UBIFS, but I believe it is the same for YAFFS:
This is why UBIFS does not work on MMC cards and the like - they look like block devices to the outside world because they implement FTL (Flash Translation Layer) support in hardware, which simply speaking emulates a block device on top of the built-in raw flash.
Click to expand...
Click to collapse
For the ext2 hack with loop device (file formated as ext2) I have no idea if it is any better.
Why do I feel like i'm the only one without the wake up lag issue? .
tbae2 said:
Why do I feel like i'm the only one without the wake up lag issue? .
Click to expand...
Click to collapse
I bet u r on stock kernel
Sent from my SAMSUNG-SGH-I897 using XDA App
Doesn't the Captivate already use yaffs2? Try running "mount" in a terminal emulator or in adb shell.
junknuts said:
Doesn't the Captivate already use yaffs2? Try running "mount" in a terminal emulator or in adb shell.
Click to expand...
Click to collapse
no, it uses rfs for everything...
yaffs2 is not really any better than rfs, both file systems, however, are not intended for use on SD memory. In other words you would be exerting great effort to get yaffs2 as your file system for the NAND part of your phone, and get little to no improvement. As for the mimocam fixes and the like that use your SD card or Internal Memory (Internal SD Card essentially), ext2, 3, or 4 would still be better options than yaffs2 or rfs as they are intended for true NAND Flash memory not block based SD memory.
tbae2 said:
Why do I feel like i'm the only one without the wake up lag issue? .
Click to expand...
Click to collapse
Ok, silly question...what is "wake up lag"? Either thats too technical of a term, or too vague, I dont really get it.
derek4484 said:
Ok, silly question...what is "wake up lag"? Either thats too technical of a term, or too vague, I dont really get it.
Click to expand...
Click to collapse
When you don't use your phone for a while, the phone goes into a "sleep" mode where the screen is totally black and does not respond to any touch. To "wake up" the phone, you press the power button, after which you can see the phone locked screen, and the screen responds to touch again. On a normal Captivate with the precompiled kernel installed by Samsung, or on a Captivate where you have flashed the same precompiled kerenel via Odin, the delay between pressing the power button, and seeing the phone locked sceen is usually less than a second or so. On phones where a kernel compiled from the Samsung released source code (either with or without any modifications) is flashed on, there is a much longer delay between the power button press, and the phone waking up to show the phone locked screen. This is what we mean by wake up lag. We still don't know what causes the rebuilt kernels to lag on wake up.
*Moved question to General*
Flash memory: NAND vs SD?
Hello,
Mr Taco above made a distinction that I can't figure out. He suggests that YAFFS is for "NAND" memory and not "block based SD." Here is my confusion.
From what I have read, it appears as though typical flash multimedia drives, such as MMC and other SD cards, are all created from NAND chips (as opposed to the less-memory-dense NOR chips). So I do not understand the distinction between "NAND" and "SD."
Also, he mentions "block based" devices. But as far as I can tell, "block level" has to do with the *interface* to storage and not the nature of the storage itself. For example, one could map a bunch of random access memory and present it as a block device (say, so it could be treated as a disk with a filesystem). Similarly, mmap and other techniques use disk storage with a memory-like interface (as opposed to a block interface).
So here are some questions I have that might help me figure this out:
1. Presumably the Captivate has some true RAM, that is, non-NAND chips that give truly random access memory that is not persistent upon shutdown.
2. That RAM has a normal (non-MTD) interface (512MB?).
3. Besides this RAM, the Captivate has an internal NAND-based flash drive (2gb).
4. It also has another internal NAND-based flash drive (16GB).
5. It has an external slot for a micro sd card, a NAND-based flash device accepting up to 32GB.
If these are all true, I have questions.
A. Is mimocam's (sp?) solution to use actual RAM, synced to flash, to load certain partitions?
B. Or is his solution implemented on the internal 2GB flash?
C. Certainly, other solutions have used external and internal flash (the ext2 solution, for example).
D. So, isn't it still true that any solution that would rely on the 2GB, internal 16GB or external NAND-flash would profit from using YAFFS?
Thank you in advance,
-0
zeroaltitude said:
Mr Taco above made a distinction that I can't figure out. He suggests that YAFFS is for "NAND" memory and not "block based SD." Here is my confusion.
From what I have read, it appears as though typical flash multimedia drives, such as MMC and other SD cards, are all created from NAND chips (as opposed to the less-memory-dense NOR chips). So I do not understand the distinction between "NAND" and "SD."
Click to expand...
Click to collapse
I'll repeat once again, it is from UBIFS page, but afaik it is the same for yaffs and others:
One thing people have to understand when dealing with UBIFS is that UBIFS is very different to any traditional file system - it does not work on top of block devices (like hard drives, MMC/SD cards, USB flash drives, SSDs, etc). UBIFS was designed to work on top of raw flash, which has nothing to do with block devices. This is why UBIFS does not work on MMC cards and the like - they look like block devices to the outside world because they implement FTL (Flash Translation Layer) support in hardware, which simply speaking emulates a block device on top of the built-in raw flash.
Click to expand...
Click to collapse
"One thing people have to understand when dealing with UBIFS is that UBIFS is very different to any traditional file system - it does not work on top of block devices (like hard drives, MMC/SD cards, USB flash drives, SSDs, etc). UBIFS was designed to work on top of raw flash, which has nothing to do with block devices. This is why UBIFS does not work on MMC cards and the like - they look like block devices to the outside world because they implement FTL (Flash Translation Layer) support in hardware, which simply speaking emulates a block device on top of the built-in raw flash."
Although I do appreciate the attempt to answer my questions, this reply is very puzzling.
My question was why did Mr Taco make a *distinction* between SD and NAND as far as flash memory goes. The reply, quoted above, *lumps SD and NAND devices together*. Furthermore, the primary topic of the quotation is yet another filesystem, UBIFS, that is not even under discussion (at least, not in my post it wasn't).
So, I'm happy to read up on UBIFS, however, I don't see how that can possibly answer the specific questions I have. I hope someone with some familiarity with device drivers or filesystem internals will drop by this thread. Otherwise, it's back to the research .
-0
NAND flash is typically configured so that for each block of stored data, there is a sub-block for supplementary data. This is used for wear-levelling, etc. "Raw" NAND devices such as kernel mtd devices expose this as well as the data portion of each block, and filesystems like yaffs2 and ubifs incorporate wear-levelling into the filesystem design, and rely on having direct access to raw flash.
SD cards contain a controller that does its own wear-levelling, and expose only the data segment of each block. Yaffs2 and ubifs will simply not work on such a device, nor are they really appropriate choices for it. A block-oriented filesystem is needed here, and because we can't guarantee graceful shutdowns, it needs to have some sort of data integrity scheme. Ext3/4 are journalled, Samsung's RFS is FAT with copy-on-write added, and the other possibilities here are nilfs2 and btrfs - but there are no backports of reasonable recent btrfs versions for the kernel Samsung has provided to us.
Unhelpful said:
nilfs2 and btrfs - but there are no backports of reasonable recent btrfs versions for the kernel Samsung has provided to us.
Click to expand...
Click to collapse
Thanks. I'm a bit boring to explain the basic things ppl can google first.
About fs. Do we need metadata or block level journaling?
We can consider ReiserFS or JFS? btrfs sounds nice tho.
Given that /system and a few other partitions are ext4 already, I know kernel support is built it. I'm guessing I'd need to root the device and edit the script that mounts/unmounts the microSD card. Anyone else know an easier way to do it? Apparently noone who manufactures tablets needs files over 4GB...Idiots.
I may give this a try today to see if I can figure out an easy way to do it. Although, I really need TrueCrypt support since most of my external drives are truecrypt containers. :-(
I suppose with root access it'd be a simple matter of mount -t ext4 /dev/block/whateversdcards /mnt/sdcard
I've still yet to root my device to test it though.
Did you ever give this a try?
It would be even cooler if we could convert the internal sdcard to ext4. It seems to be FAT32 as well. Then we could do a symlink under sdcard to the micro.
Okay, I've literally been working on this for the last 2 days, tried everything I've found so far, and the most progress I've made was (somehow) making both sdcard and extsdcard show the same storage mount, but I have no clue what change made that occur for one reboot. So far, I've tried the following:
vold.fstab editing
build.prop editing
FolderMount (desparate...)
I've even tried the debuggerd script I found in this other forum, and yes I edited the script to point to the correct vold blocks (in my case they're 179:96 and 179:97 for the internal and external storage, respectively)
While I'm not against using a fully custom rom for these tablets (I have two), the dilemma is that my 4-year-old sons use them, so the KidsMode needs to function properly. They've run out of storage space on these due to three FREAKING HUGE games they absolutely insist on keeping on the tablets at all times, and apps like GL to SD need to be run and remounted on every reboot, so it isn't a suitable solution...
Best case, I would love a boot.img swap so it'll be zero-maintenance. I've been searching and so far I haven't turned up anything I can use... I'm a long-time "power user" with several devices running custom kernels, various builds of CM, and even a modded version of CM12 on my tablet I compiled myself. I'm not a beginner, but I'm definitely out of my league on this one.. Any assistance will be appreciated.
UPDATE
I'ne partially succeeded. I've figured out how to remount /sdcard to the external sd card, but it's not a perfect redirect. It shows in file managers, but not in the Settings under Storage, and the free space shown in Application Manager is blank (crashes in a few seconds), or it continues to show the real internal sd card info. I used the following single command in the debuggerd.mnt file:
Code:
mount -t vfat -o rw /dev/block/vold/179:97 /storage/sdcard0
no luck
No luck with the swap... The only option I believe I have at this point is to either install a custom rom (but I haven't found a single one...), or I need to pull the boot.img to edit it. So far I've not been able to find the boot partition, and the "by-name" list doesn't mention anything related to "boot"
My last thought is to try to extract it from a stock firmware. Is that possible? I don't have linux running, and all boot devices are disabled on my work laptop so a live distro isn't an option...
Any help or opinions will be greatly appreciated...
Hello all.
Phone, OS and Problem Description
I have some problems with my klte, always running a fairly recent Lineeage OS 14.x ersion. Sometimes when taking photos or having other write access to my external sd card, my phone reboots. It just crashes and the picture taken is not being saved properly. If I mount the sdcard using a microsd-to-sd adapter on my linux machine, I can see the corrupted file.
I them have to put the sd card into a Windows PC (i don't own one, but others in my household luckily do) to clean up the exFAT partition. This is a no go and often very annoying when travelling or being at work. Even TWRP won’t do.
Perhaps the sd card is broken, it's a Transcend Premium 64GiB Class 10 UHS-1 microsd card.
Anyway. I'd like to use ext4 (w/o journal), btrfs or f2fs or any other FS on my external sdcard as the only partition. I can mount and fsck that on my linux and in TWRP.
So, what did I do so far?
I tried f2fs.
Sadly, if i write a folder to such a partition in LOS14 using FX file explorer, it will belong to u1_a12 and the very same app won't even be able to list files in that directory. Yes, the execute bit is missing on that folder. So this won't work.
I tried ext4
Same as above
btrfs perhaps?
I didn’t try it so far.
Does this work with Resurrection Remix, Slim or crDroid? Are there any other options? I loved SlimBean on my Galaxy Nexus, but there isn’t a current official release for klte, sadly.
Any recommendations? I’m open to switching my rom, I had ResurrectionRemix Marshmallow for a year or so on my S5. Also, I’d be open for other ideas how to check my sdcard more thoroughly. Perhaps using badblocks or F3.
Thanks in advance for your opinion and input!
Any progress on this?