Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


EeePC (2, Interesting)

lukrop (1302325) | more than 5 years ago | (#24350149)

I'm interested how useful this could be for my EeePC since it only uses SSDs. let's see

Re:EeePC (1)

lukrop (1302325) | more than 5 years ago | (#24350171)

Ahhh solid state drives... :O damn, i should go to bed... But i like those tiny drives for backing up data. Thanks for the guide anyway

First! (0)

Anonymous Coward | more than 5 years ago | (#24350155)

Thanks to SSD performance tweaks.

SSD (3, Interesting)

jrwr00 (1035020) | more than 5 years ago | (#24350167)

SSD Drives are nice and all, but a Major MYSQL DB would eat a flash disk alive, all those writes, even if the drive supports 10 billion writes, for a big mysql DB, it could eat that in a year, You will still need a shit ton of ram cache for the main DB so all the minor writes dont kill the disk, there is the fact of data loss in the power loss... all writes stored in memory will be lost... HDs are slow yes, but SSD is just not there just yet

Re:SSD (1)

antifoidulus (807088) | more than 5 years ago | (#24350277)

Depends on the DB. For instance if you are running a DB that has lots of reads but very few(comparatively) writes, such as an online store(where you only update your catalog when you have new prices/stuff to sell, but tons of people look at it). But in those types of DBs you would probably be better of using lots of cache....

indices (1)

TheSHAD0W (258774) | more than 5 years ago | (#24353109)

Does MySQL allow one to store the indices in a separate file/drive from the rest of the database entries? That would speed things up significantly without needing a large SSD drive.

Re:SSD (0)

Anonymous Coward | more than 5 years ago | (#24359423)

SSD Drives are nice and all, but a Major MYSQL DB would eat a flash disk alive, all those writes, even if the drive supports 10 billion writes, for a big mysql DB, it could eat that in a year, You will still need a shit ton of ram cache for the main DB so all the minor writes dont kill the disk, there is the fact of data loss in the power loss... all writes stored in memory will be lost... HDs are slow yes, but SSD is just not there just yet

Hehe. There are not enough seconds in a year to actually perform that amount of writes to a single flash disk. If you need that kind of bandwidth you're looking at an array of drives and if you have that replacing disks is routine maintenance anyway.

Large block size is a problem though. That may require redesigning the engine or even giving up the d from acid if you want serious performance.

Don't assume things (2, Insightful)

jgoemat (565882) | more than 5 years ago | (#24360433)

Do the math. Most flash media are good for at least 100,000 writes. They also use wearing algorithms so that each block averages out to about the same. Even if you try to write to a certain block over and over, the algorithms take over and move blocks that are not written very often to those locations, so blocks end up being written to about the same.

With that in mind, let's take the 64 gb model for $899 as an example. Let's say you have a huge workload and are writing at the max [crucial.com] of 35MB/sec. At 100,000 writes, 64GB gives you 6.4e15 bytes that can be written before the disk wears out. At 3.5e7 bytes per second, that comes to 1.83e8 seconds. There are 3.16e7 seconds in a year.

That means that at THE MAX write rate and only 100,000 write cycles (not 10 billion), the drive should last at least 5.8 years. Unless you are simply writing to a logging database, you won't be using anywhere near the max write speed and the drive should last decades.

ehh (0)

Anonymous Coward | more than 5 years ago | (#24350175)

personally, i prefer tweaking on meth.

Converted my garage PC to a SSD-alike (3, Interesting)

karnal (22275) | more than 5 years ago | (#24350265)

I've just purchased a 4gb transcend 300x card (udma5) and an addonics IDE to CF adapter. This article comes along at a great time, since scouring the net for information on "flash linux" usually results in some article regarding USB installations, which are about 2x (or more, depending on drive used) slower than this solution.

The only thing that this PC runs is minor browsing when looking up a car repair, or Amarok (with a MySQL backend.) Regarding the mysql backend, it doesn't seem like there will be enough action on the disk to even begin to worry about the flash failing.

In addition, the transcend I purchased (and most high end == costly) is an SLC device, which I've read is faster as well as can sustain more writes over the lifetime of the drive. I see this as worthwhile in a system such as this, as I want it to be an "install and forget" type of system. Using a spinning platter in the variable humidity and temperature conditions just doesn't seem to make sense - especially when most of the media used would be in a server in my basement.

I'm also looking into network booting; however the PC that I've slated for use in the garage would probably require a bootable floppy/cd since it's old enough to not be bootable from an installed NIC. Maybe I just need to add a newer NIC - but I've not spent a lot of time researching that.

If anyone has other articles I could enhance my knowledge with - and possibly doing something similar to my setup - I'd love to read them.

Re:Converted my garage PC to a SSD-alike (0)

Anonymous Coward | more than 5 years ago | (#24350875)

Have you looked into etherboot? http://etherboot.org

Re:Converted my garage PC to a SSD-alike (1)

WindBourne (631190) | more than 5 years ago | (#24354185)

Did the same to my main house server more than a year ago. My regular disk drives sleep, while the CF handle the bulk of the regular load. I have noticed that the system is MUCH cooler and quieter. In fact, for my shuttle shoebox system, I am about to take out the 80G HDD and put in a 32G CF and figure that it will not only be faster, but also cheaper on electricity and quieter (the fan HUMS when I am using it; that HDD adds heat).

Wait, what? (4, Insightful)

Briareos (21163) | more than 5 years ago | (#24350279)

He recommends disabling journalling and using RAID instead?

So exactly how will a RAID make sure the filesystem metadata is still intact when I yank out the power cable for fun and no profit, as opposed to using a filesystem with a journal?

Sheesh... that's just begging for an accident to happen.

np: Yello - You Gotta Say Yes To Another Excess (Orb Goes The Weasel Mix) (Auntie Aubrey's Excursions Beyond The Call Of Duty (Disc 2))

Re:Wait, what? (3, Insightful)

Florian Weimer (88405) | more than 5 years ago | (#24350685)

He also recommends to turn on write-back caching. I'm not really sure if this is save. The cache on the SSD is probably not battery-backed.

Re:Wait, what? (4, Insightful)

schon (31600) | more than 5 years ago | (#24351189)

He also says that the 'noatime' mount option tells the kernel not to read the atime... noatime tells the kernel not to write atimes to the fs.

sweet jebus, is there *anything* technically correct in that article?

Re:Wait, what? (1)

El_Isma (979791) | more than 5 years ago | (#24362617)

> sweet jebus, is there *anything* technically correct in that article?

Yes, of course, the title. The "On Linux" part.

Re:Wait, what? (0)

Anonymous Coward | more than 5 years ago | (#24359055)

Yeah, he picked performance over reliability and justified it by saying that SSDs are more reliable than hard disks. Journaling has nothing to do with the reliability of the device. It's needed because of crashes do to power, kernel, hardware failure, etc.

Partitioning (4, Insightful)

mickwd (196449) | more than 5 years ago | (#24350289)

I'm surprised I've heard very little about using Unix/Linux partitioning to get the best out of SSDs.

Seems to me that the best use of an SSD on a normal system is to buy a smallish one (say 16GB) and use it for the read-mainly partitions: say /usr, /opt, maybe /lib.

It would be good to get users' "dot" files in there too. Maybe create a /homedot on the SSD and symlink /home/myname/.example to /homedot/myname/.example.

Even if this doesn't make your applications run much faster, the faster read and seek times are going to make the machine boot faster, load applications faster (especially including the desktop environments, if user directories like .kde and .gnome are on SSD) and compile code faster (with /usr/include, etc on SSD).

Re:Partitioning (1)

Xtravar (725372) | more than 5 years ago | (#24350721)

Not to mention, partitioning is a good idea for any disk. It prevents fragmentation and data loss (if one partition gets corrupted). Also, it makes reinstalling an OS easier and booting faster. Well, if you partition correctly...

Partitioning: One reason why I don't use Windows anymore. Linux handles it much better.

Re:Partitioning (2, Informative)

imroy (755) | more than 5 years ago | (#24351227)

...partitioning is a good idea for any disk. It prevents fragmentation...

How do you figure that? Modern Unix filesystems actively avoid fragmentation by being careful about allocating blocks to files. With more free space, a filesystem has more options as to where to place a new file. It's better to have one big filesystem with 10G free, than four or five with only about 2-3G free each.

Re:Partitioning (1)

Xtravar (725372) | more than 5 years ago | (#24359789)

Not only fragmentation of files, but fragmentation of related files.

Let's say I'm installing Firefox to /usr/lib.

I don't want Firefox's files spread out across my entire physical disk and intersperced with /tmp /var /etc, because then Firefox will load slower as the hard drive must spin more to load related files.

Yes, I know that isn't a concern with SSDs, but it is a concern with standard hard disks.

No file system is smart enough to read your mind and know how your data is going to be used. Only you can optimize for that.

Re:Partitioning (1)

angrykeyboarder (791722) | more than 5 years ago | (#24352689)

Partitioning is more trouble than it's worth. I've found myself with full partitions on too many occasions over the years.

It's not always easy to be smart about it. One can't always anticipate their future needs.

The only partitioning that makes any sense at all is that which is used in Linux with LVM (at least as far as a home user is concerned). If I'm running Linux and not using LVM I have just one partition mounted on "/".

Just the other day I decided to marge the two partitions I have on one of my drives (Windows - NTFS) into one because having them partitioned became more trouble than it wasworth (and this is on a 500GB drive).

The best solution when it comes to potential data loss is to make regular and frequent backups.

Re:Partitioning (1)

Henkc (991475) | more than 5 years ago | (#24365725)

Couldn't agree more about partitions. I've run out of space on /usr /opt /var etc several times over the last decade on various systems. There is just no foolproof way to predict the future. I also don't use LVM - it's just another layer of indirection adding complication if your FS becomes corrupted. I've had too many problems with LVM: and no, not from power outages or resets.

Re:Partitioning (2, Insightful)

Siffy (929793) | more than 5 years ago | (#24354471)

Fragmentation is of little concern with SSDs. The time needed to read out of order bits on a rotating media is much higher as we know, but reading bits out of order in memory or on SSD is almost identical to reading the bit beside it due to the low seek times. Also, partitioning schemes that try to keep the most often accessed files at the beginning of the media lose their edge for the same reason. A SSD has the same performance characteristics from the beginning to the end of the drive from 1% to 99% used capacity. Partitioning could actually shorten the lifespan of the drive, because it could prevent the wear-leveling algorithms from doing their job properly. You'd likely have the most often written to partition fail much sooner than the rest of the drive.

Re:Partitioning (0)

Anonymous Coward | more than 5 years ago | (#24360241)

If the wear-levelling algorithm is decent, it will wear-level across the whole drive totally ignorant of your partitions and filesystems. As it should.

Re:Partitioning (1)

DarkOx (621550) | more than 5 years ago | (#24351021)

I don't think that would work very well. Symlinks are stored in most file systems as "special" files. You would have to seek read the read the link. Since dot files are usually pretty small ie would fit in one block or a few consequtive blocks, any time at all spent accessing the SSD will be a loss, because you will have done all the expensive part of the operation on the traditional disk. Now its possible some filesystems that keep more data about a link in their internal structures would end up having that info cached but you would have research all that pretty carefully.

Mentions only storing mission critical data on SSD (1)

antifoidulus (807088) | more than 5 years ago | (#24350359)

s but the article then advocates some dangerous behavior. Write back cache only works if you don't think you will have a power failure, and as we saw on /. previously, that can be real disaster. He also advocates forgoing journaling in favor of RAIDs, but again that can be dangerous if your machine somehow gets into a weird state. Not sure I would trust mission critical data without Journaling or Write-through unless that data was backed up somewhere else.

Re:Mentions only storing mission critical data on (1)

Cato (8296) | more than 5 years ago | (#24364579)

If you have a power failure during a write to an SSD, you are very dependent on the FTL (Flash Translation Layer) between the FS and the device: if it does its job properly it can recover from this, detecting blocks that are invalid because they were partially written. If not, the whole device can be unrecoverable... This is one reason why using an SSD in a laptop (i.e. with battery) or a server with UPS is a good idea.

Having looked at the very long lifetimes of most flash devices (see http://www.storagesearch.com/ssdmyths-endurance.html [storagesearch.com]) I would only use ext2 instead of ext3 if performance was critical and I had good backups on another system. The main issue with ext3 is likely to be performance.

1 more tip for them (1)

Siffy (929793) | more than 5 years ago | (#24354509)

Buy a drive intelligently. Maybe they should check out these drives. http://www.newegg.com/Product/Product.aspx?Item=N82E16820227344 [newegg.com] http://www.hothardware.com/News/OCZ_Core_Series_SSD_Vs_VelociRaptor_Sneak_Peek/ [hothardware.com] The 32GB version that would be suitable for a linux boot drive is going to have a $140-160 price point I believe. I'm considering a 64GB for my Vista laptop to reduce the heat it generates.
Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account