If there is another, bigger system on the local network, you can always syslog the logs to that. That's what it was designed for. On Thu, 13 Dec 2018, 18:27 Robert Moskowitz <rgm at htt-consult.com wrote: > > > On 12/13/18 12:09 PM, Fred Gleason wrote: > > On Dec 13, 2018, at 11:54, Stephan Guilloux <stephan.guilloux at crisalid.com> > wrote: > > 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... ;-) > > > Well, remember, we are dealing with flash RAM here. After enough > write/erase cycles, it *will* wear out. The goal is to optimize the overall > system to get maximum lifetime out of the media. For example, on our > production setups we do things like putting ‘/var/log’ on tmpfs (it doesn’t > matter for the particular application that the log data evaporates after > reboots). That greatly reduces wear on the media, while still allowing log > data to be accessed during a session for debug purposes. > > > All too often I am looking at contents of /var/log after a system restart > to figure out what went wrong. > > So that is yet another reason I am sticking with SOCs that have good sata > support. So I can run rootfs there... > > > _______________________________________________ > Arm-dev mailing list > Arm-dev at centos.org > https://lists.centos.org/mailman/listinfo/arm-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/arm-dev/attachments/20181213/6affec71/attachment-0006.html>