On 13-Dec-18 18:16, Gordan Bobic wrote: > You are likely to find that stress testing will kill most SD cards > within a day or two. They simply aren't designed for small write > workload. They are designed for large streaming writes (and they are > fine for reads, obviously). > > "Endurance" models fare much better, but you will still kill then > quickly with continuous small random writes. Starting point was exactly this. We saw FS corruption very lately, with very strange effects (especially when you are used to only SATA drives). One of them can be depicted like a ReadOnly FS not so ReadOnly ... Once formatted, the SD was working fine for a while. So, trying to narrow that down, mixing 3B and 3B+, with many devices, many different HATS, many different stuff, it came to the stress test and mount/copy/umount/fsck scenario, but yes, it took quite some time :-) The stress test will help us to perform some kind of qualification, for any new SD... > > If you want reasonable performance and longevity out of them, use > nilfs2 or ZFS. Otherwise they are only suitable for workloads that are > not random-write intensive in the way that traditional UNIX file > system workloads are. > > On Thu, 13 Dec 2018, 16:54 Stephan Guilloux > <stephan.guilloux at crisalid.com <mailto:stephan.guilloux at crisalid.com> > wrote: > > Well... > Stress test still running on reputable brand with no PB, after 6 > or 7h. > > During this stressing session, we found a few broken SD, from > another reputable brand. > Not all cards, though, but enough to put some confusion... ;-) > Something else added to the confusion, was an article on a Linux > block layer issue... > > OK. > Now, at least, we have a "stressing" tool and a stack of RPI in > case of doubt on SD :-) > > By the way, is there any well known bench mark tool for SD, on > CentOS or OpenSource ? > > > > Le 13/12/2018 à 16:19, Fred Gleason a écrit : >> On Dec 13, 2018, at 06:06, Manuel Wolfshant >> <wolfy at nobugconsulting.ro <mailto:wolfy at nobugconsulting.ro>> wrote: >> >>> did this happen with multiple SD-cards ? if not, I strongly >>> suspect that the issue is that particular card , not the OS. it >>> rhymes extremely well with either a faulty card or a card whose >>> firmware was doctored to report a larger size than the one it >>> really has >> >> ++ >> >> Been there, done that! After seeing a large number of ‘infant >> mortalities’ with RaspPi 3+ setups using cheapie ‘no brand’ >> microSD cards, we made the switch to using only ‘name brand’ >> cards from reputable manufacturers. Problem solved. >> >> >> Cheers! >> >> >> |----------------------------------------------------------------------| >> | Frederick F. Gleason, Jr. | Chief Developer >> | >> | | Paravel Systems >> | >> |----------------------------------------------------------------------| >> | A room without books is like a body without a soul. >> | >> | -- Cicero | >> |----------------------------------------------------------------------| >> >> _______________________________________________ >> Arm-dev mailing list >> Arm-dev at centos.org <mailto:Arm-dev at centos.org> >> https://lists.centos.org/mailman/listinfo/arm-dev > > _______________________________________________ > Arm-dev mailing list > Arm-dev at centos.org <mailto:Arm-dev at centos.org> > https://lists.centos.org/mailman/listinfo/arm-dev > > > > _______________________________________________ > Arm-dev mailing list > Arm-dev at centos.org > https://lists.centos.org/mailman/listinfo/arm-dev