[ltp] Does hdaps [APS] work on non-Thinkpad hard drives?

[Laurent Gilson]

Hello,

> My knowledge is very limited, but the problem I see in regards SSD or  
> NAND
> flash is not only the price, but also the problem with reliability.

I worked with embedded systems that use CF-cards for HD (LXE VX*, Adept
robots). These systems write logs, use it as swap, get used in really
tough environments, get bounced around, have unstable voltages ... all
the bad stuff. I never had real problems with flash. OK the cards are
top-of-the-line industrial models and are exchanged every 3 years.

> Recoverability on a NAND flash is almost non-existent.

Yes, that is true. You are out of luck if a NAND chip fails.

> On a normal hard
> drive, there are specific ways to get around bad sectors and other types  
> of problems that always crop up.

Good news everyone: cards have spare cells, just like the spare tracks on a
HD. The bad news: there is nothing like SMART to check the status. But you
can guess the size of the spare cells by looking at the raw, unformated
cardcapacity. NAND-chips are manufactured with 2^x bytes capacity. But a
4GB card may only have like 4.000.000.000 bytes... the rest is spare or
DOA.

> The other problem that I see is regards to the life-time of a NAND  
> flash. Like a normal flash drive, using it as a normal main file storage  
> device where it is accessed constantly and under heavy load will result  
> in a much shorter life span than a normal hard drive.

HDs get slower over time, flash does not. After 3 years most people will
exchange both anyway.


--- switch from flash to ram-based linux ---


> Is it possible to suspend to ram and suspend to disk when using a  
> ramdisc?

Suspend to ram works just fine with stock acpi/suspend-config. Suspend to  
disk
"works" after some tweaking, but is not a real option. Writing and reading  
back
1 - 1.5 GB of data is painfully slow. I think the HD is in PIO-Mode during  
the
reading? Normal restarting is faster.

> And how do you go about updates and installing new software?

The system can boot in RAM or in HD mode. In HD mode it's a normal debian  
etch
install so a monthly "apt-get update; apt-get upgrade" is no problem.

In RAM mode squashfs-images are used. These are read-only. Recreating them  
after
updates/installs takes about 15 mins. Fast incremental updates are  
possible too,
but waste a bit of space. The images for a fully useable desktop with  
dev-tools for
java, apache, SQL-server, OpenOffice, opera, irc, ftp,... take about  
550MB. 650MB
if you want eye-candy (Compiz + Gnome + themes). Just look at the  
knoppix-CD edition
to get an idea.

> What about saving data?

Everything is in RAM until i run a backup-script or shutdown. No risk, no  
fun.

> What about if the computer needs to process more data than available  
> memory (such as copying a DVD)?

The kernelbased OOM-killer kicks in and the most RAM-hungry process is  
killed
(my config. Usually the least used process is killed). Most OOM-kills  
happen
when something really bad is going on, like a a heavy memleak or a runaway  
loop.

OK, creating ISO-images locally in RAM is a bad idea. But i can always use
the HD for that. Its no problem to put temp-files from xcdroast in /HD/tmp
and not /tmp. Reading/writing a CD is not slient anyway. (xcdroast and k3br
will fail to launch with /tmp in RAM anyway: the ramdiscfs always reports
0 bytes free. These 2 are the only progs that actually check the free space
before creating files ... that still scares me).

> I may be mistaken, but if you save to your ramdisc then it is really not  
> saved. Once you reboot that data is gone since it was merely in memory.

The shutdown and backupscripts create a tar-file for /home, /etc and  
changes in
/var. /usr, /lib and /sbin are mounted ro anyway. The tars are read back  
into
RAM at startup. I only lose data if the battery goes bad or linux crashs  
very
hard. My last softwarerelated linux crash happend in 2005.

cu