Is Kingston knowingly crappy?

dunno but I got a kingston SSD for me laptop that failed inside a year

I think there are some issues with some of its technology

--
The lifetime of any political organisation is about three years before  
its been subverted by the people it tried to warn you about. 

Anon.

I seem to have the opposite experience. Most of my SD cards (from 8Mb to

32Gb) are years old. My thumb drives the same, I have one that has been on my keychain for 6years, getting knocked about, wet, hot, cold, casing has come off and taped back... no issues.

Wouldn't buy any other.

NoReply

--
Don't be afraid of the deep...      __BBS__ 
 >>> bbs.bottomlessabyss.net|https|telnet=2023|ssh=2222

Did you write these processes yourself or are they from a package? The reason for asking is that, if they are your code, consider reversing the logging logic and only reporting problems to the log, rather than what sound like endless 'I'm OK' messages. Apart from reducing wear on the SD card, it will make the logs a lot easier to read.

I used to use Kingston years ago, stopped when I found out that they are only a rebrander, i.e. that their SD cards no long come from a single, known foundry.

I now use Sandisk, because they make their own product, for everything: cameras, RPi as well as the flight logger, navigation PNA and FLARM system in my glider. The latter two are safety-critical systems.

I'm not quoting usage figures for my RPi because its run time is just an hour or two per week.

The only problem I have with it, an early 512MB Model B, is that if I leave it idle for an hour or two after booting it appears to be dead when I try to log in to it over SSH. However, if I log in and out as soon as it has come up after booting then its still responsive a couple of hours later.

Obvious question: is the PC running Linux? If not, then it will only be able to read the boot partition.

--
Martin    | martin at 
Gregorie  | gregorie dot org

You could try to:

- create ssh keys to auto-login and

- create crontab entry to ssh test@local-raspberrypi every 1/4 hour or so, without doing anything useful, just to keep it alive.

Then look if this solves the freezing problem.

Best regards,

Markus

--
Please reply to group only. 
For private email please use http://www.dipl-ing-kessler.de/email.htm

The code is selfmade.

And, yes, also successful pings are reported. So, there are 3 things that can happen: online, offline, neither / error.

As far as I've learned about SSHDs, SSD cards, USB memory sticks is, that the built-in memory controller takes care of never writing the same memory cells over and over -- and risk early defects.

Instead the formerly used cells are marked as erased / to be re-used, and the new, modified content of the file will be written to a different location. So, all cells are stressed equally.

This seems not to be the case here.

OK, that makes things clearer...

See second branch

Yes, it's Linux, and after installing there are 2 partitions offered for mounting.

But after the crash / failure, when I clicked on the "root fs" partition, there only popped up an error alert saying that this partition cannot be mounted. Same symptoms seen when the first Kingston crashed.

And, after running a fsck / e2fsck now, there is no such partition any more. I can access the whole partition like 'cat /dev/sdc2 | xxd | less', but I only see the first 64 MB. The remaining space seems unavailable. Aaaargh...

Best regards,

Markus

--
Please reply to group only. 
For private email please use http://www.dipl-ing-kessler.de/email.htm

It doesn't always happen - just sometimes, and as the RPi is only left idle like this as part of my weekly backup+upgrade session on all my systems, its not annoying enough to do anything about it: I just switch on the RPi, boot a laptop that's sitting alongside it and login to the RPi from the laptop when both are up.

--
Martin    | martin at 
Gregorie  | gregorie dot org

Just checking. Personally I'd remove the success reports because generally they're not as interesting as errors but ymmv.

Yes, wear levelling is a standard feature of all solid state memory, but the resilience and sophistication of its process seems to vary with the cost of the device. What it does is to remap the relationship between physical blocks and block IDs so that heavily used blocks, such as those containing the free sector list on a FAT device, get their content swapped with lower usage blocks.

One known way to wreck any SS memory device is to turn it off or unplug it during wear levelling because this is very likely to leave the memory in an unusable state. Its impossible to tell when the wear levelling process is being run, so its never a good idea to yank a device out of a camera/PDA/phone/computer/whatever or to simply pull the plug on anything, such as an RPi, that uses solid state memory.

Always use close/eject before removing solid state memory from whatever uses it or, if it doesn't offer this feature, do a proper shutdown and powering it off before removing the memory device.

My guess is that you were unlucky and turned it off during wear levelling.

Sometimes reformatting the device will fully recover it, sometimes not. That depends on exactly what the wear leveller was doing when it all went dark: if it was in the middle of remapping the blocks holding device size or partition data then its quite possible that a reformat will fail. When it comes to SD cards it may be useful to be know that:

- they are cheap and probably have unsophisticated, fault intolerant wear levelling processes built into them, i.e pulling an SD card out of a powered-on device without safely unmounting and ejecting it may corrupt the card.

- apparently some really cheap SD cards may not use wear levelling at all.

- SD card memory lifetime is about 100,000 write cycles, so heavy rewriting reduces their life. A write every 5 secs is 242,000 writes in two weeks, but in the worst case if we guess 10 bytes/msg and 512byte logical blocks, and 4K memory pages in the SD card the OS would think that was 4726 block writes, and this would reduce to 590 physical page writes on the card assuming it internally buffers all writes.

- an 8GB card has 2 million 4K physical blocks, so even if each OS block write forces a physical SD card write, no single physical block should see more than 8 writes in two weeks.

- there are different grades of SD card. Grade 10 are meant for sequential streaming in video cameras and may not perform well when used as random access filing systems.

--
Martin    | martin at 
Gregorie  | gregorie dot org

On 06/01/2019 10:23, Markus Robert Kessler wrote: [Snip Kingston cards fail after two weeks]

Are they genuine Kingston cards? There are so many fakes these days.

I personally only use Samsung and occasionally SanDisk flash products, as they manufacture their own flash memory, rather than stick a badge on whatever is cheapest this week.

If you are reading and writing 24/7, the most reliable storage medium is a proper SSD via a USB to SATA cable. They designed for use as computer hard disc (rather than offline file storage), have great random read/write performance, and far greater endurance than anything else. It will probably last as long as you are using the Pi.

The next best thing, especially if physical space is an issue, is a USB pen drive. A full size one, not a low profile one as these get tremendously hot. I recommend the Samsung USB 3.1 bar drives, as they are small enough not to obscure other ports, and metal cased for heat dissipation. They have tremendous performance on a USB 3 PC, but are also far quicker than USB2 drives on the Pi. Importantly the 4K read/write speeds are far greater than any SD card. You will get at least 3 to 4 years of use out of them.

In last place is the SD card, where even the best Samsung class 4 or 6 cards barely acceptable random read/write performance, and many others are truly abysmal drastically slowing down the Pi. I've only ever got a year of intensive use out of them before they start failing.

Samsung have introduced an endurance range of SD cards, aimed at uses like the Pi, but given they are about twice as expensive as normal cards, and cost more than an equivalent sized USB 3.1 stick, I've not tried them in any of my full size Pi's. I might consider one when I refresh the cards in the Pi Zero's, as SD cards are the only real option in them.

---druck

This is a myth, mostly. There are wild brand and type variations but generally, faster in one way also means faster in the other. There's one thing you can depend on: you just don't know until you buy one and test it :/

The most reliable guarantee nowadays is an A2 rating. Not cheap.

On Sun, 6 Jan 2019 14:43:15 -0000 (UTC), Markus Robert Kessler wrote in :

Are you sure they are genuine Kingston cards, from a reputable source? From what I hear this is the classic symptom of fake solid-state devices which contain far less than advertised (and reported by the modified controller) and only that small fraction can indeed be written to. See, for example,

--
                  Ivan Reid (ivan.reid@[brunel.ac.uk|cern.ch]) 
Engineering, Design & Physical Sciences                CMS Collaboration, 
Brunel University London. Room TOWD405                 CERN, Room 40-1-B12 
        KotPT -- "for stupidity above and beyond the call of duty".

On Sun, 6 Jan 2019 10:23:19 -0000 (UTC), Markus Robert Kessler declaimed the following:

Kingston does not manufacture SD cards -- they buy up blank units from lowest bidder makers and put their label on them. I believe PNY is similar.

Don't recall if Transcend is a maker or relabeler, but have a small feeling that if they do relabeling, they may still be using higher quality cards.

SanDisk (and Lexar to my knowledge) have their own silicon foundries, and would be a recommended choice. I did have a Kingston card for my first RPi -- and managed to kill it when running a benchmark suite (it did not survive having a section allocated to a swap file -- eventually had to run the benchmark with a TB USB drive for swap).

Note that SD cards are natively formatted in FAT -- a NON-JOURNALING file system. Linux EXT# (and NTFS) are journaling systems. Journaling systems are supposed to reduce the effects of corruption as they keep a journal of changes being made, and at later/idle periods finalize the changes. Power-failure in mid-update means either the update is completely lost (no change to original file), the journal is lost (so all updated data is lost, but no changes to original file), the journal and update were not lost, and can be used to finalize the actual file... But journals are "bad" for flash memory due to the amount of activity performed.

Also, cheaper memory cards may only maintain two "open allocation units" (one data file, one file allocation table), and a journaling system can easily be using three or more open AUs (data file, journal, and equivalent of FAT). On a two AU card, changing from AU to AU means flushing updates to an AU, locating a free AU in the card, ERASING that AU (SD cards can only write once to a sector without erasing), COPYING static parts of an old AU to the newly erased one, then appending new/modified data to the AU.

Note that lower quality class 10 cards may perform very badly with file systems that are not streaming data. Class 10 cards are rated for writing a video stream to a freshly formatted card (so 2 AUs are all that is needed). Class 2/4/6 cards, OTOH, are rated for writing small (photos, for example) files to a fragmented card (reflecting someone who has deleted some photos between shoots) -- they can often beat the performance of a cheap class 10 when lots of small files are being accessed.

CF:

(a bit old now, but the concepts are the same -- look at the # open AUs columns; in a quick glance, Kingston manages just 1 AU, SanDisk 3-6, and Transcend 5)

Also:

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

card-8/

I had 2 identical "Kingston 8GB Class4" cards. Sure they were cheap :-)

And, today's crash may be the result of a power loss, or, caused by overload due to those constant write cycles. Well. Maybe.

But, the first of those two cards was in a RPi running alone and touched or plugged out by no one. It was peacefully running more than hundred miles away from me. It just shot some photos taken from a USB camera and ssh-ed them to a webserver. And from one hour to the next the machine crashed and the connection was gone. First I thought, the RPi crashed and due to that the SD card was overloaded with write cycles and died. But after what I've seen today, I doubt it and rather assume that the card died and hence the OS crashed.

Really weird what happened with those "Kingston" cards...

Best regards,

Markus

--
Please reply to group only. 
For private email please use http://www.dipl-ing-kessler.de/email.htm

I have a Kingston stick formatted as NTFS. I use it for sneakernet between Windows systems, writing a couple of gigs each time. It's quite slow compared to FAT32-formatted sticks, but preserves time stamps to the second, which is important enough to me that I put up with it. I've been using the stick for several years with no problems. I typically format it before copying a new batch of data to it.

Not only am I careful to properly unmount the stick before removing it, I wait until its light stops flashing. This can be as much as 30 seconds after the system says it's safe to remove the stick - but Windows is famous for lying.

--
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs) 
\ /  I'm really at ac.dekanfrus if you read it the right way. 
 X   Top-posted messages will probably be ignored.  See RFC1855. 
/ \  Fight low-contrast text in web pages!  http://contrastrebellion.com

I bought a thumb drive at the time when 4 GB was as much as you could buy. It lived on my car key ring so it gets all sorts of abuse, and I use it for downloaded installation exe files, so files get updated as often as new releases of packages are released. It still works perfectly. I've no idea what brand it is: if there ever was any maker's mark on it, its long ago worn off.

That sort of usage is probably equivalent to a day or two being used as the main storage of a Raspberry Pi.

---druck

That is the type of use which the cards are designed for. It is magnitudes less harmful than the constant writing of small amounts data which occurs when using them as main storage on a Pi.

---druck

As someone else mentioned, there are loads of fakes around too, although if you're going to the trouble to make a fake, you would probably make a fake of a better quality product.

Journals and fsck are designed to handle failures of hard drives. Failures of cheap flash (a.k.a. SD cards and USB thumb drives) are different in nature, and neither a journal nor fsck are going to be able to help. The typical catastropic failure is when the card fails to save the logical to physical mapping table back to the flash. This has the effect of shuffling a large number of blocks on the disk, many of which were written ages ago. Some flash devices will go dead at this point, others will just serve up wrong blocks all over the place. That's not something journals nor fsck can recover. (I did let fsck try once - it just got the drive into a hopeless mess.)

Enterprise flash products go to some length to avoid this catastrophic failure mode.

--
Andrew Gabriel 
[email address is not usable -- followup in the newsgroup]

Sure you're right, but what should we use as main storage on a PI instead? Any more robust technique available, fitting in the SD slot?

B.t.w., how can a PI be shutdown without automatically starting up again? You need to know when to power it off to prevent data loss or completely damaging the SD card. If you do a "shutdown -h now" or "init 0" or even a "halt", then your PI will do the shutdown, but will immediately restart again.

Best regards,

Markus

--

Please reply to group only. 
For private email please use http://www.dipl-ing-kessler.de/email.htm

No it doesn't, or at least it shouldn't. I have certainly never seen that behaviour.