Computing desk
< February 4	<< Jan \| February \| Mar >>	February 6 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

February 5

RAM & ROM on Smartphones

As I understand it so far:

ROM is non-volatile internal memory where (on smartphones [that are not rooted]) the OS (& many apps) are stored.

RAM is volatile internal memory that the apps use (as working space) when they are running.

If a phone (such as the Samsung S3) has 16 GB of internal memory & its specs say it has 2 GB of RAM, does that mean there are 14 GB for ROM?

Also: Am I correct that the trend in the Android OS is to have all the apps loaded in ROM? --JimWae (talk) 09:29, 5 February 2015 (UTC)[reply]

That phone has 16 GB of flash memory and (separately) 2 GB of RAM, and some unmentioned amount of ROM. Flash memory is nonvolatile. I think you may be thinking of flash memory when you say ROM. -- BenRG (talk) 10:32, 5 February 2015 (UTC)[reply]

A flash drive has non-volatile RAM, but its contents are easily changed. I'm not confusing Flash RAM with ROM. I've seen several phone specs that mention ROM. The Galaxy Core is said to have 16 GB of internal memory, 1.5 GB of RAM, & 8 GB of ROM -- so I guess my simple subtraction is NOT the solution. On phones, ROM seems to be what they use to talk about internal memory that users cannot change (but that perhaps apps can be installed to). It seems to be where (along with the OS) pre-installed apps that cannot be removed (except by rooting) are stored.

What's confusing me is specs having separate numbers for Internal Memory & RAM. The RAM is internal memory, no? ROM is internal memory, yes? What else is there in internal memory? --JimWae (talk) 11:01, 5 February 2015 (UTC)[reply]

"ROM" there means built-in flash memory (as mentioned below). So does "internal memory". If you install a custom "ROM" on your phone, that also goes in flash memory. The terminology is inconsistent and confusing. If they quote two numbers, x GB and y GB, and x < y, it's safe to assume that x is RAM and y is flash memory. I don't think any smartphone has anywhere close to 1 GB of genuinely read-only memory. -- BenRG (talk) 22:08, 5 February 2015 (UTC)[reply]

this reminds me of the 1 MB (& up) computers that could only use 640K because part of the higher addressed space was the OS. Then HIMEM.SYS was used to swap that content to higher memory (above 1MB address?), and then use some of 640K to 1MB address for RAM.--JimWae (talk) 11:09, 5 February 2015 (UTC)[reply]

Go careful. Those terms are thrown around very carelessly in the smartphone world. I'm also not sure where you found the specs you quote; according to Samsung, this device has 8GB 'ROM' and 1GB 'RAM'. What they mean is that it has 8GB of internal flash, though this can be supplemented with a micro SD card to add an extra 64GB. That combined flash memory (8GB + whatever SD card is installed) has to house the permanent storage of both the OS and apps that are installed; according to the page referenced above, of the 8GB internal flash, 5GB is 'user-accessible', which basically means that the OS and the bundled apps you can't uninstall add up to 3GB, leaving 5GB (+ whatever SD card is installed) to install apps and store data.

Flash memory like this is different to what is traditionally meant by 'ROM', where some read only memory is mapped into the memory address space of the processor; this 'ROM' is actually treated in the same way as a hard drive in a computer.

RAM is entirely different. This doesn't hold its contents once the device is powered off and is used for storing the running state of the OS and apps. This state is transient, unless it is written back to flash memory.

In summary, the numbers quoted for RAM and ROM capacities don't relate to each other. This device has 1GB of RAM and 8GB of ROM, of which 3GB is occupied when you receive the device, leaving 5GB for you to install apps and store data. GoldenRing (talk) 11:17, 5 February 2015 (UTC)[reply]

OK, maybe it makes more sense now: the Galaxy S4 SGH-I337M (according to Samsung) has 16 GB internal memory, [MAXIMUM] User Accessible Memory is approximately 8.2GB, also has 2GB RAM. The RAM is never? used for storage of files or apps or OS themselves, just for data - temporarily. The external memory [SD card], like a hard drive, stores files (not the OS, but MAYBE some OS settings?)--JimWae (talk) 11:55, 5 February 2015 (UTC)[reply]

The Samsung Galaxy S4 is available with 16GB, 32GB, or 64GB of internal flash storage. although the latter is very rare. My 32GB version reports (home -> menu -> settings -> more -> storage) that there is 23.6 GB total space on the internal storage. Thus, there is 8.4 GB missing. There may be some accounted for in differences between GiB and GB, and for file system overhead. However, I suspect most of that is the operating system. As the OS is user-upgradable, I think the phone boots off a small BIOS-type ROM, and which then loads Android from the internal flash drive, much like how a PC boots. LongHairedFop (talk) 12:22, 5 February 2015 (UTC)[reply]

Falling Hard Drive

Hello all; my hard drive seems to be slowly failing. It has been displaying bad sector messages in Event Viewer. I attempted to do one final complete backup to another hard drive, by both manually copying and also Windows' built in backup, but the copy stalls and the "activity" light on the hard drive is constantly lit until the computer is hard reset. Strangely, I could use the the hard drive just fine with no visible problems other than when attempting to make another complete data backup (downloading/uploading files, even large ones, works fine). I've tried doing so on the "failing" drive itself and via a second drive that also has an OS installed on it. When the copy is attempted there, the same thing happens, and the second hard drive can't even finish shutting down the OS when it happens.

I assume the copy is failing when it finds the bad sectors on the drive. I've removed the drive and used my alternate one until I can find a solution. Is there any way to ignore or bypass bad sectors when copying? Any other ideas of what I can do? -- 143.85.169.18 (talk) 16:54, 5 February 2015 (UTC)[reply]

Microsoft ScanDisk is supposed to identify bad sectors, and mark them as unusable. You could try that. But, if new sectors are going bad all the time, it might be too late for that. StuRat (talk) 17:05, 5 February 2015 (UTC)[reply]

Should have mentioned that I've already ran CHKDSK (Windows 7), and that hasn't solved anything. I know the drive is beginning to fail, so what I'm wanting to do now is safely/reliably get my remaining data off the drive and trash it. -- 143.85.169.18 (talk) 19:27, 5 February 2015 (UTC)[reply]

The problem you have is exactly what ddrescue was built to address. -- Finlay McWalterᚠTalk 20:37, 5 February 2015 (UTC)[reply]

There are a number of tools' I use TestDisk but it does require some skill. -- Gadget850^talk 12:12, 7 February 2015 (UTC)[reply]

Are you sure? The description page you linked to suggest it is completely inappropriate for what the OP is trying to do, whatever the user's skill level. I don't see any discussion of imaging, nor handling bad sectors encounter during imaging. TestDisk may be useful after the OP has successfully image the disk, but that wasn't what the OP was asking about and since the OP is apparently trying to recover data off a physically damaged possibly dying HD, they want to image the disk and not fool around with it in situ.

BTW chkdsk/scandisk are also very bad ideas in a case like this. Yes they will mark try and move data from bad sectors elsewhere, and mark them as bad in the file system, but that's not what you want to do here. You don't want to be writing to the disk at all, and you don't want to be trying to hard to read the bad sectors initially.

Edit: [1] seems to confirm my view that TestDisk is likely a poor choice.

And I should perhaps clarify that in a few cases, it may be better to not image the disk. In particular if you're sure you only want to recover a small subset of files on the disk, it may be better to only try and copy those, rather than make a whole disk image given the risk the whole disk image (even with an advanced tool like ddrescue) could lead to further damage in the important parts before you successful image those parts containing the desired files.

However, even in that case, I'm not sure that TestDisk is normally necessary or helpful. To me, it sounds like it will only be helpful if the partition structure is actually damaged, which from the OPs description above may not be the case here. Even if the partition structure is damaged, I wonder if TestDisk is the best choice.

Ideally you want a tool like ddrescue which is designed to recognise damaged areas of the disk and preferably avoid reading them if there are files you are trying to recover in other areas which might not be damaged. I'm still not seeing any sign that TestDisk really has any understanding of physical damage on the disk, and how to deal with it. That said, I don't know of any particular tool that can deal with this. It's possible that ddrescue would work in cases when the partition structure is fine, but I'm not sure, it may only be useful for whole disk or part disk imaging rather than for dealing at the partition file level.

Nil Einne (talk) 14:09, 7 February 2015 (UTC)[reply]