On 10/28/26 08:09, bob prohaska wrote: > On Wed, Oct 28, 2026 at 04:11:02AM +0000, void wrote: >> On Wed, Oct 21, 2026 at 11:33:06AM -0700, bob prohaska wrote: >> [filesystem errors] >> >> Have you tried making an nfs server on a more powerful box >> and exporting /usr/src ports obj and optionally ccache to your rpi2b? >> >> I have a setup like this and it works well. >> -- > > I haven't, simply because I'd like to understand what went wrong, > to the extent of my ability. > > In the meantime I've added a few files to the repository of errors at > http://www.zefox.net/~fbsd/rpi2/disktrouble/
Context presented: http://www.zefox.net/~fbsd/rpi2/disktrouble/diskscan2 But all 5 of your scans have examples that are over 1 second. All the below reads took over 3 seconds. The first figure is in units of msec: 3186.687 1.000000 15261959 8388608.00 3186.687 1.000000 15261959 9320675.55 3186.687 1.000000 15261959 10485760.00 3186.687 1.000000 15261959 11983725.71 3186.687 1.000000 15261959 13981013.34 3598.335 1.000000 15261960 16777216.00 3598.335 1.000000 15261960 inf There are a bunch that are over 1 sec. The maximum observed over 3 scans need not show near the maximums that have sometimes occurred in normal use (ignoring seek time). (The 1.000000's are labeled as percentiles but really are the fractions without scaling to percent.) It appears that the unusually long times start with: 3.323 0.999658 15256744 2925.71 6.439 0.999707 15257489 3413.33 9.711 0.999756 15258234 4096.00 10.791 0.999780 15258608 4551.11 Prior to that was much smaller time increments: 2.024 0.998633 15241136 731.43 2.055 0.998828 15244138 853.33 2.125 0.999023 15247124 1024.00 2.163 0.999121 15248560 1137.78 2.203 0.999219 15250077 1280.00 2.273 0.999316 15251538 1462.86 2.341 0.999414 15253087 1706.67 2.389 0.999512 15254570 2048.00 2.443 0.999561 15255257 2275.56 2.483 0.999609 15256006 2560.00 You ran the default sequential test, so seek time is generally not expected to be involved. (That is good for the purpose.) The above indicates that the hardware is not working well. For all I know the read times can be long enough that various timeouts might happen. > > In particular, there are now two diskscan reports taken while accessing > the disk via the same powered hub (and hub power supply) that presided > over the initial problem. Near as I can tell, the hub does not interfere > with the performance of the disk. But it also does not avoid reads that take over 1 second: http://www.zefox.net/~fbsd/rpi2/disktrouble/hub_diskscan1 4.519 0.999414 15253025 1706.67 5.215 0.999512 15254509 2048.00 6.427 0.999561 15255255 2275.56 8.703 0.999609 15256004 2560.00 11.007 0.999658 15256746 2925.71 . . . 1150.975 1.000000 15261958 5242880.00 1150.975 1.000000 15261958 5991862.86 1150.975 1.000000 15261958 6990506.67 1273.855 1.000000 15261959 8388608.00 1273.855 1.000000 15261959 9320675.55 1273.855 1.000000 15261959 10485760.00 1273.855 1.000000 15261959 11983725.71 1273.855 1.000000 15261959 13981013.34 1329.151 1.000000 15261960 16777216.00 1329.151 1.000000 15261960 inf http://www.zefox.net/~fbsd/rpi2/disktrouble/hub_diskscan2 4.503 0.999609 15256001 2560.00 6.115 0.999658 15256744 2925.71 9.671 0.999707 15257489 3413.33 11.703 0.999756 15258235 4096.00 . . . 1131.519 1.000000 15261959 8388608.00 1131.519 1.000000 15261959 9320675.55 1131.519 1.000000 15261959 10485760.00 1131.519 1.000000 15261959 11983725.71 1131.519 1.000000 15261959 13981013.34 1859.583 1.000000 15261960 16777216.00 1859.583 1.000000 15261960 inf > > Thanks for writing, > > bob prohaska > > > Side note: I'll note that the powered hub does add to the read times. The smallest reported for that context is: 1.934 0.000000 1 1.00 Comparing the near 0.9 fraction/percentiles for the 3 non-powered hub example scans: 0.901 0.900000 13735974 10.00 0.902 0.900000 13738412 10.00 0.902 0.900000 13738899 10.00 -- === Mark Millard marklmi at yahoo.com
