On Fri, 2019-03-01 at 10:12 +0000, Peter Humphrey wrote: > On Thursday, 28 February 2019 15:47:41 GMT Rich Freeman wrote: > > > In general it is usually simplest to just remove /usr/portage > > anytime > > you change the sync settings. At least until portage gets smarter > > about it. > > That works well on a sufficiently powerful box; it only took - oh, I > don't > know - maybe a couple of minutes on this workstation. On my little > Atom box, > though, it takes 75 minutes. > > [OT] > Evidence is mounting that the Atom box is in terminal decline. I get > things > like batches of files in the portage tree changing owner, and then > when I > correct that, long lists of supposedly locally changed ebuilds > preventing > syncing. And when I boot weekly into its little rescue system to > backup the > main system, the root filesystem remounts itself read-only while tar > is > running. Smartd recognises the SSD and runs daily tests, but reports > no > errors. No amount of wiping and reinstalling has helped so far. > What filesystem are you running and how old is the SSD? That sounds like some of the symptoms EXT4 had on early generation flash media where its assumptions about what order writes would physically make it to the disk in were wrong, leading to corruption. So unless it was working correctly at some point in the past, try a different filesystem. EXT3 or BTRFS didn't have the same problems.
If it's just that the SSD is failing, then get a new one before something important gets damaged and you have to redo the whole thing. The self-test capability of storage media is almost universally horrible and you generally don't get a failure report until your data has already been lost. If your SMART output gives you the raw statistics on the device instead of just pass/fail then analyzing that usually gives a better indication of whether something is about to go wrong. LMP
signature.asc
Description: This is a digitally signed message part
