LinuxQuestions.org
Did you know LQ has a Linux Hardware Compatibility List?
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 07-18-2012, 06:31 AM   #31
onebuck
Moderator
 
Registered: Jan 2005
Location: Midwest USA, Central Illinois
Distribution: SlackwareŽ
Posts: 11,293
Blog Entries: 3

Rep: Reputation: 1448Reputation: 1448Reputation: 1448Reputation: 1448Reputation: 1448Reputation: 1448Reputation: 1448Reputation: 1448Reputation: 1448Reputation: 1448
Member Response


Hi,

Personal & professional preferences are what dictate hardware specifications for me. I still use mechanical hard drives but find the use of a 'SSD' enhances my hardware experience.

As to the life comparisons for a 'SSD' & 'HDD'. My base hardware will reach the end of life before a failure of either device. Too limit use of a 'SSD' because of 'FUD' is just plain silly. Go ahead and design your system around the device you wish to use. I will use my 'SSD' along with cheap large storage 'HDD' to provide a good workable machine.

Today's 'SSD' controller design along with the use of 'MLC' will insure a good experience over time for consumer grade drives. After a few years(2-4) then I will will be moving up to another platform with newer technology after a few years of positive experience.
 
Click here to see the post LQ members have rated as the most helpful post in this thread.
Old 07-18-2012, 07:27 AM   #32
solarfields
Member
 
Registered: Feb 2006
Location: Outer Shpongolia
Distribution: Slackware
Posts: 478

Rep: Reputation: 122Reputation: 122
i have a SSD...
read the section about SSD in the Arch linux wiki and in the end got a bit pissed that i have to do so many tweaks and that i had to read so much in order to just use the damn thing... eventually what i did was:

- use AHCI mode from the BIOS (don't even remember anymore why)
- use gdisk to partition the disk as GPT (so partitions are aligned properly, whatever this means)
- use EXT4 to format the partitions (because some options had to be passed in fstab, see below)
- use the following options for e.g. the root partition in fstab (don't remember what they are for either):

/dev/sda1 / ext4 defaults,noatime,discard 0 1

I do not know if everything I did was right, may be I screw up something... I have mounted /tmp/SBo into RAM, something that I always do.

yes, i know i should've mounted /home, /var and /tmp on a separate "conventional" hard disk, but since i don't have any, i just use these partitions on the SSD. And to be honest: I DON'T CARE!

Sure it is fast, but not as fast as I imagined from reading some reviews. No magic, only /usr/bin is displayed in Thunar within a second and it takes a fraction of a second to start Seamonkey. But the CPU is AMD Phenom Black (4 cores) so i suppose it would've been fast even with a HDD. There is something weird though: when LILO boots Slackware, it is very slow when the "Loading Linux.................................................. ......." completes. After that the boot is very fast (~15 sec or less with the generic kernel)

Last edited by solarfields; 07-18-2012 at 07:31 AM.
 
Old 07-18-2012, 07:45 AM   #33
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,592
Blog Entries: 2

Rep: Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047
A Slackware user that is pissed by reading documentation? That is rather rare, I would think.

- AHCI should be activated for any modern disk, regardless if it is a SSD or not.
- You can align partitions with fdisk
- ext4/btrfs are recommended for SSDs because the support TRIM, an important thing for SSDs

Seems that you have done anything right.

I am using SSDs since 2010, I never had any problems. the SMART status of my oldest SSD (Intel X25-V 40GB) reports 0% wearout.
I recommend SSDs to anyone. You have fear of loosing data because of wear-out? Make a backup! I am doing that since the time I lost data when a 6 months old mechanical disk died.
 
2 members found this post helpful.
Old 07-18-2012, 07:56 AM   #34
55020
Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 390
Blog Entries: 4

Rep: Reputation: 372Reputation: 372Reputation: 372Reputation: 372
As an additional data point, I'm using a Raspberry Pi, which is a tiny development board with a slow ARM CPU that uses an SD card as its storage medium -- i.e. a *very* slow SSD.

I tried the conventional advice to use the 'noop' scheduler. What a DISASTER! Any background load, such as compiling, would kill interactive response for minutes at a time.

The 'noop' and 'deadline' schedulers are equivalent if and only if your SSD performance is so fast, and utilisation is so low, that there is no queueing. But in any situation where your SSD is a bottleneck -- in other words, whenever actual scheduling is actually needed -- 'deadline' or 'cfq' will maintain responsiveness and 'noop' will be epic fail.

'noop' is the scheduler of choice only for workloads that are so utterly trivial that they don't ever need a scheduler. I'm guessing that, in practice, the 'noop' advocates are being saved from themselves by cleverness in their SSD controllers.
 
Old 07-18-2012, 08:15 AM   #35
solarfields
Member
 
Registered: Feb 2006
Location: Outer Shpongolia
Distribution: Slackware
Posts: 478

Rep: Reputation: 122Reputation: 122
Quote:
A Slackware user that is pissed by reading documentation? That is rather rare, I would think.
but I did read it

Quote:
Seems that you have done anything right.
Thanks! I feel much better now

Last edited by solarfields; 07-18-2012 at 08:20 AM.
 
Old 07-18-2012, 06:35 PM   #36
Cheesesteak
Member
 
Registered: Jun 2008
Distribution: Slackware
Posts: 101

Rep: Reputation: 24
Quote:
Originally Posted by guanx View Post

Originally Posted by Cheesesteak
Don't buy a hard drive. They are electro-mechanical, and the mechanical parts wear out. If the mechanical parts don't get you, faulty firmware will. They're doomed to fail. C'mon...

The red text alone is a perfect description of SSD.
I'd agree about the firmware. That's why you should research before you buy.

I'm just trying to illustrate the larger point that people seem to refuse to take a second look at a technology because it may have been rougher around the edges a few years earlier. They dwell on the negatives of old and come to expect that they were be there for eternity.
 
Old 07-19-2012, 04:54 AM   #37
guanx
Senior Member
 
Registered: Dec 2008
Posts: 1,014

Rep: Reputation: 146Reputation: 146
Quote:
Originally Posted by Cheesesteak View Post
...
I'm just trying to illustrate the larger point that people seem to refuse to take a second look at a technology because it may have been rougher around the edges a few years earlier. They dwell on the negatives of old and come to expect that they were be there for eternity.
This comes to my second point, which you did not quote.
 
Old 07-19-2012, 05:02 AM   #38
TL_CLD
Member
 
Registered: Sep 2006
Posts: 342

Rep: Reputation: 34
Quote:
Originally Posted by solarfields View Post
There is something weird though: when LILO boots Slackware, it is very slow when the "Loading Linux.................................................. ......." completes. After that the boot is very fast (~15 sec or less with the generic kernel)

Add the "compact" option to /etc/lilo.conf, run lilo and enjoy!
 
Old 07-19-2012, 05:22 AM   #39
TL_CLD
Member
 
Registered: Sep 2006
Posts: 342

Rep: Reputation: 34
I've got two Intel SSD's in my workstation:

The / SSD:
Device Model: INTEL SSDSA2M080G2GC
Serial Number: CVPO0120057J080BGN
Firmware Version: 2CV102HD
User Capacity: 80,026,361,856 bytes

The /home SSD:
Device Model: INTEL SSDSA2CW300G3
Serial Number: CVPR112601L4300EGN
Firmware Version: 4PC10302
User Capacity: 300,069,052,416 bytes

The / SSD has been online for 8561 hours and the /home SSD for 6388 hours.

I use my system quite heavily, with lots of compilation, a boatload of git commit/push/pull and lots of copying to and from network drives. This is not a box that is idling 90% of the day.

Currently the smartctl "233 Media_Wearout_Indicator" reports 99, for both SSD's.

Quote:
This attribute reports the number of cycles the NAND media has experienced. The normalized value declines linearly from 100 to 1 as the average erase cycle count increases from 0 to the maximum rated cycles. Once the normalized value reaches 1, the number will not decrease, although it is likely that significant additional wear can be put on the device.
I personally do not worry about the drives wearing out.

I use EXT4 with the discard option added to fstab. I can honestly say that buying those two SSD's have made a tremendous difference in my computing experience. They are A LOT faster than even the fastest HDD's. Probably one of the best hardware buys I've ever done.
 
Old 07-19-2012, 06:45 AM   #40
onebuck
Moderator
 
Registered: Jan 2005
Location: Midwest USA, Central Illinois
Distribution: SlackwareŽ
Posts: 11,293
Blog Entries: 3

Rep: Reputation: 1448Reputation: 1448Reputation: 1448Reputation: 1448Reputation: 1448Reputation: 1448Reputation: 1448Reputation: 1448Reputation: 1448Reputation: 1448
Member Response

Hi,

Quote:
Originally Posted by guanx View Post
<snip>
With the money for an Intel 320 Series SSD of 160 GB, I can buy four 7200 rpm HDDs of 500 GB each, three as backups. How can the latter be less reliable for normal usage?
Less reliable? This really depends on the usage, configuration and user abilities. I look at the gains provided by the purchase and use of the 'Intel 320 Series SSD of 160 GB' over the time frame. My gains will surpass with the use of a 'SSD' as compared to a 'HDD'. I use the 'HDD' to enhance my 'SSD' experience. 'HDD" are good secondary storage devices since the cost per GB is lower for a 'HDD' then a 'SSD'. With a properly configured system the 'SSD' will provide gains far above a 'HDD'. By using a 'HDD' as secondary storage I can have a system that will provide the means to work at better performance with a 'SSD' and provide enough storage for everything else on a 'HDD'. As to the 'normal' usage part, I think the use of a 'SSD' has become normal for me.

I have experienced 'HDD' failure and that is no walk in the park. For me the 'MTBF' for a 'SSD' surpass the life time of my general hardware. I do replace the system long before a failure will occur for a properly configured system with a 'SSD'. Currently replacing a Laptop that will be used for a 2-3 year time frame. 'SSD' will be a Patriot drive around 160GB-250GB with secondary USB 3.0 'HDD' at 500GB. Still shopping for the 'SSD' but think I will stick with a 'MLC' based unit for cost reasons. My laptop choices are narrowing and a new selection to be made soon.
 
Old 07-19-2012, 07:09 AM   #41
onebuck
Moderator
 
Registered: Jan 2005
Location: Midwest USA, Central Illinois
Distribution: SlackwareŽ
Posts: 11,293
Blog Entries: 3

Rep: Reputation: 1448Reputation: 1448Reputation: 1448Reputation: 1448Reputation: 1448Reputation: 1448Reputation: 1448Reputation: 1448Reputation: 1448Reputation: 1448
Member Response

Hi,
Quote:
Originally Posted by 55020 View Post
As an additional data point, I'm using a Raspberry Pi, which is a tiny development board with a slow ARM CPU that uses an SD card as its storage medium -- i.e. a *very* slow SSD.
'SD' controller and 'SSD' controllers are different thus the write/read will be handled different.
Quote:
Originally Posted by 55020 View Post
I tried the conventional advice to use the 'noop' scheduler. What a DISASTER! Any background load, such as compiling, would kill interactive response for minutes at a time.
Your system may not have been configured properly.

Quote:
Originally Posted by 55020 View Post
The 'noop' and 'deadline' schedulers are equivalent if and only if your SSD performance is so fast, and utilisation is so low, that there is no queueing. But in any situation where your SSD is a bottleneck -- in other words, whenever actual scheduling is actually needed -- 'deadline' or 'cfq' will maintain responsiveness and 'noop' will be epic fail.
'noop' and 'deadline' a totally different schedulers. 'noop' is a 'FIFO' and will provide better scheduling for a properly configured system 'SSD'. Some 'SSD' provide better cache methods that must be configured.

'deadline' does provide good scheduling for 'SSD' that could be used for DB management with potential overlay issues.
I would like to to see the data to support your statements for 'noop' and 'deadline'. If you make a system wide scheduler change then I can see some issues with the mix of 'SSD' & 'HDD' scheduling. If the system is configured for independent scheduler for each device then the data/benchmarks state otherwise.
Quote:
Originally Posted by 55020 View Post
'noop' is the scheduler of choice only for workloads that are so utterly trivial that they don't ever need a scheduler. I'm guessing that, in practice, the 'noop' advocates are being saved from themselves by cleverness in their SSD controllers.
Care to show me where you get this from. Seems to be a broad paint brush statement.
 
Old 07-19-2012, 07:36 AM   #42
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,592
Blog Entries: 2

Rep: Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047
Quote:
Originally Posted by 55020 View Post
I tried the conventional advice to use the 'noop' scheduler. What a DISASTER! Any background load, such as compiling, would kill interactive response for minutes at a time.
Posting this while playing a Youtube video and compiling a kernel with -j10 on my Corsair Force 3 120GB, noop scheduler, just to test this. No, I can't see any sluggishness. Something must be wrong with your system configuration.
 
Old 07-19-2012, 08:40 AM   #43
guanx
Senior Member
 
Registered: Dec 2008
Posts: 1,014

Rep: Reputation: 146Reputation: 146
Quote:
Originally Posted by onebuck View Post
...
I have experienced 'HDD' failure and that is no walk in the park. For me the 'MTBF' for a 'SSD' surpass the life time of my general hardware. ...
With the same money for your tiny SSD I can buy a bunch of large HDDs, putting some of them in the U.S., some in Russia, some in China, some in Iran, ... and I can be sure that my data will not be lost as long as the world exists

Furthermore, it is super easy to recover data from a failed HDD.
 
Old 07-19-2012, 08:58 AM   #44
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,592
Blog Entries: 2

Rep: Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047
Quote:
Originally Posted by guanx View Post
With the same money for your tiny SSD I can buy a bunch of large HDDs, putting some of them in the U.S., some in Russia, some in China, some in Iran, ... and I can be sure that my data will not be lost as long as the world exists
SSDs are made to put work on it, they can handle that really fast. They are not made to store large chunks of data (at least not now). So what is your point?

Quote:
Furthermore, it is super easy to recover data from a failed HDD.
Sure, let me see how you recover data from a HDD with headcrash. By the way, recovering data is for people that are either to lazy or to ignorant to make proper backups.
 
Old 07-19-2012, 02:21 PM   #45
Martinus2u
Member
 
Registered: Apr 2010
Distribution: Slackware
Posts: 345

Rep: Reputation: 56
Quote:
Originally Posted by TobiSGD View Post
Posting this while playing a Youtube video and compiling a kernel with -j10 on my Corsair Force 3 120GB, noop scheduler, just to test this. No, I can't see any sluggishness. Something must be wrong with your system configuration.
or something works different for SD cards which was the previous poster's configuration. I also use NOOP for my SSDs and it r0x0r5.

Btw, there are benchmarks done by the BFQ people (BFQ is a superior I/O scheduler for *rotational* disks) showing that for disks with NCQ (native command queueing) the I/O scheduler strategy matters less, to the point of NOOP being competitive with BFQ!

http://algo.ing.unimo.it/people/paol...mark-suite.php

and finally my ceterum censeo: people wanting the ultimate interactivity should not forget the CPU scheduler and look into BFS.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
SSD MystKid Linux - Hardware 1 04-05-2011 10:23 AM
SSD hydraMax Linux - Hardware 4 01-09-2011 12:09 PM
ssd slack66 Slackware 5 06-24-2010 12:56 AM
ssd and Slackware hemp4fuel Slackware 5 02-26-2010 11:21 AM
Slackware 12.2 on PATA SSD - Cant use as SATA? Hangdog42 Slackware - Installation 11 02-02-2009 02:42 PM


All times are GMT -5. The time now is 10:53 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration