Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.ports.arm > #10870

Re: causes for this?

Show all headers | View raw

On Sunday 24 June 2018 06:15:24 Luke Kenneth Casson Leighton wrote:

> On Sat, Jun 23, 2018 at 4:15 PM, Gene Heskett <gheskett@shentel.net> 
wrote:
> >> So when you first plug in a flash device, only a few megabytes are
> >> actually available for writing, and the controller is busy running
> >> self test routines on the rest. Any writes to the untested parts of
> >> the flash get queued behind the testing so will be quite slow. Most
> >> users would not notice an effect, especially with SD cards in
> >> digital cameras because they are powered all the time and only
> >> filled gradually.
> >
> > Sounds plausible, but you'd think they'd want to test it just to
> > stop the shipment of bad product.
>
>  pffh, naah.  you can't do tests on flash without actually risking
> damaging it.  damage means reduced life.  reduced life means less
> confidence from the customer as its capacity is less than what it's
> supposed to be.  much better to ship out untested product and let
> amazon and other sales front(s) deal with complaints and returns.
>
>  firmware on low-cost (and newly-designed unusual) SSDs is extremely
> dodgy.  one of the drives that i tested literally crawled to an
> absolute stand-still after a certain sustained amount of parallel
> writing (from different processes).  the article went out on slashdot
> and i was given some advice about it: stop the parallel write
> queueing.  there's a linux kernel parameter somewhere for it...  i
> didn't get to try it out unfortunately.
>
>  this was after OCZ had been caught switching on a firmware #define
> which they had been TOLD under no circumstances to enable as it causes
> data corruption (they wanted to be "faster" than the competition).
> the data corruption was so bad it actually in some cases overwrote the
> actual firmware *on the drive*, meaning that the SSD was no longer...
> an SSD.
>
>  the only reasonably-priced SSDs i trust now are the intel s35xx
> series.  other drives such as the toshibas which are also supposed to
> have supercapacitors for "enhanced power loss protection", the
> supercapacitors simply aren't large enough, so a sustained series of
> writes above a certain threshold speed, pull the power and there's not
> enough in the supercapacitors to cover the time it takes to save the
> cached data.
>
>  only the intel s35xx series has had the work put into it,
> technically, to do the job *at a reasonable price*.  i ran a 4-day
> test writing several terabytes of data, the power was randomly pulled
> at between 7 and 25 second intervals, for a total of six and a half
> THOUSAND times, and *not a single byte* was lost.  which is deeply
> impressive.
>
>  the s37xx series is by a different team and they use the fuckwit
> marvel "consumer" chipset that's so troublesome in kingston, crucial
> and other SSDs.
>
>  really not being funny or anything: if you care about your data
> (*and* your wallet) just don't buy anything other than intel s35xx
> series SSDs.  of course if you have over $10k to spend there are
> plenty of data-centre quality SSDs.
>
> l.

I will try to remember that s35xx intel.

Unforch, that search at newegg comes back empty today.

So far, and I've had a couple of 60GB adata or SP ssd's in use here for 
several months with no problems, on sale for about a 44 dollar bill each 
from newegg, figured I'd get my feet wet since with amanda I can do a 
bare metal revert back to spinning rust should it blow up.  So far, so 
good.

The 3rd one I just put on the pi, an SP 60GB thats now 24 bucks, with a 
$10 usb-3<->sata adapter plugged into a usb-2 port on the pi, seems to 
be ok so far.  Yeah, that faint knocking sound is real but my knuckles 
are getting tender. :)

If it dies while building a kernel on it, thats the price we pay for 
experience as I totalled a tiny spinning rust seagate 1T with a usb-3 
cable sticking out of it. Spinning hours maybe 1500 when it signed off, 
$50 bucks from Wallies. Running off the rock64 usb-3 port. Worked very 
well, with speeds in the 350 meg a second region, when it worked.

It does seem to be the direction to get used to.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

Back to linux.debian.ports.arm | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

causes  for this? Gene Heskett <gheskett@shentel.net> - 2018-06-23 15:00 +0200
  Re: causes for this? David Pottage <david@electric-spoon.com> - 2018-06-23 15:30 +0200
    Re: causes for this? Alan Corey <alan01346@gmail.com> - 2018-06-23 15:40 +0200
    Re: causes for this? Gene Heskett <gheskett@shentel.net> - 2018-06-23 17:20 +0200
      Re: causes for this? Diego Roversi <diegor@tiscali.it> - 2018-06-24 10:40 +0200
        Re: causes for this? Gene Heskett <gheskett@shentel.net> - 2018-06-24 15:40 +0200
          Re: causes for this? Alan Corey <alan01346@gmail.com> - 2018-06-24 15:50 +0200
            Re: causes for this? peter green <plugwash@p10link.net> - 2018-06-25 02:10 +0200
              Re: causes for this? Christian Knoke <chrisk@cknoke.de> - 2018-06-25 11:20 +0200
          Re: causes for this? Gene Heskett <gheskett@shentel.net> - 2018-06-24 16:20 +0200
            Re: causes for this? Elena ``of Valhalla'' <valhalla-l@trueelena.org> - 2018-06-25 12:30 +0200
              Re: causes for this? Gene Heskett <gheskett@shentel.net> - 2018-06-25 13:00 +0200
      Re: causes for this? Luke Kenneth Casson Leighton <lkcl@lkcl.net> - 2018-06-24 13:00 +0200
        Re: causes for this? Gene Heskett <gheskett@shentel.net> - 2018-06-24 17:00 +0200
          Re: causes for this? Luke Kenneth Casson Leighton <lkcl@lkcl.net> - 2018-06-25 11:30 +0200
            Re: causes for this? Gene Heskett <gheskett@shentel.net> - 2018-06-25 12:40 +0200

csiph-web