I'm in the process of upgrading my desktop and am interested in using an ssd disc for system and program files but I never want to write to it except for updates. My home directory and it's associated temp will be on a hard drive as will swap but I am not clear what temp files the os and various programs make use of.

The reason for never writing to it is based on using the technology in the automotive field. Generally data retention time for reads is enormous but have to admit that very low nm technology generally isn't use there. As to writes there is some info here

https://wiki.archlinux.org/index.php/Solid_State_Drives

It struck me that as linux can be booted from a usb stick there must be a mechanism for arranging all temp files where ever they go to or come from to end up in ram. In some ways I would prefer the option of a hard disc but am not sure how to set up either. If they go to ram there would be a need to clear them out automatically really. I don't reboot my machine very often. Currently the systems memory of files in temp seem to be shorter than their lifetime on disc. I'm think particularly of something I often do - click and open a pdf from the web. These go to root tmp. Afraid I am not aware if something ever removes them. There are also many many folders and other bits and pieces in it.

Any ideas as to what would need to be done? I will probably be running opensuse 12.3 KDE and am not much of a kernel person even thought I have used linux for a long long time.

John
-

I use 64 gb ssd disk for system, apps, and data. it has little space but enough to become bloated, so I regulary clean mess with Baobab. I belive that disk become slower over time with usage, but never as slow as normal hard drives.

Hi,

The linked Arch wiki information is based on older technology and should be brought up to date. I suggest that you look at SSDWiki;
Depending on the device manufacture and your configuration for operation to get the max life out of the modern SSD you should still create backups. Newer SSD controllers along with density will dictate life. Wear level for writes for the life is around 100,000,000, or (the warranty of 3-5 years for most new SSD) to me that will never exceed the life of the system since it will be replaced long before the 50+ years for the typical expected life of the SSD in a normal operated system. Sure older SSD technology had a shorter life span as compared to modern MLC or SLC based drives with modern SSD controllers. Be sure to compare IOPS for the SSD to get the max I/O.

Life for a modern SSD is not a real concern for me since the newer technology has extended the span if configured properly for a system.

Be sure to use a newer kernel that supports 'TRIM' along with configuring the scheduler for the drive, I prefer [noop] scheduler for the SSD since it is a FIFO and you will not have the latency that a spinning disk will have so the FIFO [noop] will perform better than [deadline] or [cfq]. Just assign [noop] for the SSD not system wide.

Check out this LQ post: #26 for references & links.

HTH!

One could use a type of live cd/dvd/usb install. The way they work is to use a file that contains a compressed image of a fileysystem. Then they attach via fuse or aufs or persistence file the changes. That change area could be memory or another media that is rewriteable or combination.

Any number or ways to use OpenSuse also. Either the live cd's or create a SuseStudio image for your use.

I doubt you have to worry about writes to the ssd. It should outlast your use. It would outlast a usb by a long shot.

Not really answering the question. I upgrade my machines when I need to. For instance this one is running what was intel's greatest but one core duo. I run optical design optimisation software and a number of other heavy processing tasks such as photo processing on it and it's performance is adequate. My main reason for upgrading is ram and the fact that the power supply failed last week so it's a case of what's next. Basically the box is about 10 years old and has odd bits replaced over that period. Graphics and one set scsi discs. The previous set of 3 in raid 5 via PCI-X had been used in an earlier machine. The graphics card was replaced to allow all KDE's desktop effects to be run without them turning themselves off occasionally.

What I have managed to sort out is that these are effectively temp directories

/dev/shm
/run
/sys/fs/cgroup
/var/lock
var/run (which is really just /run)

It seems these may all reside in ram in practice but not sure.

Also that an fstab entry as follows causes the root temp directory to be placed in ram

none /tmp tmpfs defaults 0 0

I suspect I could replace these directory entries in the ssd with links to directories on a hard drive but that wouldn't be very efficient and it would be better to do it directly.

As to the technology the automotive field has been using it for rather a long time and I find the comments in the arch wiki valid. It is possible to buy slc which has a much longer life but it's rather expensive. This touches on why certain flash memory units such as those used in some places on servers are very expensive. The warrantee - we pay for it and ever reducing sized technologies just put more and more on a silicon wafer. The number on it more or less directly relates to the cost of each item.

What I am after is info on linux temp type directories and suggestions on hacks that would allow all of these to be directed to a hard drive if they aren't effectively held in ram.

John
-