Nice ad.

Hi,

@nolretou Do you think it's ad? @Penthux has a few posts here on LQ, so I wouldn't think it's just ad.
Looking at the price of the Samsung card, it might be good. It's not the cheapest and not the most expensive one.

Anyway, yesterday I had a quick play with Arietta G25 board, and, you guessed it, I had SD/MMC related errors...

My motto is this one: if you can stay away from SD/MMC, then by all means do.

--
Best regards,
Andrzej Telszewski

I've been running a server oriented Slackware install on the RPi2 for seven months using a SanDisk MicroSDHC Ultra UHS-I 32GB card.
Its purpose is to host my WordPress site which serves on average 5000 requests a day, so it's not all idle.
As for stability, I've only experienced data corruption while doing some extreme overclocking.
When using a sensible configuration (still overclocked), I've had no further issues.

For the record, I wouldn’t dismiss the advice from Penthux regarding Samsung EVO.

Yes, you've found me out. I'm getting paid so much by Samsung to sing their praises I won't have to work in 2016!

However, joking aside, Andrzej asked for opinions and I gave mine. For what it's worth you can take it or leave it. Not only do I use the Samsung EVO microSD cards on the rpi and rpi2, I use them on the Hummingboard and Orange Pi as well. So, having tried and tested many different brands (and unbranded) cards, in my personal experience Samsung EVO are the best.

(Ohhh... I can hear all those dollar$ just dropping into my bank account. Thank you Samsung! XXX)

Slightly on-topic, since we're talking about SD cards and stability:

1. Don't use a journaling/logging filesystem that isn't designated "flash-friendly." These would include ext3, ReiserFS, XFS, and JFS. Journaling is not optional except as an administrative matter (to speed up restoring backups).

1a. However, btrfs and F2FS have code specifically to account for the particular characteristics of flash media (discard page size and wear minimizing, for example). They are log-structured filesystems, that is, the log/journal IS the filesystem.

2. FAT doesn't support proper privileges. Avoid it if you can.

3. That leaves ext2 and ext4 among the stable Linux filesystems. It's possible to make an ext4 filesystem w/o a journal. Its other benefit is using extents rather than allocation bitmaps, resulting in shorter meta-data writes for larger data changes.

So you can guess which one I use. ;-)

Hi,

How does ext4 without journaling goes through power failure?
Will it survive?

--
Best regards,
Andrzej Telszewski

The recovery is like for ext2: make sure the meta-data is consistent. A journal would ensure this, but the journal causes extra wear on SD media. But even without the journal, the recovery is faster for ext4 than for ext2, again because of extent-based allocation mapping (less I/O). I haven't yet destroyed an ext4 filesystem on an SD card, even after 3-1/2 years of tinkering with my Raspberry Pi.

The following URL might be of interest - Raspberry Pi microSD card performance comparison - 2015

I the past I ran slackware on my Aspire One from the SD card. After having had a short life on one particular SD I started mounting filesystems on flash devices with the "noatome" option which avoids updating the access time on each file that is accessed. Since then I've mot had any issues worth mentioning with SD (or generic flash) devices including all the stuff I used after that with SD (AC100, Pi's, XZPAD ...)
Another thing that you should possibly avoid is swapping on flash devices.

Lower price flash devices tent to use MLC technology that typically has a MTBF on the rewrite count an order of magnitude smaller then SLC (technology mostly on the higher cost devices). It is not uncommon that MLC devices have 10,000 rewrites cycles while SLC devices 100,000 rewrite cycles. Most of the time I invest in low priece devices because I tend to want a bigger size device before the older smaller one wares out.

At some point I've formatted with ext(2/3/4) every SD or usb flash stick I've owned. As long as I create a new partition layout from scratch on the media I never ran into not being able to put ext(2/3/4) filesystem on any SD or usb flash stick. Looking at that chart I may have got lucky ... but then again there are cards that are reported for not working on either fat32 or ext ... find that hard to believe !

It's because of the data write.
If you burst let's say a source code on the card, it will crash it.
If you put small files one by one, it's ok. Typically Transcend in the pre-2010 era.

I installed and ran slackware on a 8Gb Transcend SD on my Aspire One in the pre 2010 era and even extracted kernel tarballs and compiled then on that SD. I must be a lucky guy ... but now that you mention I do recall that I had returned on type of SD because I could not get it to work ... I had done a bit of research on the device and found several people complaining (even if I had a faulty unit I was not going to test my luck) so I had it replaced with a different brand same size device.

I've had a beaglebone black running 24/7 in an industrial environment for about 6 months with the os on a Transcend SD card and occasionally saving machine settings to it and so far no problems.
I've been using sd cards a lot over the last 18 months and only had a problem with one of them which was caused by something I did.

Is noatome a typo for noatime ?

To be sure, would you valid this step by step :
Fully inspired by :
http://fenidik.blogspot.fr/2010/03/ext4-disable-journal.html?m=1

Yes that was a typo noatime is the option.

I don't like using distro defaults (that may have made arguable choices for the block size and inode numbers based on partitions sizes mostly relevant to ordinary rotating mass storage) I prefer to make the filesystem with mke2fs and specify all the options I like.
Here is an example
[CODE] mke2fs -t ext4 -b 4096 -i 16384 -m 1 -L ma_label -j /dev/my_device [\CODE]
Based on the size of the filesystem I may resort to deciding the total number of inodes via -N or have less then 1 inode for every 4 blocks.
The block size has a fairly important impact on wasted space as on avarage you will waste 1/2 a block for every file on your filesystem.
Small blocks will waste less space but will perform worse for I/O, while large blosks do the exact opposite.
The default reserved space used to default to 5% which is huge on a 1TB filesystem ... I will generally specify what I think is appropriate for the fs I'm making.

Journaling filesystems has it's advantages even on flash devices ... but it's up to you to decide if you would rather sacrifice flash life for better crash resistance.
On removable flash media like SSD, USB memory stick, SD and so on I would rather use journal, on flash soldered on the motherboard I will consider using non journaled ext* but if it supports using JFFS2 UBIFS or something like that I would trust the ware leveling and still use journal.

On some distros the default data for ext3/4 is data=journal which I regard as probably being the worse choice for ext3/4 on flash, wedge between ordered and writeback based on what your goal is.
According to https://www.kernel.org/doc/Documentation/filesystems/ext4.txt the default data is data=ordered

Not sure what you mean by "Required fsck" ... I don't run it after I make the fs and the "-f" flag does not make it mandatory for fsck to run during initialization.
If you want to make sure your fs is created on good blocks you might wnat to make the fs with -c flag ... if you want fsck to run during initialization put 1 or 2 in the sixth field instead of 0.

I've a blog about running linux on flash: http://www.linuxquestions.org/questions/blog/louigi600-808242/some-thoughts-on-running-linux-off-flash-mass-storage-36895/

1 members found this post helpful.

I am not using RPi, but Olimex A20 for the last couple of years. A couple of hundred of them.
Everything runs from a microSD.
Quite a lot of reading and writing, using ext4.
Once the A20 is put into use, it never shutdown, barring power outage events.

During that time and having to use so many of these devils, these are my observations.

1) Not all SD cards are created equal. Experiment. A lot. I need at least UHS-1 class cards. I favor ADATA-made if I can find them, SanDisk if not. Criteria is reliability and price/performance. Not all UHS-1 have the same level of support of the standard.

2) Of all the A20's, about 4 had erratic card reader. So you need to factor this too for the RPi or for any other single-board you use.

3) I had about 8 failures due to corrupted filesystem. I cannot attribute these failures directly to the microSD card, but in all cases of corrupted filesystems the SD card even if formatted had very little life left.

I am no way affiliated with Olimex and although the discussion is about RPi, I though I would contribute my findings since it is quite possible that the individual components that make the RPi or the A20 would be sourced from the same manufacturer.

J