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

an SSD?

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

Any storage medium needs formatting, since each filessytem type stores information in different ways on the medium. And you sure would not want to use FAT with all its limitations as a universal filesystem.

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

Does anyone format RAM?

Presumably you do, and on that basis you should be the best placed to answer the second part of the question...?

Chris

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

Are you a Snit?

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

abuse complaints to: snipped-for-privacy@eternal-september.org

Are you an internet troll impersonating Peter Köhlmann again?

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

Idiot

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

Yes. Every operating system formats ram so it can find where in the world the program are that it has to page in, and where the data is, etc. That that formatting goes on internally to the operating system and is not a separate process is irrelevant for this discussion.

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

Are you really this clueless or are you trolling? Storage media needs to be formatted (aka - "organized") to make data retrieval possible.

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

Oops........How harsh against your Mr. president of COLA?, an "intelligent and insightful" leader of COLA, according to Chris Ahlstrom!

-- "Peter Köhlmann" lied in COLA: Message-ID: "I have seen enough quotes of Snit Michael Glassers slander the last days that I am starting to prepare some material about his criminal behaviour

*teh* next days, *wen* I have some *mopre* time at hand. After all, I need to unplonk that POS for the duration, google is too unwieldy for stuff like that

lol !

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

In general, embedded systems don't format RAM. The smaller the system, the less likely.

(e.g. you would have to be seriously stupid to store "Hello World" in a text file in FAT formatted RAM.)

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

Ahlstrom is a suck up. Kohlmann is not.

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

Aha... Is that a rhetorical question I spy....

--
?¡aah, los gringos otra vez!?

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

Is this one of those troll posts? I can only assume it is because you're exhibiting levels of ignorance I thought impossible even for you or Gortard.

That is the principle method of using RAM.

SSD is not much more different.

So somewhere in the annals of history, its all gone wrong.

SSDs being memory that retain data after power down, some additional work needed to extend the RAM model to SSD.

First cut at this (deeply technical):

1. Starting from highest address available and counting down, the data at the higher locations are all just pointers pointing at data in the rest of the SSD which are stored at address beginning at the 0 end.

Call this the root pointer table.

Note 1, 2

1. Pointer data grow from one end, the data itself grows from the other end.

1. No need to format the drive with this scheme!!!!!!!

2. Perfect for the embedded world because there is no code overheads associated with formatting. Put a new SSD in, the drive can be used immediately without having to format it! Perfect for TVs with PVRs, to Linux desktop OSes.

1. Each pointer points to arbitrary lengths of data and is free of context. That creates a problem because each device now doesn't know what data to expect when it opens the pointer table and tries to read the data that each pointer points at.

The best way out of this is to agree on what the first 4 bytes in a structure pointed to by pointers from root table will hold. It should be unique number to indicate specific types of data.

Note 3, 4.

1. Database operations become infinitely easy and orders of magnitude faster for desktops, mainframes and embedded devices. The reason is that each root pointer points to data that identifies itself without needing a filename.

A database program can create thousands of data types and sift through the root table to find all its data without reference to a single file name.

Note 3b.

1. A large part of file management operations can be dropped for faster database, gaming and embedded applications, because the file names and their management is modular and easy to drop when not needed.

Note 3c.

1. Parallel operations by multiple CPUs to manage different data structures independently of each other across multiple SSDs.

A small CPU could be managing the root pointer table, file management tables and cache management on a separate battery backed RAM and write back to the SSD only when it needs to.

This means the file management, doesn't interfere with caching. The caching could be much smarter because it is software controlled.

etc.

Note 1 The pointer with value 0 means its a null pointer while a pointer with all bits set to 1 means its the pointer list terminator. Because 0 is null pointer, sector 0 is is not used for standard data.

Note 2 The root pointer table begins at the last page, but it may be a broken/worn out sector. To detect this, the first 4 bytes are not used and contain a unique improbable number. A check sum of this is number in the last 4 bytes of that sector. These 8 bytes must work out for the data in that sector to be read by operating system and treated as valid. Otherwise operating system moves on to the last but 1 sector to seek a valid sector for the beginning of the root pointer table.

Note 3 The first 4 bytes in a structure pointed to by pointers from root table gives that data a implied data structure.

For example, the value 1 could mean the rest of the data in that block are pointers to bad sectors that should not be used. Value 2 could be used to point to a data structure that gives filenames to data structures pointed to by the root table. Each entry points to a string that is a filename. If the pointer is 0, then no filename exists for that object. For each entry in the root pointer table, there is a corresponding entry in the filename table with same offset. # The separation of file objects from file names is perfect for minimalist embedded systems, as they can use the objects pointed to root table directly without having to maintain filename overheads in many an environment!!

Value 3 could be used to mean a unix style text file.

Value 4 could be used to mean database data objects with another 4 bytes to follow that indicates specific data type such as address, stock code, name, etc.

Some open source authority will have to issue the numbers on a reasonable and free basis to avoid collisions.

Note 3b Value 5 could be used mean a collection of pointers of database data objects. These are copies of pointers taken from root table. It effectively collects randomly scattered data objects to make a complete database. # For embedded this is great because they can now manipulate database objects without file and filename management! No MMU. It is many orders of magnitude faster for desktops and mainframes to use this method because root pointer operations are atomic. You could build a transaction, and switch a pointer at the last minute to complete the transaction.

Note 3c Value 6 could be used to mean file permissions, dates, file size etc. This is useful for standard file management. Again this feature can be dropped in embedded where it may not be needed. Note 4 To prevent running out of numbers, the 4 bytes can be optionally be extended to 8 bytes. The switch over happens when the MSB of the 4 byte number is set to 1 to indicate an 8 byte number.

There are many more advantages to not using a formatted drives for Linux. But I guess it has to begin somewhere, and I'm thinking the pressure to abandon formatting drives will begin when SSDs without formatting coupled to smaller embedded devices begin to eat into the performance of desktops with drives that have formatted disks.

Well done to Mr. Marti Van Lin for sticking his neck out into the proverbial jaws of a crocodile to check if the teeth are sharp.

And well done to Mr. Homer for being so 100% correct.

Thank you for that lead in! :-)

My problems are these:

1. SSDs are randomly accessible with no moving parts They are just slower versions of RAM. RAM is not formatted, but still just as easy to use!

1. SSD read sectors can be 4K, erase sectors may be 512k This will strain every known file system approach.

2. SSDs sectors need erasing before writing. This doubles the work load for an MMU which at the moment skips and dances around the issue.

1. Damn hard to properly format and read/write SSDs in an embedded system which adds layers of overhead.

2. Linux is built with an MMU in mind, but with an SSD, an MMU is extreme waste and extreme overhead.

1. Database support overhead is next to impossible to handle in a small embedded system if a filing system is present.

That won't do with advent of 32 bit cheap as chips computing having arrived on the scene.

Seems to me the slate needs to be wiped clean.

1. Remove MMU. Kiss it good bye now! Replace it with software managed data shuffling and more DMA controllers.

1. Eliminate formatted drives immediately!!

How? Here is something I posted earlier (unfinished).

#-----#

SSDs being memory that retain data after power down, some additional work needed to extend the RAM model to SSD.

First cut at this (deeply technical):

1. Starting from highest address available and counting down, the data at the higher locations are all just pointers pointing at data in the rest of the SSD which are stored at address beginning at the 0 end.

Call this the root pointer table.

Note 1, 2

1. Pointer data grow from one end, the data itself grows from the other end.

1. No need to format the drive with this scheme!!!!!!!

2. Perfect for the embedded world because there is no code overheads associated with formatting. Put a new SSD in, the drive can be used immediately without having to format it! Perfect for TVs with PVRs, to Linux desktop OSes.

1. Each pointer points to arbitrary lengths of data and is free of context. That creates a problem because each device now doesn't know what data to expect when it opens the pointer table and tries to read the data that each pointer points at.

The best way out of this is to agree on what the first 4 bytes in a structure pointed to by pointers from root table will hold. It should be unique number to indicate specific types of data.

Note 3, 4.

1. Database operations become infinitely easy and orders of magnitude faster for desktops, mainframes and embedded devices. The reason is that each root pointer points to data that identifies itself without needing a filename.

A database program can create thousands of data types and sift through the root table to find all its data without reference to a single file name.

Note 3b.

1. A large part of file management operations can be dropped for faster database, gaming and embedded applications, because the file names and their management is modular and easy to drop when not needed.

Note 3c.

1. Parallel operations by multiple CPUs to manage different data structures independently of each other across multiple SSDs.

A small CPU could be managing the root pointer table, file management tables and cache management on a separate battery backed RAM and write back to the SSD only when it needs to.

This means the file management, doesn't interfere with caching. The caching could be much smarter because it is software controlled.

etc.

Note 1 The pointer with value 0 means its a null pointer while a pointer with all bits set to 1 means its the pointer list terminator. Because 0 is null pointer, sector 0 is is not used for standard data.

Note 2 The root pointer table begins at the last page, but it may be a broken/worn out sector. To detect this, the first 4 bytes are not used and contain a unique improbable number. A check sum of this is number in the last 4 bytes of that sector. These 8 bytes must work out for the data in that sector to be read by operating system and treated as valid. Otherwise operating system moves on to the last but 1 sector to seek a valid sector for the beginning of the root pointer table.

Note 3 The first 4 bytes in a structure pointed to by pointers from root table gives that data a implied data structure.

For example, the value 1 could mean the rest of the data in that block are pointers to bad sectors that should not be used. Value 2 could be used to point to a data structure that gives filenames to data structures pointed to by the root table. Each entry points to a string that is a filename. If the pointer is 0, then no filename exists for that object. For each entry in the root pointer table, there is a corresponding entry in the filename table with same offset. # The separation of file objects from file names is perfect for minimalist embedded systems, as they can use the objects pointed to root table directly without having to maintain filename overheads in many an environment!!

Value 3 could be used to mean a unix style text file.

Value 4 could be used to mean database data objects with another 4 bytes to follow that indicates specific data type such as address, stock code, name, etc.

Some open source authority will have to issue the numbers on a reasonable and free basis to avoid collisions.

Note 3b Value 5 could be used mean a collection of pointers of database data objects. These are copies of pointers taken from root table. It effectively collects randomly scattered data objects to make a complete database. # For embedded this is great because they can now manipulate database objects without file and filename management! No MMU. It is many orders of magnitude faster for desktops and mainframes to use this method because root pointer operations are atomic. You could build a transaction, and switch a pointer at the last minute to complete the transaction.

Note 3c Value 6 could be used to mean file permissions, dates, file size etc. This is useful for standard file management. Again this feature can be dropped in embedded where it may not be needed. Note 4 To prevent running out of numbers, the 4 bytes can be optionally be extended to 8 bytes. The switch over happens when the MSB of the 4 byte number is set to 1 to indicate an 8 byte number.

Already been done. It's effectively what happens when someone "formats" a drive. The data-block bitmaps and inode-bitmaps are initialized and then used to indicate what sections of disk (or RAM in this case) are available and which are not.

--
If you know the assembler in detail, you would know what "select * from 
employees" would translate into Assembler and how different and yet similar 
that would be from "select name from employees"

Babbling idiot "7"
March 7, 2012

snipped-for-privacy@eternal-september.org

Meet Ezekiel - Burson-Marselar troll trolling Linux newsgroups.

Just because appil and micoshaft are loosing business to Linux, thats not a good reason for Burson-Marstelar employees to be trolling Linux newsgroups on their behalf.

snipped-for-privacy@eternal-september.org

Meet Ezekiel - Burson-Marselar troll trolling Linux newsgroups.

Just because appil and micoshaft are loosing business to Linux, thats not a good reason for Burson-Marstelar employees to be trolling Linux newsgroups on their behalf.

What time does a "pretend software engineer" like you go to work at Quickie Mart today?

Does your cash register run Linux? Why do you look like a donkey?

--

"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 
and byte movements."

Babbling idiot "7"
March 6, 2012