22 Jul
2014
22 Jul
'14
2:06 p.m.
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/
22 Jul
22 Jul
2:18 p.m.
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/B00K…
-Toby
On 22 July 2014 14:06, Russell Coker <russell(a)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(a)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
23 Jul
23 Jul
11:20 a.m.
Toby Corkindale <toby(a)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/B00K…
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/131…
(still expensive, but this should change.)
12:58 p.m.
On 23 July 2014 11:20, Jason White <jason(a)jasonjgw.net> wrote:
Toby Corkindale <toby(a)dryft.net> 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. 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
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/B00K…
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? 
8:51 p.m.
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
24 Jul
24 Jul
10:14 a.m.
Chris Samuel <chris(a)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?
10:49 a.m.
On 24 July 2014 10:14, Jason White <jason(a)jasonjgw.net> wrote:
Chris Samuel <chris(a)csamuel.org> wrote:
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=…
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
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? 
4:25 p.m.
Toby Corkindale <toby(a)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-3e5f0c2bcebc98efd197e3036dd814eadd…
4:36 p.m.
Trent W. Buck <trentbuck(a)gmail.com> wrote:
KN is my reference of choice for a user-friendly NEWS
file for linux releases:
Mine too.
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."
11:07 a.m.
Chris Samuel <chris(a)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?
23 Jul
23 Jul
1:13 p.m.
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/131…
(still expensive, but this should change.)
Those don't look very hot swappable, but I there are some PCI-E drives
available that are.
1:56 p.m.
On Wed, 23 Jul 2014 11:20:02 Jason White wrote:
Toby Corkindale <toby(a)dryft.net> wrote:
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.
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? 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/
2:51 p.m.
On 23 July 2014 13:56, Russell Coker <russell(a)coker.com.au> wrote:
On Wed, 23 Jul 2014 11:20:02 Jason White wrote:
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
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.
3170
days inactive
3172
days old
12 comments
6 participants
participants (6)
-
Andrew Spiers -
Chris Samuel -
Jason White -
Russell Coker -
Toby Corkindale -
trentbuck＠gmail.com