Raspberry PI, SlackwareARM, fs integrity and power outages
 

I have been running a Raspberry PI model B (1st version) with SlackwareARM-14.1 installed according to Exaga's guide.

I have experienced not so rare power outages. By that I mean "mains power" and a few times brownout on the PI due to high current consumption by a USB-WiFi dongle.

Even with the standard FS checks done at startup, after several weeks I experienced more and more FS corruption after several outages.
I checked the card (badblocks), no errors reported.
The SDCARD is a class 10 Sandisk from the RPI compatibility list.

The FS got so badly damaged that after manually answering about a hundred items for fsck, I gave up and rewrote the card from a backup image.
Then I tried a Verbatim card (also on the list). Same results over time.

I know SDCARDs work internally quite different from HDDs, one such difference being in internal block size, reading, erasing a block before, then writing it back (large blocks even for a single bit change).

Has anyone encountered such corruption after power outages?

Are there optimizations that can help reduce or eliminate the chances for such corruptions?

Such as:
- using fdisk to align partitions to certain boundaries?
- using mkfs.ext4 and tune2fs to set special FS parameters regarding alignments and special FS options regarding it running of a flash memory rather then hdd?
- installing on several partitions:
* /boot (ro)
* / (ro)
* /home (rw)
* /var (rw)
maybe /etc ? (there are several files written to /etc at run time)

I am seeking installation/configuration improvements.
From hardware perspective I know for USB a powered hub would help and that a UPS would help. But these may not always be available.

I live in a storm afflicted area. Since I put a pi 3 in a week ago it has rebooted at least every day from power drops.
I use ext4 and it has survived without corruption on the restart. Class 10 Sandisk.

I have just ordered a small fanless UPS for the router and pi. You might want to consider likewise.

Any advice for the SDCARD specific medium also regarding these:

- disk caching, amount of data cached in memory before commited to disk. How much (to be safe), how much to avoid killing performance due to slow writes

- ext4 delayed writes, as described here:
https://en.wikipedia.org/wiki/Ext4#D...tial_data_loss

- ext4 specific options like:
* block_validity (data integrity gains vs. performance loss)
* discard (does this apply to SDCARDS?)
* nodelalloc (disable delayed allocation described above)
* uninit_bg (reduce e2fsck runtimes, beneficial on the SDCARD and PI?)
* flex_bg and mkfs -G option?
* custom inode size (with reference to SDCARD hardware)
* bigalloc (might help with SDCARD hardware page size?)

My question is now even more general, if any PI and SlackwareARM users have played with such options and with what results.

I had a couple corruption issues with my first PI. Some advice I received from the forum here was that USB flash is faster and more reliable than SD/MicroSD. So I started using a small 16 or 32G USB flash for mt /root leaving only the SD as /boot and haven't had an issue since.

Have you tested using a SDCARD in an USB card reader instead of an USB flash drive?
To see if it has anything to do specifically with SDCARDS, or with the SDCARD interface of the PI?

Once you've verified whether the media is still good or not you might want to give this blog a read.

I have not tested with an sdcard in a usb adapter. I seem to be having issues cloning my sd card, put it and a usb flash drive in my laptop and dd'ed it. I have /boot and /root on the sd and since I dd'ed both to the usb I tried to edit fstab to use /root from the usb it panic'ed.
I wish they would make these USB boot.

You just have to bolt an ISCSI initiator onto your Raspberry Pi and then it will boot from SAN, like the good Lord intended....

Very interesting idea.

Of course, however, having a SAN available for any RPi based project may not always be feasible...

Admittedly, though you can make a SAN from an RPi, some cabling, a hub and some USB hard drives (USB2 Hard drives are pretty cheap right now).
Upon Further Consideration:
While a personal SAN is imminently doable as an RPi project and goodness knows everyone would enjoy the hours of pouring over LUN IDs, WWNNs, et al, SAN and SAN zoning entails, that RPi (the one hosting the theoretical SAN)would still have to boot from its on board card so file corruption is still a show stopper.
I might give enines' solution a try.

The problem with the RPis for making NAS is that they don't have Gigabit NICs ... so the NAS performance will be bogged don not only by the USB2 mass storage throughput but also bu the fast Ethernet limited performance. If I remember right there is another limiting factor: the RPi's NIC and the USB ports are all on the same USB bus so they all share the same bandwidth (due to bus access constraints, the effective throughput of the USB2 High Speed signaling rate is limited to 280 Mbit/s or 35 MB/s).

If you're going to make a NAS from a Rpi2/3 it will be sufficient from media streaming but your upload times might be comparable to the play times of the media you deposit on it.

An SBC with Gb Ethernet NIC would be much better suited for making a NAS (plenty of options there) end even more so if it had 2 or more sata ports on-board (not so common unfortunately).

@dijetlo: actually my reply was about the idea to already have a SAN and make the RPi boot over the network from it.

@louigi600: Regarding the limitations of the RPi for a SAN project, one might consider the Olinuxino Lime 2: Cortex A7 dual core @1GHz, 1GB RAM, native SATA port, 1Gbps ethernet.

I run my NAS off a Seagate GoFlex NET: not much ram and internal flash but it can boot of the SATA drives and has 2 onboard SATA ports and Gb NIC.

If you can do without redundancy I guess 1 SATA port is good enough .... But loosing 1Tb, or more, of data dew to a disk failure can be a pain in the but even if it's not vital data. I software mirror the 2 SATA drives on my NAS ... so if one fails I can hopefully replace it before I loose the data.

Is your LIME running SlackwareARM ? :)

One could, concievably use a SATA port expander, though it is not recommended for RAID (as in if one disk fails, the port on the LIME will go down, but your data will still be safe on the second disk).