1 |
On Tuesday, October 27, 2015 12:25:07 PM Peter Humphrey wrote: |
2 |
> On Tuesday 27 October 2015 12:04:46 Stefan G. Weichinger wrote: |
3 |
> > Am 26.10.2015 um 15:47 schrieb Peter Humphrey: |
4 |
> > > I keep the portage tree under /usr-bits. |
5 |
> > > |
6 |
> > > # dmesg | grep sdb3 |
7 |
> > > [ 1.753508] sdb: sdb1 sdb2 sdb3 sdb4 < sdb5 sdb6 sdb7 sdb8 sdb9 > |
8 |
> > > [ 4.833460] EXT4-fs (sdb3): mounted filesystem with ordered data |
9 |
> > > mode. |
10 |
> > > Opts: (null) |
11 |
> > > [ 107.205918] EXT4-fs (sdb3): mounted filesystem with ordered data |
12 |
> > > mode. |
13 |
> > > Opts: (null) |
14 |
> > > |
15 |
> > > You can see the successful mount at 4.8 s; the entry at 107 s is me |
16 |
> > > mounting it again manually. |
17 |
> > > |
18 |
> > > I've rewritten the partition label, and I've run a smartctl test which |
19 |
> > > reported no faults found. I've also just reduced the speed of the |
20 |
> > > chipset, |
21 |
> > > which has three settings: good performance, better performance and |
22 |
> > > turbo. |
23 |
> > > It adopts the turbo setting by default and I've now set it to "better". |
24 |
> > > It's too early yet to see if that will help. |
25 |
> > |
26 |
> > interesting ... |
27 |
> > |
28 |
> > What init-system? openrc or systemd? |
29 |
> |
30 |
> Openrc. |
31 |
> |
32 |
> > No trace of the actual unmount in any logs? |
33 |
> |
34 |
> Not that I can find, no. |
35 |
> |
36 |
> > Maybe also look/grep for the LABEL of the fs. |
37 |
> |
38 |
> Nope, nor that. |
39 |
> |
40 |
> > Maybe test if using the device-name itself ( /dev/sdb3 ) or the UUID in |
41 |
> > fstab changes the behavior. |
42 |
> |
43 |
> I'll try reverting to /dev/sdb3 and see if that helps. |
44 |
> |
45 |
> > I use UUIDs here without problems (with systemd). |
46 |
> |
47 |
> The only thing I use UUIDs for here is in mdadm.conf to get the LVs started |
48 |
> reliably for the main system*. Those live in partitions /dev/sd[ab][5789]. |
49 |
> |
50 |
> Three more things: I've had the cover off and checked the seating of the |
51 |
> SATA cables; while the lid was off I watched the MB LEDs during startup, |
52 |
> which seemed okay; and today the kernel was upgraded from 4.0.5 to 4.0.9; |
53 |
> that may help too. (Hm ... too many changes at once.) |
54 |
> |
55 |
> * Now that I think of it, one of the LVs came up as inactive the other day, |
56 |
> and nothing I could think of would activate it (consulting man mdadm of |
57 |
> course). In the end I had to reboot. This machine has shown some bizarre |
58 |
> behaviour over the last few months. Something is definitely wrong; I just |
59 |
> can't figure out what it is. |
60 |
|
61 |
The full log for that entire period might be useful. |
62 |
|
63 |
If a disk is umounted/removed, something needs to be logged somewhere. |
64 |
Might even be a comment from the scsi-subsystem or the SATA driver. |
65 |
|
66 |
I usually only grep the log to try to find specific messages. |
67 |
If I know the time-period something weird happened in, I tend to go through |
68 |
the unfiltered log for that period. |
69 |
|
70 |
-- |
71 |
Joost |