Related
Hi
I bought a kingston 512mb sd, but my xdaII is reporting it as a 483,55 mb size...
I already tried to format it with FAT32 but didn't solve it
any idea ?
thanks!
Memory
I ain't no IT guru but this much I know.
There's this memory mystery which has been around that I tried reading about before however after attempting to digest the article I'd rather it remained a mystery.
:mrgreen:
It's normal Bro. Hopefully some expert will provide a proper explanation for you. In the mean time I hope you can take my word for it.
Here's a screenshot of my 512MB SD card memory.
The main reason for the difference in size is this, even though your SD is a "memory" card, your PPC treats it like a disk drive - you format it with a FAT file system.
FAT stands for File Allocation Table, meaning that there is a table stored on the media (just like on a hard drive or floppy drive) that stores the location of the files on the media so they can be located quickly and easily, since files are not stored contiguously. Think of it as an index.
The larger the media, the larger the FAT. For instance, the following are my SD cards and their FAT sizes: 128MB/8MB; 256MB/16MB; 512MB/32MB; 1GB/58MB.
HTH
argh
:shock:
How didn't remember that ? :roll:
You know, the card was so much expensive than i wanted to pay, that when i tested it, i just felt reaaaaallly mad!
(i was just thinking how much does 29mb cost!)
thanks for the replys and fast help!
Actually, there was a patch, that allowed to use the space, that is not physically taken by FAT32: FAT32 reserves 32b for each possible catalog. If your catalogs are only, for instance, 12b long - you don't need resting 20b, but it's reserved by FAT, so you can't store anything there! The bigger storage you have, the more it reserves! The patch allowes you use the spase unless it's physically taken.
I'll try to find the patch till the end of the week and post it.
PS: you can also format your card in FAT16 or even FAT8 - both will take less space!
big fat making diet
that would be great! thanks!
Oops
Oops!
So the memory mystery don't apply in this huh?
Sorry hbatista for giving wrong info.
Thanks guys for the enlightenment.
The other reason is some retailers claim 512 megabytes, however their megabyte is 1000kb whereas we are used to the idea that a megabyte is 1024kb.
Kignston explanation
Hi
Before i posted to this forum i contacted kigston and here their explanation:
"Dear Mr. Batista,
Regarding your below request:
The fact that your flashcard shows about 6% less of its capacity is quite normal and the following will try to explain why:
When formatted to a specific file system, storage devices such as the Kingston flash card SD/512 "loose" a small amount of capacity because this is used by the file system to store file system information. Operating systems (such as Windows, for instance) will format using 1K=1024 bytes rather than 1K=1000 bytes resulting in some residual loss of capacity.
SD technology comes with a security feature that enables manufacturers to add specific hardware controlled security features for their software when stored on an SD card. More information regarding this can be obtained from the SDA (Secure Digital Association) at http://www.sdcard.org. Furthermore a so-called "OS overhead" exists, where the operation system stores OS specific data on the storage device. The overhead varies between different OS.
An overall overhead of 29MB is well within limits and you will find that it will be the normal amount of overhead for the SD/512 for your OS.
You can observe the same effect for all your other storage devices, especially hard drives.
Usually the reduction of available data is in the range of 2%-7%. You can try and replace the card at your point of purchase, if you feel that the problem is related to a defect of the card rather than the above phenomenon, however it is most likely that the replacement will show the same capacity.
Regards"
Click to expand...
Click to collapse
I defragged my SD and the performance gain was considerable. Is there any program that can defrag the main memory or the Storage?
i used my cardreader, but i think that's diffrent :?
Defragmenting flash or SD memory is useless since every address on the chip has the same access time. Defragmentation only makes sense with devices like hard disks, where the relative location of data plays a role.
is there any way of defragmenting the device itself not the SD card
Dandie said:
Defragmenting flash or SD memory is useless since every address on the chip has the same access time. Defragmentation only makes sense with devices like hard disks, where the relative location of data plays a role.
Click to expand...
Click to collapse
Not quite sure I understand your response. Using Pocket Mechanic, I can format the SD card with FAT16 or FAT32. Both file systems can become fragmented...
BTW, Pocket Mechanic can defragment the internal storage memory (if you rename it to something other than "Storage" - it seems to have a problem with the default Magician file name), but NOT the main memory file system.
stevedebi said:
Dandie said:
Defragmenting flash or SD memory is useless since every address on the chip has the same access time. Defragmentation only makes sense with devices like hard disks, where the relative location of data plays a role.
Click to expand...
Click to collapse
Not quite sure I understand your response. Using Pocket Mechanic, I can format the SD card with FAT16 or FAT32. Both file systems can become fragmented...
Click to expand...
Click to collapse
Yes, they can become fragmented, even NTFS can get fragmented although MS designed it not to. But that is besides the point, as pointed out before. Defragmenting can speed up (and mechanically relieve) all devices that use mechanical means to retrieve the data. On a hard disk there are tracks kind of like on an old vinyl audio media. Fragmentation in this context means you want to listen to track 1,3,7,9 and 11. So you have to lift the needle after each track and reposition it. Same happens when a hard disk wants to read a file smeared across multiple tracks on the disk platter. It reads some part, then has ro reposition the head and keep reading. Defragmenting puts the data of one file into one long track so the time needed for positioning is eiliminated. In the analogy that would be pressing a new vinyl disk that only contains the tracks desired (1,3,7,9,11) just one after another. You won't have to lift the needle anymore.
This is the theory. But for memory chips (all kinds, be it RAM, ROM, USB-Sticks, SD-Cards, ..., any storage media with NO MOVING Parts) this is not applicable. When the system wants File A it looks in the File Table where that file is located. Then it gets a list of positions and starts requesting the contents of these positions from the card device. The access time to any of these positions is exactly the same. Go back to the audio comparison. For a vinyl disk you have to lift and reposition the needle if you selectively want to hear certain songs only. If you had the same album on a MP3 player or other device you can arrange your playlist and no matter in which order or position the tracks are the time until the player starts playing them is the same.
Hope that clears it up. I am actually not too sure why the PocketMechanic author has put in Defragmentation. It does not make sense to me. Maybe on FAT devices there is a slight advantage to having the files en bloc because that way their position data is more compact (just START-END or something as opposed to START1-END1 ... START2-END2 ...) but I am not sure about this. Even if this was the case your only gain would be a few bytes of SPACE not TIME.
Takes ages too to defragment a SD-card. So if you insist in defragmenting you'd better put your SD in a card-reader & transfer the contents to your harddisk, format the card if you like (faster than deleting) or delete everything & transfer everything back.
M
STAY AWAY from defragging flash memory!!!
1.) This doesn't help anything, it won't be faster. Flash memory is adressed directly (like already said) and doesn't need to be defragged.
2.) If you want (for whatever reason) the files to be in one piece (that's what defragging does) on the flash memory, simply copy the contents of the card to the PCs harddisk, reformat the card and copy the stuff back on. This has the same result as defragging.
3.) Defragging will destroy you card! Flash memory has a limited amoung of read/write cycles before the will die someday. It's unlikely you'll ever see that in real life use because read/write cycles are used faithfully by PPCs. However defragging uses an insane amount of read/write cycles since data is read and written so often from one point to another that it will shorten the lifetime of the card noticeably.
I don't know why defragging of flash memory is offered at all, it's no good at all and only damages the cards in the long run. But maybe it's a feature that has to be "there".
Wow, I never knew that. :!: I had been faithfully defragging my SD once every few months; I am going to stop doing that.
Always learn something new around here! 8)
Well, best is to use that format method and move the contents to the PC and after formating the flash memory card copy the stuff back on. This has the same effect as defraggin, takes much less time (since defraggin flash mem in a PPC is not that fast at all) and has no negative effect on the lifetime. I tend to do that once in 2-3 month. But the speed gain is not even worth mentioning, it's basically nonexistant.
Can someone explain to me what is inside the vibrant that is used as storage.
People refer to the internal memory card, why, is it an actual memory card or is it simply because apps cannot be stored there.
Why is the app storage space limited to 2gb if the internal memory is 16gb, and if all 16gb resides on the same medium can't it just be symlinked similar to what people do with apps2sd on other phones with no detriment in performance?
Calcvictim said:
Can someone explain to me what is inside the vibrant that is used as storage.
People refer to the internal memory card, why, is it an actual memory card or is it simply because apps cannot be stored there.
Why is the app storage space limited to 2gb if the internal memory is 16gb, and if all 16gb resides on the same medium can't it just be symlinked similar to what people do with apps2sd on other phones with no detriment in performance?
Click to expand...
Click to collapse
There are 2 storage types soldered onto the vibrant. NAND (fast, small) and "flash" (16g, slow).
The nand is split up for various things like booting, firmware (/system), cache, etc. And - to solve lag with their own apps - 128 megs of it is split out for the built-in apps to use. (That is the 'method 1' fix - move all app data to nand, where it is super fast.)
The 16 gigs of flash is much slower than nand, and split into 2 sections:
- /data (mmcblk0p1) is android apps, app storage, settings, etc. (2 gigs of "application space"). This is the standard android-phone onboard storage, and not accessible to the PC.
- /sdcard (mmcblk0p2) is the 14 gig media/misc space. Standard fat filesystem, shown when you plug into the PC. (They basically subverted the standard android sdcard handling for this - solves some problems, but causes others.)
The removable sd is mounted to "/sdcard/sd".
^ awesome post man, care if I stick it in the sticky?
Disconn3ct said:
There are 2 storage types soldered onto the vibrant. NAND (fast, small) and "flash" (16g, slow).
The nand is split up for various things like booting, etc. And - to solve lag with their own apps - 128 megs of it is split out for the built-in apps to use. (That is the 'method 1' fix - move all apps to nand, where it is super fast.)
The flash is much slower than nand, and split into 2 sections:
- /data is android apps, app storage, settings, etc. (2 gigs of "application space"). This is the standard android-phone onboard storage, and not accessible to the PC.
- /sdcard is the large media/misc space. Standard fat filesystem, shown when you plug into the PC. (They basically subverted the standard android sdcard handling for this - solves some problems, but causes others.)
The removable sd is mounted to "/sdcard/sd".
Click to expand...
Click to collapse
so RyanZA's lag fix, which creates a 1gb file system within the 2 gigs....why can't it be mapped outside of the original appspace since everything resides on flash anyway, the speeds should be the same, no?
s15274n said:
^ awesome post man, care if I stick it in the sticky?
Click to expand...
Click to collapse
Sure. (I wanted to doublecheck some info, so it is slightly updated.)
Calcvictim said:
so RyanZA's lag fix, which creates a 1gb file system within the 2 gigs....why can't it be mapped outside of the original appspace since everything resides on flash anyway, the speeds should be the same, no?
Click to expand...
Click to collapse
"mapped outside the original appspace"? Those words all make sense but not in that order
Data (and cache and so forth) all use samsung's proprietary RFS filesystem. (It has been described as "fat with wear levelling, unix perms and journalling".) The loopback mount fix basically bypasses all that and just shows rfs a large monolithic file. You lose reliability (journal) and flash protection (wear levelling, erase optimization) and so forth, but get speeds much closer to the raw flash. (Personally, I'm a fan of not prematurely destroying soldered on storage..)
One of the things to be tried is yaffs/jffs in place of rfs - all the advantages/protections with much better performance..
Disconn3ct said:
"mapped outside the original appspace"? Those words all make sense but not in that order
Click to expand...
Click to collapse
I understand about the RFS, I just don't really understand why the appspace is limited to 2 gigs when there are 16 gigs on the same piece of silicon. Why is it not a matter of partitioning and mounting the other 16 gigs?
Calcvictim said:
I understand about the RFS, I just don't really understand why the appspace is limited to 2 gigs when there are 16 gigs on the same piece of silicon. Why is it not a matter of partitioning and mounting the other 16 gigs?
Click to expand...
Click to collapse
First, it's not "the other 16 gigs". It is 16 gigs total - 2 for apps/data, 14 for media/etc.
How pissed would you be if only kies (and adb) could get to that storage? That's why - 14 of it is presented as vfat, so that it can be exported over usb to the pc. You might be able to adjust the split a little (eg 8/8) using modified pit files and odin, but I wouldn't even count on that..
Certainly you can't share the space - android security guarantees that only the app (well, and root, but..) can read the app's files. Not the pc, not other apps. So you need something vfat hasn't got (owners, permissions) and you need to not export it to the pc where those limits won't be enforced. (Finally, you only get one fs user at a time - if you have it on the pc, you can't have it on the phone. "Please reboot into usb mode" hasn't been OK since the late 90s...)
Disconn3ct said:
First, it's not "the other 16 gigs". It is 16 gigs total - 2 for apps/data, 14 for media/etc.
How pissed would you be if only kies (and adb) could get to that storage? That's why - 14 of it is presented as vfat, so that it can be exported over usb to the pc. You might be able to adjust the split a little (eg 8/8) using modified pit files and odin, but I wouldn't even count on that..
Certainly you can't share the space - android security guarantees that only the app (well, and root, but..) can read the app's files. Not the pc, not other apps. So you need something vfat hasn't got (owners, permissions) and you need to not export it to the pc where those limits won't be enforced. (Finally, you only get one fs user at a time - if you have it on the pc, you can't have it on the phone. "Please reboot into usb mode" hasn't been OK since the late 90s...)
Click to expand...
Click to collapse
Ok, so if someone did modify the PIT file then it would be possible. It's not a hardware limitation, but just the way the firmware is setup.
What speed is the other 14Gb? How does it compare to standard microSD? Class 4 at least?
Calcvictim said:
Ok, so if someone did modify the PIT file then it would be possible. It's not a hardware limitation, but just the way the firmware is setup.
Click to expand...
Click to collapse
Modify the pit, and the bootloader, and (possibly) the rfs partition scheme, and (possibly) the kernel.
People found a pit that changes the layout a little bit and they're getting a higher-than-normal percentage of bricks. (I don't know how high, but look at all the odin threads that warn against using the new pit..) It is doable, but not reliable yet. Did you already fill 2 gigs of app storage? Thats .. kinda nuts.
applebook said:
What speed is the other 14Gb? How does it compare to standard microSD? Class 4 at least?
Click to expand...
Click to collapse
They claim class 6. With rfs, it is ok until you get to multiple requests - then it goes all thrashy instead of threading properly..
If it's around class 6, then I'm satisfied. Since that memory is for storing media, I have little use for anything much faster anyway.
Disconn3ct said:
People found a pit that changes the layout a little bit and they're getting a higher-than-normal percentage of bricks. (I don't know how high, but look at all the odin threads that warn against using the new pit..) It is doable, but not reliable yet. Did you already fill 2 gigs of app storage? Thats .. kinda nuts.
.
Click to expand...
Click to collapse
I didn't fill the 2 gigs but I don't use the phone for media really, it's just apps and games and just wandering since it would be nice to have more storage for those things.
So what is the size difference between the Vibrants with the larger NAND and the smaller NAND?
What difference does this make in the real world?
Why would they put two different size NAND chips?
SamsungVibrant said:
Why would they put two different size NAND chips?
Click to expand...
Click to collapse
Samsung does some weird things sometimes
Disconn3ct said:
"mapped outside the original appspace"? Those words all make sense but not in that order
Data (and cache and so forth) all use samsung's proprietary RFS filesystem. (It has been described as "fat with wear levelling, unix perms and journalling".) The loopback mount fix basically bypasses all that and just shows rfs a large monolithic file. You lose reliability (journal) and flash protection (wear levelling, erase optimization) and so forth, but get speeds much closer to the raw flash. (Personally, I'm a fan of not prematurely destroying soldered on storage..)
One of the things to be tried is yaffs/jffs in place of rfs - all the advantages/protections with much better performance..
Click to expand...
Click to collapse
So are you saying that samsung's filesystem (rfs) causes wear and tear to the flash drive? Do any of the lag fixes that replace the rfs filesystem (ext 2/3/4) cause wear and tear to the drive as well? I am personally not applying a lag fix for this reason, but if samsung's rfs does that already, might as well take the plunge with a lag fix...
I read somewhere that the nexus one uses a filesystem created for flash drives - it started with a y, probably the yaffs that you spoke of?
Sent from my SGH-T959 using XDA App
veol said:
So are you saying that samsung's filesystem (rfs) causes wear and tear to the flash drive? Do any of the lag fixes that replace the rfs filesystem (ext 2/3/4) cause wear and tear to the drive as well? I am personally not applying a lag fix for this reason, but if samsung's rfs does that already, might as well take the plunge with a lag fix...
I read somewhere that the nexus one uses a filesystem created for flash drives - it started with a y, probably the yaffs that you spoke of?
Sent from my SGH-T959 using XDA App
Click to expand...
Click to collapse
I took him to mean that a loopback mount style lagfix, like OCLF, can cause premature deterioration.
Kubernetes said:
I took him to mean that a loopback mount style lagfix, like OCLF, can cause premature deterioration.
Click to expand...
Click to collapse
That all depends on how samsung implemented wear leveling. It would be insanely stupid to do it in a way that would cause premature death of the flash with a loop file system though. Wear leveling is generally done at the block level so that file systems that have to write to fixed locations a lot like fat don't kill that block. As rfs is fat, I think it's unlikely that it will cause issues.
We can't use yaffs2 and friends without replacing the kernel driver for the flash. They don't work on block devices, they require raw flash access. I suspect it will also require a new secondary boot loader. I wouldn't attempt it without a dev phone and jtag access.
ttabbal said:
That all depends on how samsung implemented wear leveling. It would be insanely stupid to do it in a way that would cause premature death of the flash with a loop file system though. Wear leveling is generally done at the block level so that file systems that have to write to fixed locations a lot like fat don't kill that block. As rfs is fat, I think it's unlikely that it will cause issues.
We can't use yaffs2 and friends without replacing the kernel driver for the flash. They don't work on block devices, they require raw flash access. I suspect it will also require a new secondary boot loader. I wouldn't attempt it without a dev phone and jtag access.
Click to expand...
Click to collapse
Ah... sorry for asking a noobish question and being off-topic a little, but if I were to use a lagfix, which one is best (for the flash drive)?
Thanks for the questions and the answers and for laying it out in understandable terms! A good read.
Sent from my SGH-T959 using XDA App
I am trying to understand the folder structure on the TF.
I have a 16GB micros SD card and I want all data type files to be saved there e.g. photos, downloads, music etc.
There is a folder at the top level called /SDCARD and I had assumed that this was the MicroSD card and all this sort of data is being stored in sub folder from there.
I have now realised that the MicroSD card is actually accessed from /Removable/MicroSD and that the TF has not stored anything on it. I have just moved my music and video to there.
Can I move all the other SDCARD subfolders to /Removable/MicroSD and then delete the SDCARD folder?
I can't see the point of having a folder called SDCARD it is very misleading.
Thanks for any help.
This is your internal storage. I'm not sure why it is displayed this way, maybe that will become standard in Gingerbread?
You cannot 'delete' the SDCARD folder. It is a mount point for the remainder of your internal storage (16GB or 32GB)
As bizarre as it seems when compared to a phone, this actually makes more sense. My Droid X has 6.5GB of the 8GB internal memory put aside for the /data partition. Despite having the phone for a full year and having a ton of apps installed, /data still has 5GB free. That's 5GB of storage I do not have access to, so it's effectively wasted.
On the ASUS (and others HC tabs?) that space exists as a virtual device /dev/fuse and is mounted as /mnt/sdcard. A symbolic link exists /sdcard which points to the mount point. The net result is, you have the majority of free space on the internal memory available to you. If you didn't, there'd be no incentive to buy the 32GB version over the 16GB version.
It is called /sdcard to maintain the illusion within the OS. This space, like it or not, is your primary storage. It makes your actual sdcard more of a transient storage location, great for just music, movies, etc., that you do not necessarily want to keep on the device long term. This is a great advantage as you can keep multiple sdcards with different content and not worry about messing up the core OS storage needs.
Be aware that the OS and apps expect to find certain data in /sdcard and moving the folders to your 'external' card will only force these apps and processes to recreate the folders in /sdcard. Also some apps will have lost some of their data and may not operate as expected or will act as when they were first installed (games will redownload supporting data, for example)
Sent from my rooted ASUS Transformer running PRIME 1.4
jhanford said:
You cannot 'delete' the SDCARD folder. It is a mount point for the remainder of your internal storage (16GB or 32GB)
As bizarre as it seems when compared to a phone, this actually makes more sense. My Droid X has 6.5GB of the 8GB internal memory put aside for the /data partition. Despite having the phone for a full year and having a ton of apps installed, /data still has 5GB free. That's 5GB of storage I do not have access to, so it's effectively wasted.
On the ASUS (and others HC tabs?) that space exists as a virtual device /dev/fuse and is mounted as /mnt/sdcard. A symbolic link exists /sdcard which points to the mount point. The net result is, you have the majority of free space on the internal memory available to you. If you didn't, there'd be no incentive to buy the 32GB version over the 16GB version.
It is called /sdcard to maintain the illusion within the OS. This space, like it or not, is your primary storage. It makes your actual sdcard more of a transient storage location, great for just music, movies, etc., that you do not necessarily want to keep on the device long term. This is a great advantage as you can keep multiple sdcards with different content and not worry about messing up the core OS storage needs.
Be aware that the OS and apps expect to find certain data in /sdcard and moving the folders to your 'external' card will only force these apps and processes to recreate the folders in /sdcard. Also some apps will have lost some of their data and may not operate as expected or will act as when they were first installed (games will redownload supporting data, for example)
Sent from my rooted ASUS Transformer running PRIME 1.4
Click to expand...
Click to collapse
After reading your explanation, it makes better sense to me. I was a bit annoyed, but I see how this could work to my favor. Using just the actual SD cards for movies, music, ect.
Moving data - Video
Sorry, I find what is said here a little disconcerting.
Why have SD cards and USB devices attached (eg. USB Flash drives, hard drives) when the data flow only goes one way, "in", and not out.
If I want to edit a video, the files are too large to email.
I can't find a way to move the video to an external device.
All one can do, as far as I can tell, is to upload the unedited video to YouTube.
Once there initially one get an error message saying that the file type is not recognized. It is...eventually, but only after it's fully processed. This is really confusing to the user. You'd think Google would give Android users a processing message rather than something that makes you think there is no way to view and share your video other than your tablet.
I couldn't find a way to tag a video either.
The default seemed to be "entertainment."
The options for sharing video are much to limited.
The only site you can upload a video to is YouTube.
I'd love to be able to put it on another site (e.g. a personal/corporate website).
I sure wish there were a way of off-loading and storing a folder generated from the Tablet to an external device, especially one with external ports like the Transformer.
If anyone knows of an app to do two way data flows, I'd sure like to know about it because my SHDC card and USB Flash drives look so lonely with nothing to do.
[email protected] said:
Sorry, I find what is said here a little disconcerting.
Why have SD cards and USB devices attached (eg. USB Flash drives, hard drives) when the data flow only goes one way, "in", and not out.
If I want to edit a video, the files are too large to email.
I can't find a way to move the video to an external device.
All one can do, as far as I can tell, is to upload the unedited video to YouTube.
Once there initially one get an error message saying that the file type is not recognized. It is...eventually, but only after it's fully processed. This is really confusing to the user. You'd think Google would give Android users a processing message rather than something that makes you think there is no way to view and share your video other than your tablet.
I couldn't find a way to tag a video either.
The default seemed to be "entertainment."
The options for sharing video are much to limited.
The only site you can upload a video to is YouTube.
I'd love to be able to put it on another site (e.g. a personal/corporate website).
I sure wish there were a way of off-loading and storing a folder generated from the Tablet to an external device, especially one with external ports like the Transformer.
If anyone knows of an app to do two way data flows, I'd sure like to know about it because my SHDC card and USB Flash drives look so lonely with nothing to do.
Click to expand...
Click to collapse
There is nothing stopping you from copy files from the internal storage to an external sdcard. From the built-in file manager you can select a folder using the check boxes to the left of it, and then click the Copy or Cut button at the top of the screen, then navigate up until you see "Removable". Tap that and then "MicroSD" and then you can tap "Paste" at the top of the screen to copy or move to the new location.
Sent from my Transformer TF101 using XDA Premium App
Drive letters or some kind of unique ID from the root would be favorable. I know it's meant to adapt to Android, but last time I checked, Honeycomb was a separat version of the OS. It's unfortunate that it has to fool both the user and itself to be effective.
moo99 said:
Drive letters or some kind of unique ID from the root would be favorable. I know it's meant to adapt to Android, but last time I checked, Honeycomb was a separat version of the OS. It's unfortunate that it has to fool both the user and itself to be effective.
Click to expand...
Click to collapse
It still maintains the overall Adroid/Linux filesystem structure, there are no lettered drives in *NIX.
I know that, bru. Calling it , I dont know, "Internal" instead of "SD Card" would make a little sense considering there are two separate ports for SD Cards on there. Writing an alias isnt that complicated
Hi all!
Just an idea, would it be feasible to use say 2GB of RAM for a drive used to store pictures on, for even better performance? Or is the UFS 2.1 just as fast?
This is an idea for a custom ROM feature, hence the chosen forum section!
Kind Regards
TwinAdk
LPDDR4 is much faster, But as we know RAM is a volatile memory and what ever you do goes puff!!!
Unless we create a dump of the ram when rebooting/shutdown-ing
shazzy1 said:
LPDDR4 is much faster, But as we know RAM is a volatile memory and what ever you do goes puff!!!
Unless we create a dump of the ram when rebooting/shutdown-ing
Click to expand...
Click to collapse
Good point! Possibly create a control panel to control the usage of the ram drive, and have the content moved from RD to defined destination when the app that saves the data (camera app, download manager, Chrome, Firefox, etc) is no longer in focus?
And then symlink between locations so the system is left clueless :good::victory:
Great ideas here!!
Sent from my NEM-L21 using XDA Labs
LOL! Almost the same question, 30 minutes earlier...
https://forum.xda-developers.com/oneplus-5/help/best-to-extra-ram-t3625570
Linux probably supports RAM drives out of the box, so I doubt it would be that much work.
What the heck are you doing with pictures on a phone that you require better performance than UFS 2.1?
Chaleman said:
LOL! Almost the same question, 30 minutes earlier...
https://forum.xda-developers.com/oneplus-5/help/best-to-extra-ram-t3625570
Click to expand...
Click to collapse
Yeah, though that's general cache thoughts, this is the creation of a drive, usable by any app, or the user Great minds think alike!
ABotelho23 said:
Linux probably supports RAM drives out of the box, so I doubt it would be that much work.
What the heck are you doing with pictures on a phone that you require better performance than UFS 2.1?
Click to expand...
Click to collapse
I'm just thinking of the write speed that will increase. Then the content can be loaded off the drive when the user is leaving it idle. It will give an even better experience when writing stuff to disk. Do you see the potential that the users write command is done instantly, so the user can move on with things. The system can then handle the offload in the background when the user do not have to wait
I would love that feature!
Kind Regards
TwinAdk
Sent from my NEM-L21 using XDA Labs
Not sure if swap is still in use, but on my old Xperia (and a couple of others) swap was created as a RD and supposedly it helped a lot. With a beast like OP5 though not sure if that would help and if this is still in place and used .. I stopped following a couple threads when I broke that Xperia so kind of digging from memory
caki25 said:
Not sure if swap is still in use, but on my old Xperia (and a couple of others) swap was created as a RD and supposedly it helped a lot. With a beast like OP5 though not sure if that would help and if this is still in place and used .. I stopped following a couple threads when I broke that Xperia so kind of digging from memory
Click to expand...
Click to collapse
On older phones I guess RD makes more sense, but as long as RAM is faster than disk (and you have RAM to spare) RD makes some sense :silly:
Sent from my NEM-L21 using XDA Labs
caki25 said:
Not sure if swap is still in use, but on my old Xperia (and a couple of others) swap was created as a RD and supposedly it helped a lot. With a beast like OP5 though not sure if that would help and if this is still in place and used .. I stopped following a couple threads when I broke that Xperia so kind of digging from memory
Click to expand...
Click to collapse
Swap created as ramdisk? That doesn't make any sense. Mounting a ramdisk as swap is worse than useless.
davfiala said:
Swap created as ramdisk? That doesn't make any sense. Mounting a ramdisk as swap is worse than useless.
Click to expand...
Click to collapse
it does, if you use compression to sort of extend the size of the memory. If configured properly, it might bypass android's swappiness, but still keep the app's data in RAM for faster switchover. Not the most elegant solution, but it just might work. With so much memory that the OP5 has, that it can't really exhaust it, it's a bit pointless.
TwinAdk said:
On older phones I guess RD makes more sense, but as long as RAM is faster than disk (and you have RAM to spare) RD makes some sense :silly:
Sent from my NEM-L21 using XDA Labs
Click to expand...
Click to collapse
yeah, agreed, was just thinking aloud. I don't see that much into the internals of Android, but as you said earlier, some sort of quick cache might be worth a shot.
Running a ramdisk as a mount for /tmp is a common trick on Linux to make processes that write a lot of tempfiles run a bit faster. I don't know how Android handles tempfiles, but if it stores them all in one place like on GNU-style systems in should work as well. But I suspect not many Android apps write tempfiles anyway...
TwinAdk said:
Yeah, though that's general cache thoughts, this is the creation of a drive, usable by any app, or the user Great minds think alike!
I'm just thinking of the write speed that will increase. Then the content can be loaded off the drive when the user is leaving it idle. It will give an even better experience when writing stuff to disk. Do you see the potential that the users write command is done instantly, so the user can move on with things. The system can then handle the offload in the background when the user do not have to wait
I would love that feature!
Kind Regards
TwinAdk
Sent from my NEM-L21 using XDA Labs
Click to expand...
Click to collapse
Of course the write speed will increase. But for pictures, would it not be negligible?
ABotelho23 said:
Of course the write speed will increase. But for pictures, would it not be negligible?
Click to expand...
Click to collapse
Yes, it would be :laugh:
Sent from my NEM-L21 using XDA Labs
using tmpfs would be much easier than a ramdisk.
off the top of my head you would need to work out a few things
if you wanted it to be 'persistent' you would need to run some kind of scheduled rsync or background process to sync the data (lsync) to a dir on the ufs filesystem
either way you open yourself to data loss if during the scheduled window, or during the lsync, the phone reboots or crashes
you would also need to write an init script to create the tmpfs mount and sync back the data from the ufs filesystem
What would be a good candidate for 'ultra fast data'? Maybe the dir the camera stores files? What about the cached data each app stores?... you would probably have to limit this to a certain set of apps because you could run into an issue with space depending on how large you make the tmpfs mount...is that even something possible? I can't remember I haven't look at where the cache is stored
A memcached style setup might be nice... But that's probably similar to how the "app priority" feature works.
I'm actually looking for a way to create a ramdisk on my OnePlus 3T.
Is there any detailed description/explanation of how to make one or if there are any apps available that can do it for me?
Respond asap.
LOS ER said:
I'm actually looking for a way to create a ramdisk on my OnePlus 3T.
Is there any detailed description/explanation of how to make one or if there are any apps available that can do it for me?
Respond asap.
Click to expand...
Click to collapse
Sorry to bump up old thread, but maybe other are googling and directed here. So I better post my finding here and maybe other can benefit.
I have been searching for the holy grail for so long and finally found it. I am using RN5 whyred and trying to reserve 100 MB RAM for temporary storage and file processing for my Automagic flow. It is meant to reduce write cycle on the emmc. I have been trying to mount tmpfs on the /storage/emulate/0 and found out not working, the file still stored on emmc. Because I tried to reboot and the file still there.
I am currently using custom ROM AEX 6.7 Pie 9.0. When I use command mount, I can find tmpfs is mounted on /storage/self. So I thought to create a new folder inside it and chmod 777, /storage/self/ramdrive. Then I copy file to it using MiXplorer. And the speed is amazing.
I then check on the command free | grep Shmem
The size is increasing, means the RAM is being used for the storage. Deleting the file will reduce it, so it is working !
Testing copying file to internal storage, 750 MB takes about 12 seconds, while copy to the ramdrive takes about 5 seconds. Leave the file at ramdrive and restart the phone, the file disappear. So it is confirmed that the file is stored at RAM.
So for other, if you want to mount ramdrive, you need root. You need at least terminal emulator. But MiXplorer with root access can also create the folder. Try to check your tmpfs file first using
Code:
mount | grep tmpfs
I found several and use /storage/self. So I create additional folder there
Code:
mkdir /storage/self/ramdrive
chmod 777 /storage/self/ramdrive
This folder disappear at every reboot, so I use Automagic startup to recreate it at every reboot.
I then point my flow to save or process file at that path. By default the limit is half from the total RAM, which is 2 GB from my 4 GB RAM. I am thinking to find the script to limit the size, but rather than playing with the mount script, I better disciplined my flow to not store too much here.
Using the ramdrive, now I can lavishly store and delete temporary file there without worrying reducing my emmc lifespan.
I know, topic is old... But I found this discussion while searching for a solution to my problem, which is as follows:
I want to run a Dos emulator on my android device (to play windows 3.11 and dos games). I will do it with Magic Dosbox or even Limbo PC Emulator.
Point is: given the poor lifespan of sd cards and internal storage of mobile devices, it would be great if I could run such DOS "virtual machines" on ram disks, to avoid degrading the mobile's storage with all the read/write methods on the disk image (in case of Limbo) or in the folder (in case of Magic Dosbox).
So, I ask:
a) do Magic Dosbox have this feature? (I didn't find it on the documentation)
b) can I prepare a ram disk before running Magic Dosbox, to load a specific folder content or a specific disk image?