I've got hundreds, if not thousands of these lines in my syslog.

 

Quote

 

Nov 18 10:33:25 NAS kernel: EXT4-fs warning (device sdp1): htree_dirblock_to_tree:962: inode #2: lblock 0: comm find: error -5 reading directory block
Nov 18 10:33:36 NAS kernel: EXT4-fs warning (device sdp1): htree_dirblock_to_tree:962: inode #2: lblock 0: comm find: error -5 reading directory block
Nov 18 10:33:48 NAS kernel: EXT4-fs warning (device sdp1): htree_dirblock_to_tree:962: inode #2: lblock 0: comm find: error -5 reading directory block
Nov 18 10:34:00 NAS kernel: EXT4-fs warning (device sdp1): htree_dirblock_to_tree:962: inode #2: lblock 0: comm find: error -5 reading directory block

 

 

I'd be really concerned about my drive sdp, except I don't have anything in my server that I can find that's identified as "sdp".

 

As I look through the Main page of WebGUI I can identify sda through sdo. It hit me that maybe it was a ghost from an Unassigned Devices that had been mounted at some point, so I plugged in both of the drives I've ever used via UD. They mounted up as sdq and sdr, so something has sdp and the server doesn't like it.

 

I do recall that at some point in the past, I was having issues with the server indicating there was a pre-clear in process on this same, non-existent sdp. I'll see if I can find that thread and link in the relevant bits.

 

I've attached diagnostics. If someone could parse through the important bits and

  A) identify what sdp is supposed to be, and

  B) figure out why it's giving all these EXT4-fs warnings and how I should resolve them

I'd be most appreciative. If there is any other info that would be helpful in tracking this down, let me know, I'm happy to provide it.
 

nas-diagnostics-20171118-1034.zip

Edited November 18, 20178 yr by FreeMan

Here is the post I started about the pre-clear on "sdp". There was no resolution. I'm going to rummage in the pre-clear support thread to see if I posted there.

6 minutes ago, FreeMan said:

A) identify what sdp is supposed to be, and

 

It was this:

 

/dev/sdp1       146G  125G   14G  91% /mnt/disks/Hitachi 160GB

Rebooting should clear the errors.

1 minute ago, johnnie.black said:

It was this:

 

Thanks, Jonnie. What file did you look in to find that and how long ago was that? (I could figure out the how long if I knew where to look)

Edited November 18, 20178 yr by FreeMan
grammar...

system\df.txt

 

Can't say how long since your syslog is missing the beginning.

I've noticed that I only ever have "syslog", "syslog.1" and "syslog.2" in /var/logs.

 

It's missing the beginning since those 3 files cover about 2 days (with all those error lines) and my server's been up for 175 days.

 

Is there a way to get it to keep more history, or is 3 files normally enough if the system isn't spewing errors every 7-8 seconds?

Having more than 1 syslog file is rare, and suggests you have an underlying issue that is causing much more writing to the syslog than is normal.

1 minute ago, itimpi said:

Having more than 1 syslog file is rare, and suggests you have an underlying issue that is causing much more writing to the syslog than is normal.

 

well... I think I may have identified the an underlying issue... I do often seem to have more than one syslog, so maybe there is something else going on, as well.

 

I was looking forward to seeing the Uptime display hitting 180 days. I think the most I've ever had in the past was about 139. (I keep screen shots, I know, I'm weird.)

 

I may have to reboot today and see if the errors return.

alrighty then, I've rebooted after being up nearly 6 months:

 

and no signs of an sdp:

Filesystem      Size  Used Avail Use% Mounted on
rootfs          7.5G  558M  6.9G   8% /
tmpfs           7.5G  432K  7.5G   1% /run
devtmpfs        7.5G     0  7.5G   0% /dev
cgroup_root     7.5G     0  7.5G   0% /sys/fs/cgroup
tmpfs           128M  2.9M  126M   3% /var/log
/dev/sdb1       3.8G  1.5G  2.4G  38% /boot
/dev/md1        932G  921G   11G  99% /mnt/disk1
/dev/md2        1.9T  1.8T   22G  99% /mnt/disk2
/dev/md3        932G  916G   16G  99% /mnt/disk3
/dev/md4        1.9T  1.9T   12G 100% /mnt/disk4
/dev/md5        3.7T  3.7T   32G 100% /mnt/disk5
/dev/md6        1.9T  1.9T  6.8G 100% /mnt/disk6
/dev/md7        1.9T  1.3T  550G  71% /mnt/disk7
/dev/md8        1.9T  1.8T   44G  98% /mnt/disk8
/dev/md9        932G  893G   39G  96% /mnt/disk9
/dev/md10       2.8T  2.7T   35G  99% /mnt/disk10
/dev/md11       3.7T  1.8T  2.0T  48% /mnt/disk11
/dev/md12       3.7T  1.6T  2.1T  43% /mnt/disk12
/dev/sdi1       224G   67G  157G  30% /mnt/cache
shfs             26T   21T  4.8T  82% /mnt/user0
shfs             26T   21T  5.0T  81% /mnt/user
/dev/loop0       30G  8.1G   21G  29% /var/lib/docker
shm              64M     0   64M   0% /var/lib/docker/containers/837ed2f07c02c93fd2b204c5d5b9ce0c54fe119034185a2c1cff30fec818d071/shm
shm              64M     0   64M   0% /var/lib/docker/containers/9e25a915f238aa0232a885e276ddb61e33e4d9b7ca4965188315c68d752ed70f/shm
shm              64M     0   64M   0% /var/lib/docker/containers/953e36b104638b403781ce5e195a7d0f29dfaf134ecb7635edd6f17a90fd795e/shm
shm              64M     0   64M   0% /var/lib/docker/containers/dc89efaf622532486b234031482d7b11030564ff842f2c45b312f61ec02fd078/shm
shm              64M     0   64M   0% /var/lib/docker/containers/b80f4c1c745c6402f7d692621e26c12b8351509101d7ad1d1a1d96880ed76662/shm
shm              64M     0   64M   0% /var/lib/docker/containers/b6b73ad93b85842f1471bdb4be117b1e3f3e2f64ca32c25b17e91a4d3e82e008/shm
shm              64M     0   64M   0% /var/lib/docker/containers/4c2815dd144dd45f66939616fc27311724a00cb45b32c6208cb87e956d9a5345/shm
shm              64M     0   64M   0% /var/lib/docker/containers/9f676d36fac6e519755e924c11d792bdb21693ab798c66dc5a84ca6fb3af5417/shm
shm              64M     0   64M   0% /var/lib/docker/containers/067226e9eb3b630bebd2a7d5e59ac411b52e09dfeea3c341756dd105e84b5435/shm
shm              64M     0   64M   0% /var/lib/docker/containers/a42ed96dc31499299a13633131e71b30e82e62f6ef91a8185e0a7de010e0b03d/shm
shm              64M     0   64M   0% /var/lib/docker/containers/f91f18bc33833003e6c3c6acbf36b709ed7079e7bc14934f050f546f5b9c846d/shm
shm              64M     0   64M   0% /var/lib/docker/containers/ea1630eb8f2d0773fbfe5d4fb9a7197e80561256f3dd535d6c236b9f31108862/shm

 

Maybe now I'll get drives spinning down too. I'll let it run for a while and see what happens. I'll start a new issue if they don't spin down.

As a follow up, this seems to have also resolved my "disks not spinning down" issue. I manually spun everything down after the reboot and none have spun up in the hour since.