http://www.kogan.com/au/buy/kogan-256gb-6gbs-solid-state-drive/ Kogan is selling a 256G SATA flash storage device with Intel flash (IE flash that shouldn't lose your data) for $139. Flash storage will make your system a lot faster. Boot time will be improved a lot, particularly if you use systemd and have a multi-core CPU (in which case CPU won't be a bottleneck and most of the boot time will be disk IO). The time taken to login to a GUI environment will be a lot faster too, last time I timed it a flash device halved the time from entering a password in KDM to having KDE ready to use. Flash storage also makes your system a lot quieter, you might not realise the noise from a constantly spinning hard drive until it goes away. If you have $139 to spend on an upgrade to a desktop system then this is probably the best option. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
mmmmmmmmmmmmmmmmmmmmmmmm I don't know if I'd choose Kogan for something as important as the primary drive in my computer. There's more to reliability than just using Intel NAND chips internally. a) I'm sure Intel separate out the good, average and bad chips and then sell them at different price points (or keep the best for themselves at least). b) This will be some no-name Chinese flash manufacturer's product rebadged as Kogan, just like everything else they sell, and you know it'll be built to a price. A low price. c) No details given on what chipset it uses apart from "JMicron".. Some of those have been awful, some acceptable. And finally -- the price isn't even that good! Why pay $140 for an unproven Kogan drive, when you can get a *proven* decent drive like the Crucial MX100 256GB for $110? http://www.amazon.com/Crucial-MX100-adapter-Internal-CT256MX100SSD1/dp/B00KF... -Toby On 22 July 2014 14:06, Russell Coker <russell@coker.com.au> wrote:
http://www.kogan.com/au/buy/kogan-256gb-6gbs-solid-state-drive/
Kogan is selling a 256G SATA flash storage device with Intel flash (IE flash that shouldn't lose your data) for $139.
Flash storage will make your system a lot faster. Boot time will be improved a lot, particularly if you use systemd and have a multi-core CPU (in which case CPU won't be a bottleneck and most of the boot time will be disk IO). The time taken to login to a GUI environment will be a lot faster too, last time I timed it a flash device halved the time from entering a password in KDM to having KDE ready to use.
Flash storage also makes your system a lot quieter, you might not realise the noise from a constantly spinning hard drive until it goes away.
If you have $139 to spend on an upgrade to a desktop system then this is probably the best option.
-- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
-- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world
Toby Corkindale <toby@dryft.net> wrote:
And finally -- the price isn't even that good! Why pay $140 for an unproven Kogan drive, when you can get a *proven* decent drive like the Crucial MX100 256GB for $110? http://www.amazon.com/Crucial-MX100-adapter-Internal-CT256MX100SSD1/dp/B00KF...
That's an excellent price for a 256GB SSD. We can expect prices and capacity to improve further in coming years. Does Linux still require edits to /etc/fstab to support Trim and other SSD optimizations, or is it all done by default now? A further development of note is the move to SSDs attached directly to the PCI-Express bus, with no drive controller required. Example: http://www.ramcity.com.au/blog/all-about-pcie-ssds-part-1-windows-linux/1313... (still expensive, but this should change.)
On 23 July 2014 11:20, Jason White <jason@jasonjgw.net> wrote:
Toby Corkindale <toby@dryft.net> wrote:
And finally -- the price isn't even that good! Why pay $140 for an unproven Kogan drive, when you can get a *proven* decent drive like the Crucial MX100 256GB for $110? http://www.amazon.com/Crucial-MX100-adapter-Internal-CT256MX100SSD1/dp/B00KF...
That's an excellent price for a 256GB SSD. We can expect prices and capacity to improve further in coming years.
Does Linux still require edits to /etc/fstab to support Trim and other SSD optimizations, or is it all done by default now?
I think most tools are smart enough to do things right for SSDs (mainly, block-aligning) now, but TRIM still tends to need you to fiddle with stuff to enable. I think this is because on older SSDs, TRIM (aka discard) was a performance problem, so you really only wanted to run it once at 4am rather than every time you touched a block on your device. But newer SSDs fixed that issue, but because only some support it, the choice is left up to the user. (With the default seeming to be "don't do it at all" unfortunately) T
On Wed, 23 Jul 2014 12:58:08 PM Toby Corkindale wrote:
I think most tools are smart enough to do things right for SSDs (mainly, block-aligning) now, but TRIM still tends to need you to fiddle with stuff to enable. I think this is because on older SSDs, TRIM (aka discard) was a performance problem, so you really only wanted to run it once at 4am rather than every time you touched a block on your device.
Pre SATA 3.1 the TRIM command was non-queued, which means the kernel had to wait for all I/O to complete before it could issue the TRIM command and couldn't send any other commands until it completed. Bad protocol design. http://lwn.net/Articles/347511/ Which didn't help the fact that many SSDs took/take a long time to TRIM. This was fixed in SATA-3.1 which introduced an NCQ/DSM (queued) TRIM command.
But newer SSDs fixed that issue, but because only some support it, the choice is left up to the user. (With the default seeming to be "don't do it at all" unfortunately)
There has been an attempt to detect and enable it for certain devices but for instance Crucial and Micron have problems with crappy SSD firmware (FTL) leading to data corruption. :-( It was meant to be fixed in a firmware update (MU05), but sadly trusting the vendor and whitelisting it resulted in more people getting data corruption, including trashed partition tables. Bugzilla entry of their pain: https://bugzilla.kernel.org/show_bug.cgi?id=71371 I don't know if they've gotten around to fixing it yet. :-( cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
Chris Samuel <chris@csamuel.org> wrote:
Pre SATA 3.1 the TRIM command was non-queued, which means the kernel had to wait for all I/O to complete before it could issue the TRIM command and couldn't send any other commands until it completed. Bad protocol design.
http://lwn.net/Articles/347511/
Which didn't help the fact that many SSDs took/take a long time to TRIM.
This was fixed in SATA-3.1 which introduced an NCQ/DSM (queued) TRIM command.
How is the protocol handled by SSDs that attach directly to a PCI-Express interface rather than to a SATA controller? Does Linux support these yet?
On 24 July 2014 10:14, Jason White <jason@jasonjgw.net> wrote:
Chris Samuel <chris@csamuel.org> wrote:
Pre SATA 3.1 the TRIM command was non-queued, which means the kernel had to wait for all I/O to complete before it could issue the TRIM command and couldn't send any other commands until it completed. Bad protocol design.
http://lwn.net/Articles/347511/
Which didn't help the fact that many SSDs took/take a long time to TRIM.
This was fixed in SATA-3.1 which introduced an NCQ/DSM (queued) TRIM command.
How is the protocol handled by SSDs that attach directly to a PCI-Express interface rather than to a SATA controller? Does Linux support these yet?
Well, they are going to attach via the old SATA connectors still, but the new controllers will use "SATA Express", which is just the PCI Express bus going over SATA cables. The new protocol for accessing the disks is "NVM Express": Linux appears to have had support since kernel 3.3: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9... However the wikipedia article mentions that 3.13 saw major performance alterations come in with 3.13. Refs: https://en.wikipedia.org/wiki/SATA_Express https://en.wikipedia.org/wiki/NVM_Express
Toby Corkindale <toby@dryft.net> writes:
However the wikipedia article mentions that 3.13 saw major performance alterations come in with 3.13. https://en.wikipedia.org/wiki/SATA_Express https://en.wikipedia.org/wiki/NVM_Express
KN is my reference of choice for a user-friendly NEWS file for linux releases: http://kernelnewbies.org/Linux_3.13#head-3e5f0c2bcebc98efd197e3036dd814eadd6...
Trent W. Buck <trentbuck@gmail.com> wrote:
KN is my reference of choice for a user-friendly NEWS file for linux releases:
Mine too.
http://kernelnewbies.org/Linux_3.13#head-3e5f0c2bcebc98efd197e3036dd814eadd6...
Quoting the above: "Note: in this release, only the virtioblk driver has been ported to this interface, other drivers will be ported in next releases."
Chris Samuel <chris@csamuel.org> writes:
There has been an attempt to detect and enable it for certain devices but for instance Crucial and Micron have problems with crappy SSD firmware (FTL) leading to data corruption. :-(
It was meant to be fixed in a firmware update (MU05), but sadly trusting the vendor and whitelisting it resulted in more people getting data corruption, including trashed partition tables.
Is anyone working on an open firmware for FTLs yet?
On 23/07/14 11:20, Jason White wrote:
That's an excellent price for a 256GB SSD. We can expect prices and capacity to improve further in coming years.
I read somewhere recently (sorry I forget where) that price parity with rotating disks could come in around 5-10 years.
A further development of note is the move to SSDs attached directly to the PCI-Express bus, with no drive controller required. Example: http://www.ramcity.com.au/blog/all-about-pcie-ssds-part-1-windows-linux/1313... (still expensive, but this should change.)
Those don't look very hot swappable, but I there are some PCI-E drives available that are.
On Wed, 23 Jul 2014 11:20:02 Jason White wrote:
Toby Corkindale <toby@dryft.net> wrote:
And finally -- the price isn't even that good! Why pay $140 for an unproven Kogan drive, when you can get a *proven* decent drive like the Crucial MX100 256GB for $110? http://www.amazon.com/Crucial-MX100-adapter-Internal-CT256MX100SSD1/dp/B00 KFAGCWK That's an excellent price for a 256GB SSD. We can expect prices and capacity to improve further in coming years.
Does Linux still require edits to /etc/fstab to support Trim and other SSD optimizations, or is it all done by default now?
Yes, but trim is often undesirable. When I had it enabled with BTRFS performance suffered significantly. It will be a long time before that's a feature that can be enabled by default.
A further development of note is the move to SSDs attached directly to the PCI-Express bus, with no drive controller required. Example: http://www.ramcity.com.au/blog/all-about-pcie-ssds-part-1-windows-linux/1313 71 (still expensive, but this should change.)
The Intel SSDs I have can't sustain 300MB/s and when under significant load (EG swapping) they give even less performance. A SSD that could sustain 300MB/s under all conditions would be a significant improvement over all storage I've used. On Wed, 23 Jul 2014 13:13:57 Andrew Spiers wrote:
I read somewhere recently (sorry I forget where) that price parity with rotating disks could come in around 5-10 years.
They already have for storage capacities of 60G or less. If you want a workstation for typical business use (IE email, wordprocessing, etc) then 60G should be adequate storage. Even for 120G of storage the cost of SSD isn't much greater than that of hard drives (~$75 vs ~$55). But for most people the price difference isn't the difference in replacement cost but the fact that hard drives ship with most machines, so the price difference is $0 vs $55. For most people on this list when adding an extra storage device to a machine it's a matter of using one of the spare disks that we have on the shelf vs buying a SSD. Effective price parity will happen when more systems ship with SSD by default. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On 23 July 2014 13:56, Russell Coker <russell@coker.com.au> wrote:
On Wed, 23 Jul 2014 11:20:02 Jason White wrote:
Does Linux still require edits to /etc/fstab to support Trim and other SSD optimizations, or is it all done by default now?
Yes, but trim is often undesirable. When I had it enabled with BTRFS performance suffered significantly. It will be a long time before that's a feature that can be enabled by default.
I think you mean: TRIM is always desirable, because your drives slow down over time without it -- you just don't want to be taking the TRIM penalty on every write to the disk, so batch it up for later. Stick a call to fstrim in /etc/cron.daily or similar.. http://man7.org/linux/man-pages/man8/fstrim.8.html
participants (6)
-
Andrew Spiers -
Chris Samuel -
Jason White -
Russell Coker -
Toby Corkindale -
trentbuck＠gmail.com