I have read the thread, and its point is, beginning from the OP, what are experiences of Slackware users with SSDs, used together with HDDs in the same system. This evolved into the discussion over the lifetime of SSDs. So I still have to ask: What is your point with that post?

Ah, know I see. Your statement:Actually was meant as: Hey, if it crashes it is pretty easy to give it to a professional data recovery company and it will only cost a few hundreds to thousand dollars.

May be there are some other and pretty simple factors that make you system slow with the noop scheduler.
Some things that come to my mind, but I can't say if anything applies to your system:
- a slow SD card controller.
- SD cards are magnitudes slower than SSDs, especially write speed, but also read speed.
- As far as I know, SD cards/controllers don't support the TRIM feature, which can have serious impact on write speed.

I never heard from a SSD user with the same problems that you have with the SD card (which doesn't mean that those problems can't exist), so I would simply assume that the problem is caused by your system.

I want to chime in with my (probably different) point of view, and at the same time give a plug (hope that's OK) for my SourceForge project called "Joe's Boot Disk (JBD)" which you can find at:

http://www.sourceforge.net/projects/joesbootdisk

I'm currently using two SSDs and I have Slackware installed on both of them. Perhaps it was unwise, but I just installed it in the normal way giving no consideration for the type of drive. I don't remember the file system types, but I think I used ext3 or ext4, the same as what I would normally have used.

What I did differently, however, is that the SSDs are each in a Sabrent USB enclosure. I made JBDs (see my SourceForge project) to boot them. The resulting combination has been working well for me. Most people are not familiar with this idea, so I'll say it again more slowly. Slackware (in each) is on the SSD in the USB enclosure. The enclosure connects to the Linux box (or CPU, tower, or whatever you like to call it) with a USB cable. The enclosure is very small as it is hardly bigger than the drive, and it needs no power beyond what USB provides. The Linux boxes are configured to boot first from CDROM. The JBD (a CDROM) does the job of booting Slackware on the SSD automatically when the Linux box is powered on.

I said I have two such SSDs in use. One serves as my firewall and dhcp server (instead of a standard, off-the-shelf router) for my home network. The linux box it plugs into therefore has two network interface cards. It has been in use for about one year. The other SSD serves as an educational computer in the special ed class where I work. The students mostly use seamonkey, ktuberling, and mplayer, and it has been in use for about two years. Both give quick, reliable performance and are a pleasure to use. Also being external to the Linux box I can (and I have) moved them from one Linux box to another with little effort.

In summary, the benefits of an SSD for me are (1) low power requirement, (2) small form factor, (3) speed of operation, and (4) works well with my JBDs. Although I've been conscious of their limitations, I've not treated them any differently from a hard drive.

-Joe

But that was exactly my point to start with. By running this experiment on a setup that is maybe 200 times slower than a typical SSD, and that does *not* have any of the fancy features that alleviate the noop scheduler's shortcomings, you can see clearly in isolation what effect the noop scheduler has. And that effect is not good. I suggest that the noop scheduler can and does cause these problems with typical SSD setups, but people don't care, because it's all happening 200 times faster.

All I wanted to do was to make people question the conventional advice about the noop scheduler and to make people think critically about the noop scheduler itself. Apparently I failed: probably because the conventional advice has become a matter of faith. Alas.

Edit: I'm worried that this thread is starting to look anti-TobiSGD. No! I really admire Tobi's work at LQ, it's outstanding, invaluable and irreplaceable.

I think my point is clear enough from this post: http://www.linuxquestions.org/questi...ml#post4732705
If you still believe "storage reliability = rated lifetime" then I have nothing to say. Please feel free to put your eggs into one basket.

More a matter of experience. But anyways, I never really noticed the differences between the schedulers, so may be you are right, but the differences in performance are so small that you can't notice them even under heaviest load.

I still don't get it. This thread is still about using SSDs in conjunction with HDDs. Also, no one said that using a SSD means that you don't have to do your backups. So please elaborate how using a SSD is putting "your eggs into one basket".

Member Response
 

Hi,

You are still comparing two different storage techniques. Show me the data or information to support your claims. As I said before that a 'SD' controller manages writes & reads differently than a 'SSD' controller. How do you define 'noop' shortcomings? Not just a verbal claim, please support your argument.
Not a matter of faith but fact. You will find gains when using 'noop' for the 'SSD' with general overall system usage. 'deadline' should be used for indexed/overlay usage and bottlenecks of this type. If you as a user are not sure then use the default [cfq] scheduler.

I believe 'TobiSGD' can hold his own. Debates are healthy with good challenging factual points for exchange. Hearsay or FUD have no place when discussing something of the this sort. Opinions are fine but support with details. :)

Personally, I have been reading docs, benchmarks and anything available to make positive choice(s) for the scheduler to use. For one laptop , the 'noop' scheduler for a 'SSD' is the best overall choice. Along with proper configuration setups the 'noop' does provide best fit. This machine uses a 'Patriot' Pyro 'SSD' which does support 'write-back cache'. Another point for performance gains but not all 'SSD' controllers support 'write-back'. Users should dig into 'SSD' manufactures data to insure that maximum performance can be gained by tweaks for their system. Ask the technical support people to define or explain any of your queries/questions.

One other thing: be sure to use relative information, do not mix old 'SSD' configuration techniques with newer 'SSD' since this can be a problem. Newer controllers do provide better control techniques than older versions.

Buyer be-aware!

Don't worry, i don't see it to be this way and even if it would be you can be sure that I can handle that.

Still all modern SSDs and HDDs use NCQ which means they re-order requests at their leasure. Your SD card does not.

How many times do I have to repeat myself?

I see no point in continuing to participate in this thread if people can't remember beyond the last thing they read.

no need to get ratty if we all seem to agree on the point. Btw, in addtition to your guesswork I pointed out proof in my earlier post.