Next year will see 100GB SSD cheap as chips, but why does Linux need to format an SSD?

And how about a lead out - maybe you'd like to try and learn something about SSDs, flash, disks, filesystems, ram, and pretty much everything else you've got wrong here before continuing?

They are not randomly writeable, unlike RAM.

RAM used for filesystems /is/ formatted. That is how it can work as a filesystem.

Formatting is just a matter of setting up a basic structure on the disk/flash/ram block so that the OS can reliably store and retrieve data. That's all - and that's all that is done with SSD's too.

Erase sectors are not usually so big, but they are still big. And write sectors are also perhaps 4K. This means you can't write less data than that - flash is not randomly writeable, in the way RAM is.

Reading and writing 4K blocks at a time sounds quite like current large hard disks to me.

It is not work of an "MMU". The SSD controller has to handle block erasing, fragmentation, re-mapping, wear levelling, etc. This will always be the case for flash (if the SSD controller doesn't do it, the OS must do it - as it does with bare-bones flash filesystems like jffs2).

It is not a challenge at all. If you are using embedded Linux, you can format, read and write SSDs just like any other media. If you are working on minimal sized embedded systems, you can use a simpler system like FAT.

MMUs are part of the system of directly accessing memory - SSDs (and other flash) is not directly accessed, and the MMU is not involved. Throwing around technical terms that you don't understand does not make you look any better.

You've pulled that claim out of thin air, without showing any knowledge of databases, filesystems, or embedded systems.

The whole point of using embedded Linux is that you can use Linux software - including databases (big ones like Postgresql, small ones like sqllite, or whatever) in exactly the same way as you would on a non-embedded Linux system.

It is fair to say that if you have an embedded system with directly connected flash (NAND or NOR), and you have a particular simple database requirement (say, a logging system), then you could be more efficient by having a simpler structure on the NAND rather than a full-blown filesystem. But that would not be an SSD.

Reply to
David Brown
Loading thread data ...

If any of what you rant about has anything to with reality or is in with the topic, invite yourself back.

Reply to
7

If any of the nonsense that you rant about has anything to do with reality then you should invite yourself back.

Once AGAIN - you seem know absolutely nothing about anything and aren't shy about exposing your ignorance.

--
"I've done for example SQL optimization and the reason I could do it better 
than the best high level experts can do was because I think in hex and bits 
 Click to see the full signature
Reply to
Ezekiel

--------------------------------------------------------------------------------------

So what do you call the process of making a RAM filesystem, for /tmp or /dev, or whatever?

Phil

--
> I'd argue that there is much evidence for the existence of a God.
Pics or it didn't happen.
 Click to see the full signature
Reply to
Phil Carmody

I'm not sure who said this, but please define "formats ram"

or is this a joke ??

Reply to
hamilton

It is partly a joke and partly serious. The operating system must have tables which tell it where things are-- memory, programs, data, drivers, ... That is want a format is, a formal setup about how one finds stuff on a disk drive. Just such a formal setup is also needed for ram. Now on a disk that format is set up once when the disk is readied for storing data. In ram it is set up when the operating system boots ( and dynamically while it runs). But in either case, there needs to be a formal setup allowing things to be found.

Reply to
unruh

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.