SD Card reliability debate ...

[kaspencer]

Greetings all ...

I would like to ask as many people as possible what their experience (and if you are expert, your opinion too) regarding the reliability of SD Cards. I have four Raspberies Pi - two are 256M models and two are more recent 512M models. I received my first two back in June of 2012.

There were many reports of difficulties with SD Cards during the first 6-8 months of availability of the machines. There was advice issued regarding the use of Class 10 cards, and of the suitability of Micro SD Cards too. Like many people, I experienced some difficulty but the problems abated as changes were made in the boot loader, and in other parts of the system.

First, I will say that I do not overclock the machines that I wish to use for real-world applications.

My longest serving machine is the one onto which I immediately set about putting my music and some video to run under RaspXBMC. Basically I was trying to replace a 450watt PC with a 4watt Raspberry Pi!
By about July or August, I had a 128Gbyte SD Card (Class 10) practically full. During the work setting all that up I had used a 64Gbyte (Class 10) card, but had noted that inexplicably it would fail and become corrupt during occasional data loading over my LAN. However, my 128 Gbyte SD Card seems to have functioned for over six months of uptime, having been on 24hours every day. Possibly I can give a thumbs up for the 128Gbyte card and a thumbs down for the 64Gbyte card.

The next project was to set up a Raspberry Pi as a webserver as a replacement for my Windows Server 2003 R2 webserver, mainly to save on the 450watt consumed by that PC. I had that running on a 32Gbyte Class 10 Micro SD Card by the end of November. From that time until last weekend (16th February 2013), it served over XX Gbyte of data, which included video and audio in over XX,000 hits, that is, in about three months of uptime.

However, at around midnight on 16th it seems that the SD Card suffered a major problem and became very seriously corrupt. After several attempts to reflash the card and reinstall the software, data and scripts, I had to abandon that SD Card. It had to be regarded as having failed because, whilst it might be successfully reflashed, it soon failed again during the reinstallation of software or reloading of the website data. The 32Gbyte SD Card that has replaced it is a Class 6 card, and I am hoping that it may prove more reliable. Time will tell.

My third machine has been commissioned as a Primary Domain Controller and File Server to replace most of the remaining functions of my Windows Server 2003 R2 PC. The functions not covered are Exchange Server 2003, SQL Server 2005, and ASP.NET2. I have currently sacrificed the former and the latter, but have replaced SQL Server 2005 by MySQL 5.5 with some limitations. Data storage is now on a Seagate 2Terabyte USB disc drive, via NTFS-3G and Samba version 3.
I was able to turn off the Windows Server two and a half weeks ago. However, it was not straight forward because after a week the SD Card (64Gbyte, Class 10) became spontaneously corrupt during an overnight data backup and remote webstatistics log file retrieval. Reconfiguring and reinstalling on the same card seems to have succeeded, at least for the time being.

So, as you'll see if you have managed to read this far, I am asking those who have commissioned a Raspberry Pi for real-world applications, especially requiring long periods of uptime, to feed back their SD Card issues, with comments, advice and suspicions. This will help all of us to understand the hazards of committing such developments onto this platform.

Many thanks for reading - I really will look forward to contributions.

Regards

Kenneth Spencer

[LetHopeItsSnowing]

I run 3 Pi's and I have had my fair share of SD card reliability issues.... However every one that has failed, has been a cheap unbranded one which I got from the local supermarket. My first Pi is probably the most heavily loaded, running an iplayer downloader and podcast host, including the webserver to make all that work and that has been running on the same 8gb class 4 sandisk ultra card 24 hours a day since June.

In the end I brought similar sandisk ultra cards for my other 2 pi's which again have shown the same level of reliability.

[obcd]

I am not an expert, but I am frquently experiencing Murphys law and even the law of Johnson.
(Johnson said Murphy was optimistic in his thinking..)
First of all, a 450W pc isn't consuming 450W. It's something between 60W - 100W under normal operating conditions. Replacing the harddisk with a SSD can reduce that even more. You will never reach the Pi 3-5W consumption, but comparing a pc with it is like comparing a Ferrari with a Toyota. The first one will conbsume more fuel. The second one will also bring you from A to B, but it's another experience.
Linux has 2 things dan't don't cooperate very well with sd technology.
Those are swap and loggings.
SD cards have a limited number of erase/write cycles per page. swap and loggings frequently write to the card. Other flash technology has the same limitation.
For that reason, wear levelling algoritms are used to create an equal number of writes to every flash page. (for instance on SSD disks.)
The question is, does a sd card also has wear levelling buildin? If we use it in our camera, we take 1000 pictures during our vacation, and we erase those after we transferred them to our pc. If we use it in our mediaplayer, we fill it with 500 (legaly downloaded) music tracks and stick it in our player. We might additionally put a couple of video's on it, but again, it's not like we frequently write erase the thing.

[obcd]

If we use it for linux, the situation is different. Enough to wear out the flash technology? Very hard to tell.
Another known issue is the fact that flash chips need to be erased on page boundaries. Therefore, the controller of the sd card copies erased sectors untill it has a page full of them to erase. This whole thing happens in the background. Some brands of sd cards can get corrupted data if the power is removed in the middle of such an operation. Apparantly, the background task is only running if you write to the sd card. Why there is also no solid prove of that (as the way it works is factory secret of the sd card manufactures), it makes logically sense. As long as you don't erase a sector of the card, it's controller has nothing to move to the page it's preparing for erasure.
I noticed you speak about 64GB and 128GB sd cards. Aren't those SDXC instead of SDHC? I can't remember the spec's out of my head, but is the Pi capable of working which such?
The whole point of this writing is to create a little understanding what technical problems you are facing when you use an sd card as linux disk.
There are ways to get rid of those problems, but you have to sacrisfy some comfort for it.
You can create the loggings on a tmpfs folder on a ramdisk. If the system reboots, the loggings are gone. For a user who doesn't care about the underlying os on his toy, this dosn't matter much.
You can compile a kerel with swapping disabled. As long as you know perfectly what will run on the system, and as long as you know it all fits into available memory, this doesn't has to be a problem either.
You can mount the linux rootfs read only. Some stuff like SMB and DHCP don''t like this very much as they expect some files to be read write. You can copy those to the tmpfs in ram, but it's not a beginners setup. It's also a problem if you have an application that needs a place to save it's settings.
You can also install another drive for that like an usb stick. Such a setup fixes the read only rootfs issues without the loose of comfort.

[kaspencer]

Thanks for the replies ...

First, OB.. thanks for the detailed comments of SD Card behaviour - maybe someone will offer further advice on the real significance of the fact that it does seem that all SD Cards have a limited life as a storage medium for an OS in a computing device.
My 64Gbyte and 128Gbyte cards are both SDXC, Class 10. The 64Gbyte is Transcend, and the 128Gbyte is Kingston. All the indication is that the Kingston is highly stable in the Raspberry Pi, although as you observed, the data in a Media Centre (and all my music and video is legally owned by myself), is relatively static. As I observed, the 64Gbyte Transcend is somewhat less stable, but is in a situation where there is quite a lot of data change occurring both in overnight selective backups of data on the 2TB drive and in retrieval of webstatistic logs from the remote hosts of my three business websites hosted in the LINX.
Regarding the PC server power comment, I'd say that your expectation of 50-100W is as optimistic as my 450W might have been pessimistic. I didn't actually divulge the processor in the Windows Server 2003 R2 machine, but I will say that the CPU alone can consume up to 95W. On top of that are two large capacity fixed disc drives, which would cost me a great deal of money to replace in SSD - thus only exchanging one cost for another. Power consumption averaged over a 1 month period did indicate a figure nearer mine than yours.

I am looking forward to more!

Thanks alot,

Ken.

[kaspencer]

Just a quick addendum to my initial post for this thread, as I don't seem to be able to any editing ...

The activity data on the Raspberry Pi webserver is:
"From that time (last week of November) until last weekend (16th February 2013), it served over 5.3 Gbyte of data, which included video and audio in over 71,600 hits, that is, in about three months of uptime."

Kenneth Spencer

[thradtke]

No problems thus far. I'm using class 4 cards only as they're cheap and only get used to boot the firmware (or systems that don't use the card as extensively as Linux). That said, I never had much luck with flash memory. Cannot count the number of USB keys that went bad, while my old 6GB 1in ARCDisk is still in good shape since 2005 .

[SN]

I have a SANDisk Ultra Class 6 4Gb card in my webserver Pi

Its run non-stop for 110 days, every 5 seconds it pulls a still image off a web cam, writes a timestamp onto it using imagemagick and then moves it to a location that apache2 can read and serve

According to my numbers that's about 133Gb written (in nearly 6 million writes) to the SD card without issue.

This is without any O/S write operations or Apache logging for serving pages/images.

And it ran a similar config for about 40 days prior to that on its last run - so I would say, if you get a good card, a Pi will run and run...

[ab1jx]

Old thread, I know. I've had 2 Pi 3Bs and a Zero for a year or so. I use Sandisk class 10 128 and 64 GB cards. The Pis have been running 24/7, I finally put the Zero to work running a Litecoin ASIC rig. Mostly I use them for programming and graphics.

Now I get the

Code: Select all

/dev/sda2: recovering journal
Superblock needs_recovery flag is clear, but journal has data.
Run journal anyway<y>? no
Clear journal<y>? no
e2fsck: unable to set superblock flags on /dev/sda2
/dev/sda2: ********** WARNING: Filesystem still has errors **********

First of all I feel boxed in. I know there are spare superblocks, most of which are probably OK, that I could be using. It's not clear to me what the above is going to attempt. I miss Norton Disk Editor that would let you change a single bit in a partition if you needed to. This problem showed up as suddenly a read-only file system.

panic2c.gif (48.51 KiB) Viewed 6030 times

But it's clear to me that trying to use SD cards in a server scenario isn't going to be very reliable. In theory they're supposed to last 10 years. I think I have a few USB memory stick that died at about that age. But I'm seeing early failures that have me worried. On a hunch, higher density is less reliable, my latest USB stick is only 8 GB. I tend to be swapped out a lot too, that doesn't help.

So, I'm thinking: Get a dedicated USB hub just for storage. Get about 4 USB card readers (I have an IoGear one I trust). Put in about 4 SD cards with the best reputation. Set up the partitions in a RAID 5 array https://en.wikipedia.org/wiki/Standard_ ... els#RAID_5. The cards don't have to be identical, you just have to be able to make partitions of identical size. Keep a cloned copy of your boot SD. Wish I'd thought of it when I could afford it better. The cards seem to reliably fail in warranty so if you're willing to jump through hoops you can get them replaced.

[apudapus]

I'm a former SSD firmware engineer that worked on the flash translation layer for SATA drives. The NAND flash used in solid-state memory has limited program/erase cycles and requires good block management. I've provided some excerpts from NAND flash specifications to show what SSD makers have to manage and to give insight into making your memory cards last.

From a Micron NAND flash spec (from Micron's website, easily found on Google):

Over time, some memory locations may fail to program or erase properly. In order to ensure that data is stored properly over the life of the Flash device, certain precautions must be taken, such as:
• Always check status after a WRITE, ERASE, or DATA MOVE operation.
• Use some type of error detection and correction algorithm to recover from single-bit errors.
• Use a bad-block replacement algorithm.

From a Toshiba NAND flash spec:

Data Retention
The data in memory may change after a certain amount of storage time. This is due to charge loss or charge gain. After block erasure and reprogramming, the block may become usable again.
Here is the combined characteristics image of Write/Erase Endurance and Data Retention
<see attached>

Read Disturb
A Read Operation may disturb the data in memory. The data may change due to charge gain. Usually, bit errors occur on other pages in the block, not the page being read. After a large number of read cycles (between block erases), a tiny charge may build up and can cause a cell to be soft programmed to another state. After block erasure and reprogramming, the block may become usable again

Toshiba's graph of data retention is unfortunately unmarked but the point is that with more program/erase (P/E cycles on your drive the less time data can sit without getting errors. Older generations of flash could sit for years at even maximum P/E cycles but with TLC and QLC that has gone down to months. I worked on firmware that refreshed these areas before data got too "stale" but you're battling minimizing P/E cycles with bit errors (nowadays it's likely better to experience multiple correctable bit errors than to preemptively lose a P/E cycle). Since SD cards are limited with capacity (flash), memory (RAM), and processing (CPU) all by its small size, they won't be able to do some of these management operations as efficiently/frequently as larger SSDs.

Tips:
* don't use more than 80% of capacity - this reduces garbage collection and prolongs the life of the device
* don't average more than 0.1 drive writes per day (DWPD) - if you have a 256GB SD card, don't average more than 25.6GB writes per day
* refresh the entire card once a year - backup the entire card to another one, use the newly written copy
* use the more reputable brands because they put more effort into their firmware and testing
* ALWAYS backup your "can't lose" data on redundant storage (>=RAID1 or manually copying to multiple devices)

[ab1jx]

Hmm, would there be any point in having software tools for Linux that specifically test/exercise/troubleshoot SD cards? Seems like people in the business probably have stuff we don't. They aren't actually hard drives but about all we have is fsck. Seems like just going through all the files and re-writing each one to a different location on the SD periodically might help. With hard drives too actually. I have heard of people using an SD card until they get errors, then just reformatting it, but I've been skeptical of that. Actually I do have a Sandisk Ultra here that was loaded with Christmas music and in a Kindle Fire until the Kindle stopped recognizing it after a year or so. I reloaded it with other stuff and I've been using it in a reader as a memory stick for a month or so, seems fine like that.

All my Sandisk High Endurance cards are still running, in fact no SD card problems in a year.

[hommar]

don't use more than 80% of capacity - this reduces garbage collection and prolongs the life of the device

if use SD card with A1 or A2 classes, then add parameter "discard" for ext4 or f2fs in fstab
else controller think you use 100% of capacity.

PS because true A1/A2 cards support blkdiscard

[ab1jx]

Well, well, just in time to make bad press. I bought 1 Transcend 400 128 GB card for $65 just under a year ago because Sandisk doesn't make a 128 GB High Endurance, at least not then. The review I read about using High Endurance cards gave them a glowing review. Well, it's being flaky .

It's in a Pi in the basement that I use in the summer but keep running so I can fetch stuff off from it occasionally over wifi. Couldn't ping it, next time I was down there I repowered it. Still couldn't ping it, so I turned on its monitor to see a screen full of error messages. Pulled the SD out and brought it upstairs to fsck in a reader. Multiple passes of fsck are still finding exactly the same errors, it isn't fixing them. So I cloned this 128 GB card onto it thinking maybe rewriting it would help. Ran fsck some more, still kept finding errors that won't go away. Now I'm trying

mke2fs -c -c /dev/sdb2

because if you use -c twice it does a write/read test (see the mke2fs man page). Which takes hours on a 128 GB card over USB 2 at least.

The link to apply for a warranty RMA at Transcend is https://rma.transcend-info.com/us/enduser/Item2 to save time. But I bought 1 of their cards and it failed in under a year, I have at least half a dozen Sandisk cards and a couple failed a year or so ago. They replaced them with new cards in factory blister packs. Just goes to show you I guess that you can't tell much about long term reliability from some review, you need to actually run a few.

My latest fsck run (the third since I cloned onto it)

Code: Select all

fsck from util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-2017)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Entry '.' in ??? (4459184) is duplicate '.' entry.
Fix? yes

Entry '..' in ??? (4459184) is a link to '.'  Clear? yes

Problem in HTREE directory inode 4459184: block #4 has bad max hash
Invalid HTREE directory inode 4459184 (/usr/share/doc).  Clear HTree index? yes

Pass 3: Checking directory connectivity
Unconnected directory inode 4461703 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4461730 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4461920 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4461984 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4462423 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4464472 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4464669 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4464732 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4464817 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4465001 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4465286 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4465317 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4465911 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4465915 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4466014 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4466107 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4466386 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4466450 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4466538 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4466540 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4587589 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4587834 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4587929 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4588215 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4588246 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4588270 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4588936 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4588947 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4589005 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4589395 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4589427 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4589523 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4589688 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4589863 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4589982 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4590585 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4590719 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4590738 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4591420 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4591496 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4718801 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4719099 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4719131 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4719145 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4719231 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4719307 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4719435 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4719478 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4719798 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4719895 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4719916 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4719968 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4720548 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4724083 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4725053 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4850201 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4850205 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4850289 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4853593 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4867580 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4867899 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4876657 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4878535 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4878585 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 4878638 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5002609 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5003103 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5003218 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5003375 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5003422 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5003503 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5005062 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5005177 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5005410 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5005536 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5005568 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5005817 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5005831 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5005859 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5006285 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5006389 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5006686 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5007048 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5111809 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5111869 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5111909 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5114173 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5116740 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5119127 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5119153 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5119204 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5119537 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5119596 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5119814 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5120238 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5120371 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5120375 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5120413 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5120813 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5120898 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5121086 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5121179 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5242881 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5243701 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5243742 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5243770 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5243815 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5244094 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5244394 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5244454 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5244731 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5244739 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5244823 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5244914 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5244945 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5245096 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5245223 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5245441 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5245460 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5245472 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5245601 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5246511 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5249202 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5253327 (/usr/share/doc/???)
Connect to /lost+found? yes

No room in lost+found directory.  Expand? yes

Unconnected directory inode 5374020 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5374387 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5374984 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5375025 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5376133 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5377519 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5377830 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5378159 (/usr/share/doc/???)
Connect to /lost+found? yes

Unconnected directory inode 5378916 (/usr/share/doc/???)
Connect to /lost+found? yes

Pass 3A: Optimizing directories
Duplicate entry 'README.Debian' in /usr/share/doc (4459184) found.  Clear? yes

Duplicate entry 'copyright' in /usr/share/doc (4459184) found.  Clear? yes

Duplicate entry 'changelog.Debian.gz' in /usr/share/doc (4459184) found.  Clear? yes

Duplicate entry 'README.Bugs' in /usr/share/doc (4459184) found.  Clear? yes

Pass 4: Checking reference counts
Unattached inode 4460399
Connect to /lost+found? yes

Inode 4460399 ref count is 2, should be 1.  Fix? yes

Unattached inode 4460402
Connect to /lost+found? yes

Inode 4460402 ref count is 2, should be 1.  Fix? yes

Unattached inode 4460403
Connect to /lost+found? yes

Inode 4460403 ref count is 2, should be 1.  Fix? yes

Unattached inode 4460414
Connect to /lost+found? yes

Inode 4460414 ref count is 2, should be 1.  Fix? yes

Unattached inode 4460427
Connect to /lost+found? yes

Inode 4460427 ref count is 2, should be 1.  Fix? yes

Unattached inode 4460446
Connect to /lost+found? yes

Inode 4460446 ref count is 2, should be 1.  Fix? yes

Inode 4461703 ref count is 3, should be 2.  Fix? yes

Inode 4461730 ref count is 3, should be 2.  Fix? yes

Inode 4461920 ref count is 3, should be 2.  Fix? yes

Inode 4461984 ref count is 3, should be 2.  Fix? yes

Inode 4462423 ref count is 3, should be 2.  Fix? yes

Inode 4464472 ref count is 3, should be 2.  Fix? yes

Inode 4464669 ref count is 3, should be 2.  Fix? yes

Inode 4464710 ref count is 1, should be 2.  Fix? yes

Inode 4464711 ref count is 1, should be 2.  Fix? yes

Inode 4464712 ref count is 1, should be 2.  Fix? yes

Inode 4464713 ref count is 1, should be 2.  Fix? yes

Inode 4464732 ref count is 3, should be 2.  Fix? yes

Inode 4464817 ref count is 3, should be 2.  Fix? yes

Inode 4465001 ref count is 3, should be 2.  Fix? yes

Inode 4465286 ref count is 7, should be 6.  Fix? yes

Inode 4465317 ref count is 3, should be 2.  Fix? yes

Inode 4465911 ref count is 3, should be 2.  Fix? yes

Inode 4465915 ref count is 3, should be 2.  Fix? yes

Inode 4466014 ref count is 3, should be 2.  Fix? yes

Inode 4466107 ref count is 3, should be 2.  Fix? yes

Inode 4466386 ref count is 3, should be 2.  Fix? yes

Inode 4466450 ref count is 3, should be 2.  Fix? yes

Inode 4466538 ref count is 3, should be 2.  Fix? yes

Inode 4466540 ref count is 3, should be 2.  Fix? yes

Inode 4587589 ref count is 3, should be 2.  Fix? yes

Inode 4587834 ref count is 3, should be 2.  Fix? yes

Inode 4587929 ref count is 3, should be 2.  Fix? yes

Inode 4588215 ref count is 3, should be 2.  Fix? yes

Inode 4588246 ref count is 3, should be 2.  Fix? yes

Inode 4588270 ref count is 3, should be 2.  Fix? yes

Inode 4588936 ref count is 3, should be 2.  Fix? yes

Inode 4588947 ref count is 3, should be 2.  Fix? yes

Inode 4589005 ref count is 3, should be 2.  Fix? yes

Inode 4589395 ref count is 3, should be 2.  Fix? yes

Inode 4589427 ref count is 3, should be 2.  Fix? yes

Inode 4589523 ref count is 3, should be 2.  Fix? yes

Inode 4589688 ref count is 3, should be 2.  Fix? yes

Inode 4589863 ref count is 3, should be 2.  Fix? yes

Inode 4589982 ref count is 3, should be 2.  Fix? yes

Inode 4590585 ref count is 3, should be 2.  Fix? yes

Inode 4590719 ref count is 3, should be 2.  Fix? yes

Inode 4590738 ref count is 3, should be 2.  Fix? yes

Inode 4591420 ref count is 3, should be 2.  Fix? yes

Inode 4591496 ref count is 3, should be 2.  Fix? yes

Inode 4718801 ref count is 3, should be 2.  Fix? yes

Inode 4719099 ref count is 3, should be 2.  Fix? yes

Inode 4719131 ref count is 3, should be 2.  Fix? yes

Inode 4719145 ref count is 3, should be 2.  Fix? yes

Inode 4719231 ref count is 3, should be 2.  Fix? yes

Inode 4719307 ref count is 3, should be 2.  Fix? yes

Inode 4719435 ref count is 4, should be 3.  Fix? yes

Inode 4719478 ref count is 3, should be 2.  Fix? yes

Inode 4719798 ref count is 3, should be 2.  Fix? yes

Inode 4719895 ref count is 3, should be 2.  Fix? yes

Inode 4719916 ref count is 4, should be 3.  Fix? yes

Inode 4719968 ref count is 3, should be 2.  Fix? yes

Inode 4720548 ref count is 3, should be 2.  Fix? yes

Inode 4724083 ref count is 3, should be 2.  Fix? yes

Inode 4725053 ref count is 4, should be 3.  Fix? yes

Inode 4850201 ref count is 3, should be 2.  Fix? yes

Inode 4850205 ref count is 3, should be 2.  Fix? yes

Inode 4850289 ref count is 3, should be 2.  Fix? yes

Inode 4853593 ref count is 3, should be 2.  Fix? yes

Inode 4867580 ref count is 3, should be 2.  Fix? yes

Inode 4867899 ref count is 3, should be 2.  Fix? yes

Inode 4876657 ref count is 3, should be 2.  Fix? yes

Inode 4878535 ref count is 3, should be 2.  Fix? yes

Inode 4878585 ref count is 3, should be 2.  Fix? yes

Inode 4878638 ref count is 3, should be 2.  Fix? yes

Inode 5002609 ref count is 3, should be 2.  Fix? yes

Inode 5003103 ref count is 3, should be 2.  Fix? yes

Inode 5003218 ref count is 3, should be 2.  Fix? yes

Inode 5003375 ref count is 3, should be 2.  Fix? yes

Inode 5003422 ref count is 3, should be 2.  Fix? yes

Inode 5003503 ref count is 3, should be 2.  Fix? yes

Inode 5005062 ref count is 3, should be 2.  Fix? yes

Inode 5005177 ref count is 3, should be 2.  Fix? yes

Inode 5005410 ref count is 3, should be 2.  Fix? yes

Inode 5005536 ref count is 3, should be 2.  Fix? yes

Inode 5005568 ref count is 3, should be 2.  Fix? yes

Inode 5005817 ref count is 3, should be 2.  Fix? yes

Inode 5005831 ref count is 3, should be 2.  Fix? yes

Inode 5005859 ref count is 3, should be 2.  Fix? yes

Inode 5006285 ref count is 3, should be 2.  Fix? yes

Inode 5006389 ref count is 3, should be 2.  Fix? yes

Inode 5006686 ref count is 3, should be 2.  Fix? yes

Inode 5007048 ref count is 3, should be 2.  Fix? yes

Inode 5111809 ref count is 3, should be 2.  Fix? yes

Inode 5111869 ref count is 3, should be 2.  Fix? yes

Inode 5111909 ref count is 3, should be 2.  Fix? yes

Inode 5114173 ref count is 3, should be 2.  Fix? yes

Inode 5116740 ref count is 6, should be 5.  Fix? yes

Inode 5119127 ref count is 3, should be 2.  Fix? yes

Inode 5119153 ref count is 3, should be 2.  Fix? yes

Inode 5119204 ref count is 3, should be 2.  Fix? yes

Inode 5119537 ref count is 3, should be 2.  Fix? yes

Inode 5119596 ref count is 3, should be 2.  Fix? yes

Inode 5119814 ref count is 3, should be 2.  Fix? yes

Inode 5120238 ref count is 3, should be 2.  Fix? yes

Inode 5120371 ref count is 3, should be 2.  Fix? yes

Inode 5120375 ref count is 3, should be 2.  Fix? yes

Inode 5120413 ref count is 3, should be 2.  Fix? yes

Inode 5120813 ref count is 3, should be 2.  Fix? yes

Inode 5120898 ref count is 3, should be 2.  Fix? yes

Inode 5121086 ref count is 3, should be 2.  Fix? yes

Inode 5121179 ref count is 3, should be 2.  Fix? yes

Inode 5242881 ref count is 3, should be 2.  Fix? yes

Inode 5243701 ref count is 3, should be 2.  Fix? yes

Inode 5243742 ref count is 3, should be 2.  Fix? yes

Inode 5243770 ref count is 3, should be 2.  Fix? yes

Inode 5243815 ref count is 3, should be 2.  Fix? yes

Inode 5244094 ref count is 3, should be 2.  Fix? yes

Inode 5244394 ref count is 3, should be 2.  Fix? yes

Inode 5244454 ref count is 5, should be 4.  Fix? yes

Inode 5244731 ref count is 3, should be 2.  Fix? yes

Inode 5244739 ref count is 3, should be 2.  Fix? yes

Inode 5244823 ref count is 3, should be 2.  Fix? yes

Inode 5244914 ref count is 3, should be 2.  Fix? yes

Inode 5244945 ref count is 3, should be 2.  Fix? yes

Inode 5245096 ref count is 3, should be 2.  Fix? yes

Inode 5245223 ref count is 3, should be 2.  Fix? yes

Inode 5245441 ref count is 3, should be 2.  Fix? yes

Inode 5245460 ref count is 3, should be 2.  Fix? yes

Inode 5245472 ref count is 3, should be 2.  Fix? yes

Inode 5245601 ref count is 3, should be 2.  Fix? yes

Inode 5246511 ref count is 4, should be 3.  Fix? yes

Inode 5249202 ref count is 3, should be 2.  Fix? yes

Inode 5253327 ref count is 3, should be 2.  Fix? yes

Inode 5374020 ref count is 3, should be 2.  Fix? yes

Inode 5374387 ref count is 3, should be 2.  Fix? yes

Inode 5374984 ref count is 3, should be 2.  Fix? yes

Inode 5375025 ref count is 3, should be 2.  Fix? yes

Inode 5376133 ref count is 3, should be 2.  Fix? yes

Inode 5377519 ref count is 3, should be 2.  Fix? yes

Inode 5377830 ref count is 3, should be 2.  Fix? yes

Inode 5378159 ref count is 3, should be 2.  Fix? yes

Inode 5378916 ref count is 3, should be 2.  Fix? yes

Pass 5: Checking group summary information

rootfs: ***** FILE SYSTEM WAS MODIFIED *****
rootfs: 949589/7823360 files (0.1% non-contiguous), 13921852/31265024 blocks

mke2fs isn't listing any errors so far at 42% done.

OK, now I'm getting errors. Apparently it writes one pattern to the whole space, then reads it back, then does a different pattern and reads that back, I think there are maybe 3 patterns it's going to use. Notice the last 2 lines here. It hogs CPU too, it's hard to do much else.

errs.gif (12.31 KiB) Viewed 2806 times

I left it running (in an rxvt window) and next morning it was sitting there in console mode repeating some error over and over about failing to remap a partition. And this is an SD that cost almost twice as much as a Pi a year ago? Wish I could get my money back, the best I can hope for is a replacement Transcend SD.

Made in Taiwan apparently and the warranty on all of them seems to be 5 years. All packed in an envelope with RMA and invoice ready to mail.