Groups > comp.os.linux.advocacy > #96917

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

From	Homer <usenet@slated.org>
Newsgroups	comp.os.linux.advocacy
Subject	Re: Next year will see 100GB SSD cheap as chips, but why does Linux need to format an SSD?
Date	2012-03-23 07:32 +0000
Organization	Slated.org
Message-ID	<8ilt39-b5k.ln1@sky.matrix> (permalink)
References	<H4Lar.16022$VY2.3692@fx05.am4> <oKLar.2691$BZ2.582@newsfe07.iad> <DMLar.46912$mH5.16276@fx06.am4> <jkgmb8$830$1@news.albasani.net>

Show all headers | View raw

Verily I say unto thee that Marti Van Lin spake thusly:
> [Follow up set to comp.os.linux.advocacy]
> On 22-03-12 21:16, 7 wrote:
>> unruh wrote:
>>>
>>> Any storage medium needs formatting,
>>
>> Does anyone format RAM?
>
> Yes, Linux does it at every bootstrap. What do you think initrd does?

That's not "formatting RAM" though, it's just extracting a compressed
archive of software into an allocated area of RAM. That reserved area
is treated like a block device and a filesystem, but it's really only
a virtual container within the RAM itself.

Typical utilisation of RAM only requires the hardware identifies what
RAM is available and its addresses (RAM map), then software "mallocs"
what it needs dynamically. E.g.:

BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000ce000 - 00000000000d2000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)
 BIOS-e820: 000000003fff0000 - 000000003fff8000 (ACPI data)
 BIOS-e820: 000000003fff8000 - 0000000040000000 (ACPI NVS)
 BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)

...

init_memory_mapping: 0000000000000000-0000000037fa1000
 0000000000 - 0000200000 page 4k
 0000200000 - 0037e00000 page 2M
 0037e00000 - 0037fa1000 page 4k
kernel direct mapping tables up to 37fa1000 @ 1bfb000-1c00000
RAMDISK: 37cae000 - 37ff0000
Allocated new RAMDISK: 3796c000 - 37cadbb8

The software then retains an array of pointers to the location in RAM
where that object is, so it can access it, and "free" it when it's no
longer required.

There are certainly parallels between this and a disk storage device.
One could think of the physical RAM map as the disk geometry, and the
array of memory pointers as a file allocation table, so in that sense
there is a sort of "filesystem" in memory, insofar as the location of
objects in memory are known (hopefully), but there's no formatting of
RAM as such, it's simply used directly.

The initrd/initramfs is one example where a virtual container, almost
like a "partition", is allocated in RAM. Another is /dev/shm which is
shared memory for interprocess communication (roughly, a "RAM disk").
If you have CONFIG_SHMEM=y in your kernel config then you should have
a filesystem of type tmpfs mounted directly under /dev/shm (note, not
/mnt), and you should be able to use it like any other storage device
(but you'll lose everything in there when you reboot).

You can dynamically control the maximum allocation of memory for SHM,
by either changing /proc/sys/kernel/shmmax or using sysctl like this:

sysctl -w kernel.shmmax=<number of bytes>

You can make your preferences persistent by editing /etc/sysctl.conf.
The current default (at least on Gentoo) seems to be 33554432.

> http://en.wikipedia.org/wiki/Ramdisk
>
> They have been around and very useful since the early 1980's or perhaps 
> even before.

The Amiga had a persistent RAM disk called "RAD" which one could boot
from, which was very useful for debugging, or running buggy software,
since it was much faster than booting from a floppy disk. Although it
had to be explicitly mounted, formatted then installed with AmigaDOS,
and you lost the contents whenever you powered-off. Like all AmigaDOS
devices you could create an entry in DEVS:DOSDrivers to automount it,
roughly comparable to fstab. I had an ARexx script that formatted and
installed it at every cold-boot.

I'm not aware of anything comparable to that on any modern OS. AFAIK,
the nearest equivalent would be the ACPI S3 state known as Suspend To
RAM, but that's not quite the same thing as a clean boot from a fixed
RAM disk.

This looks promising, but AFAICT it's not bootable:

http://pramfs.sourceforge.net

-- 
K.                           | "You see? You cannot kill me. There is no flesh
http://slated.org            |  and blood within this cloak to kill. There is
Fedora 8 (Werewolf) on šky   |  only an idea. And ideas are bulletproof."
kernel 2.6.31.5, up 44 days  |    ~ V for Vendetta.

Back to comp.os.linux.advocacy | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

csiph-web