February 27, 201412 yr Running version unRAID Pro v5.05 with various 2TB drives (7 data + 1 parity). The web interface has been locking up frequently lately. Today I had to force a power down to regain control. From the resulting Syslog Feb 26 13:30:13 Alfred emhttp: unclean shutdown detected Feb 26 13:30:13 Alfred kernel: mdcmd (45): check CORRECT Feb 26 13:30:13 Alfred kernel: md: recovery thread woken up ... Feb 26 13:30:13 Alfred kernel: md: recovery thread checking parity... Feb 26 13:30:13 Alfred kernel: md: using 1536k window, over a total of 1953514552 blocks. Feb 26 13:30:14 Alfred kernel: md: correcting parity, sector=65680 Since I have seven data drives, I could have up to seven files that occupy sector 65680. How can I determine which file resides on that sector on each disk? I have reverted from the latest web GUI back to the stock GUI, and no lockups so far (knock on simulated wood grain product). Thanks for your help! -- stewartwb syslog.txt
February 27, 201412 yr What are all those ethernet 'bonding' errors, starting at around line #1100 in the syslog? Looks as if the ethernet connection is flipped from eth0 to eth1, but shortly after, eth0 goes looking for a DNS address...
February 27, 201412 yr Author What are all those ethernet 'bonding' errors, starting at around line #1100 in the syslog? Looks as if the ethernet connection is flipped from eth0 to eth1, but shortly after, eth0 goes looking for a DNS address... First, I am using DHCP reservations by MAC address to assign my server's IP, rather than hard-coding an IP directly in the unRAID GUI. After rebooting the server, I used the Web GUI's Network Settings page to switch bonding mode from active-backup (1) to Balance-rr (0). Those messages show the interface restarting to apply the bonding configuration change. Line 540 shows that at boot time mode=1 for active-backup mode. Feb 26 13:30:09 Alfred logger: /etc/rc.d/rc.inet1: modprobe bonding mode=1 miimon=100 Line 1082 shows the web interface starting to reconfigure the NICs and bonding mode, after I hit Apply Feb 26 13:32:28 Alfred emhttp: shcmd (50): /usr/local/sbin/emhttp_event stopping_svcs Line 1119 shows the new mode=0 for Balance Round-Robin mode Feb 26 13:32:32 Alfred logger: /etc/rc.d/rc.inet1: modprobe bonding mode=0 miimon=100
February 27, 201412 yr Thanks, stewartwb. I've never tried bonding mode. Sorry to divert attention from the problem posed. So...how can stewartwb find out which files are on Sector 65680 of each of his data drives?
February 27, 201412 yr I do not believe there is any easy way to find out which file corresponds to any particular sector on a disk.
February 27, 201412 yr https://www.google.com/search?client=safari&rls=en&q=find+file+on+bad+sector+reiserfsck&ie=UTF-8&oe=UTF-8#q=find+file+on+bad+sector+reiserfsck&rls=en
March 3, 201412 yr Author I don't have any bad blocks per-se, just a specific sector reported as needing a parity correction. I'd like to open and check the files that were involved with that operation, once I identify them. Following steps on this page: http://smartmontools.sourceforge.net/badblockhowto.html#reiserfs_ex I calculated block # 8202 houses sector 65680 Partition aligned to start at sector 64 Block size = 4096 bytes 512 bytes per sector Block number = (65680 - 64)*512/4096 = 8202 debugreiserfs -1 8202 /dev/sdd1 returns debugreiserfs 3.6.24 8202 is used in ondisk bitmap =================================================================== LEAF NODE (8202) contains level=1, nr_items=1, free_space=0 rdkey (real items 1) ------------------------------------------------------------------------------- |###|type|ilen|f/sp| loc|fmt|fsck| key | | | | |e/cn| | |need| | ------------------------------------------------------------------------------- | 0|154133 154138 0x1dec5001 IND (1), len 4048, location 48 entry count 0, fsck need 0, format new| 1012 pointers [ 195722156(1012)] =================================================================== Doesn't tell me which file uses that sector. Still looking for a solution...
Archived
This topic is now archived and is closed to further replies.