Skip to content
View in the app

A better way to browse. Learn more.
Unraid

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.
Unraid Summer Sale in live: 20% off Starter and Unleashed + buy one, get one 50% off

unRAID Server Release 5.0-rc12 Available

limetech
in Announcements

Featured Replies

Thanks,

 

AFP places the .AppleDesktop\.volinfo and .AppleDouble\.parent per AFP share only on one disk and doesnt change often and not a single one changed today. The db for the apple shares I don't even store on the array or cache drive, I have it on a separate disk off unRAID array/cache drive. Storing in on the array cause a full rebuilt every reboot otherwise, and is unacceptable. So I agree AFP is reading ALOT of something and writes little something (ACL, extended attribute, don't know) per the web gui stats, but nothing clear as to what.

 

Memtest'ed my build 2 years ago for a week straight (ECC fully buffered) passed with flying colors.

850w gold PSU over kill for what I have.

 

Thanks for the suggestion prostuff1

 

  • Replies 480
  • Views 151.2k
  • Created
  • Last Reply

The nfs stale file handle issue is a bugger because of how FUSE works.  The solution here is going to involve either a large amount of RAM or use of a swap device/file.

 

I don't quite understand why you were able to effect a significant improvement in the nfs stale file handle issue a couple of RCs back, but it suddenly became worse again between rc10 and rc11.  Did FUSE change between those two releases?

 

Looking back through the release notes, I can see that you made a change to shfs in rc4 to address the nfs stale file handle problem.  While this didn't completely fix every instance of the problem, it did make things a great deal better.

 

I still wonder, then, why the problem returned with avengeance in rc11.  The release notes record two shfs changes in rc11 - did these, somehow, negate the change you made in rc4?

Same here. rc11 is fine but rc12 does not recognise NIC.

 

Here is a dump form rc11

 

ethtool -i eth0
driver: r8168
version: 8.035.00-NAPI
firmware-version:
bus-info: 0000:02:00.0

 

Update: I am pretty certain in 4.7 this was the r8169 driver not r8168

 

Yay!  Just saw your link for rc12a.  Copied bzimage, and bzroot to my rc10 configuration and now it works.  NIC card recognized.  Thank you.

Stop AFP, then go through each of your shares and rebuild the CNID stores.

 

telnet: dbd -rf /mnt/user/Share

 

If you're extra keen, run newperms beforehand:

 

telnet: nohup /usr/local/sbin/newperms &

Thanks,

 

AFP places the .AppleDesktop\.volinfo and .AppleDouble\.parent per AFP share only on one disk and doesnt change often and not a single one changed today. The db for the apple shares I don't even store on the array or cache drive, I have it on a separate disk off unRAID array/cache drive. Storing in on the array cause a full rebuilt every reboot otherwise, and is unacceptable. So I agree AFP is reading ALOT of something and writes little something (ACL, extended attribute, don't know) per the web gui stats, but nothing clear as to what.

 

Memtest'ed my build 2 years ago for a week straight (ECC fully buffered) passed with flying colors.

850w gold PSU over kill for what I have.

 

Thanks for the suggestion prostuff1

 

Weird, I'm not seeing this behavior.

Just to confirm 12a fixed my NIC issue as expected

Reboot after mover crash.

 

I have asked this before, no answer from Tom, The question was why are there so many reads and several writes to each and every disk in the array when you first start the array including the parity drive, when no clients are attached. THis reading and writing last for about 10-15 mins. Any and every reboot of unRAID.

 

Upon this reboot, and starting the array I did not wait 10-15 minutes for these reads and writes to subside, and launched mover manually.

 

This time not only did mover crashe but a Kernel oops, cant get a syslog, unRAID is frozen, grabbed what was being spit out via a console session:

 

Mar 23 19:36:48 Tower emhttp: shcmd (132): /usr/local/sbin/mover |& logger &
Mar 23 19:36:48 Tower logger: mover started
Mar 23 19:36:48 Tower logger: skipping Backup/
Mar 23 19:36:48 Tower logger: skipping Handbrake/
Mar 23 19:36:48 Tower logger: moving Kids Movies/
Mar 23 19:36:48 Tower logger: ./Kids Movies/Wreck-It Ralph (2012) BRu/Wreck-It.Ralph.2012.PROPER.BluRay.720p.DTS.x264-DON.nfo
Mar 23 19:36:48 Tower logger: .d..t...... ./
Mar 23 19:36:48 Tower logger: rsync: get_xattr_names: llistxattr("Kids Movies",1024) failed: Software caused connection abort (103)
Mar 23 19:36:48 Tower logger: .d..t.....x Kids Movies/
Mar 23 19:36:48 Tower logger: rsync: get_acl: sys_acl_get_file(Kids Movies, ACL_TYPE_ACCESS): Transport endpoint is not connected (107)
Mar 23 19:36:48 Tower logger: rsync: failed to set times on "/mnt/user0/Kids Movies": Transport endpoint is not connected (107)
Mar 23 19:36:48 Tower logger: cd+++++++++ Kids Movies/Wreck-It Ralph (2012) BRu/
Mar 23 19:36:48 Tower logger: rsync: recv_generator: mkdir "/mnt/user0/Kids Movies/Wreck-It Ralph (2012) BRu" failed: Transport endpoint is not connected (107)
Mar 23 19:36:48 Tower logger: *** Skipping any contents from this failed directory ***
Mar 23 19:36:48 Tower logger: rsync: get_acl: sys_acl_get_file(Kids Movies, ACL_TYPE_ACCESS): Transport endpoint is not connected (107)
Mar 23 19:36:48 Tower logger: rsync: get_xattr_names: llistxattr("Kids Movies",1024) failed: Transport endpoint is not connected (107)
Mar 23 19:36:48 Tower logger: rsync: failed to set times on "/mnt/user0/Kids Movies": Transport endpoint is not connected (107)
Mar 23 19:36:48 Tower kernel: shfs[3090]: segfault at 8000000 ip b746368c sp b6b99008 error 4 in libc-2.11.1.so[b73ed000+15c000]
Mar 23 19:36:48 Tower logger: rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1042) [sender=3.0.7]
Mar 23 19:36:48 Tower logger: /usr/local/sbin/mover: line 44:  3197 Killed                  find "./$Share" -depth \( \( -type f ! -exec fuser -s {} \; \) -o \( -type d -empty \) \) -print -exec rsync -i -dIWRpEAXogt --numeric-ids --inplace {} /mnt/user0/ \; -delete
Mar 23 19:36:48 Tower logger: skipping Kids TV Shows/
Mar 23 19:36:48 Tower logger: skipping Movies/
Mar 23 19:36:48 Tower logger: skipping NZBDrop/
Mar 23 19:36:48 Tower logger: skipping TV Shows/
Mar 23 19:36:48 Tower logger: skipping Test Movies/
Mar 23 19:36:48 Tower logger: skipping iDownloads/
Mar 23 19:36:48 Tower logger: mover finished
Mar 23 19:36:48 Tower kernel: BUG: unable to handle kernel paging request at 6c617465
Mar 23 19:36:48 Tower kernel: IP: [<c1098dd8>] d_set_d_op+0x59/0x89
Mar 23 19:36:48 Tower kernel: *pdpt = 000000002ab9c001 *pde = 0000000000000000
Mar 23 19:36:48 Tower kernel: Oops: 0000 [#1] SMP
Mar 23 19:36:48 Tower kernel: Modules linked in: md_mod xor vmxnet(O) vsock(O) vmsync(O) vmhgfs(O) vmci(O) vmblock(O) ata_piix sg coretemp hwmon mptsas mptscsih vmxnet3 mptbase i2c_piix4 i2c_core piix mpt2sas scsi_transport_sas raid_class [last unloaded: md_mod]
Mar 23 19:36:48 Tower kernel:
Mar 23 19:36:48 Tower kernel: Pid: 3197, comm: find Tainted: G           O 3.4.36-unRAID #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform
Mar 23 19:36:48 Tower kernel: EIP: 0060:[<c1098dd8>] EFLAGS: 00210202 CPU: 0
Mar 23 19:36:48 Tower kernel: EIP is at d_set_d_op+0x59/0x89
Mar 23 19:36:48 Tower kernel: EAX: e9a99600 EBX: e9a99600 ECX: f12fd000 EDX: 6c617461
Mar 23 19:36:48 Tower kernel: ESI: 6c617461 EDI: e9a99641 EBP: ea43bda4 ESP: ea43bd9c

Message from syslogd@Tower at Sat Mar 23 19:36:48 2013 ...
Tower kernel: Process find (pid: 3197, ti=ea43a000 task=f1660360 task.ti=ea43a000)
Mar 23 19:36:48 Tower kernel:  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Mar 23 19:36:48 Tower kernel: CR0: 8005003b CR2: 6c617465 CR3: 2a445000 CR4: 000007f0
Mar 23 19:36:48 Tower kernel: DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
Mar 23 19:36:48 Tower kernel: DR6: ffff0ff0 DR7: 00000400
Mar 23 19:36:48 Tower kernel: Process find (pid: 3197, ti=ea43a000 task=f1660360 task.ti=ea43a000)
Mar 23 19:36:48 Tower kernel: Stack:
Mar 23 19:36:48 Tower kernel:  e9a99600 ea56c01d ea43bdc0 c1098f02 f12fd000 ea43beb8 f0d90b00 ea43bdff
Mar 23 19:36:48 Tower kernel:  ea43beb8 ea43bdd0 c1098f68 00000000 ea43bdff ea43bdf0 c1090f5e ea43be0c
Mar 23 19:36:48 Tower kernel:  ea43beb0 f0d90b00 f0d90b00 ea43be68 ea43beb0 ea43be0c c1090f92 ea43bdff
Mar 23 19:36:48 Tower kernel: Call Trace:
Mar 23 19:36:48 Tower kernel:  [<c1098f02>] __d_alloc+0xfa/0x10a

Message from syslogd@Tower at Sat Mar 23 19:36:48 2013 ...
Tower kernel: Stack:
Mar 23 19:36:48 Tower kernel:  [<c1098f68>] d_alloc+0xf/0x42
Mar 23 19:36:48 Tower kernel:  [<c1090f5e>] lookup_dcache+0x74/0x8e
Mar 23 19:36:48 Tower kernel:  [<c1090f92>] __lookup_hash+0x1a/0x5a
Mar 23 19:36:48 Tower kernel:  [<c10911f2>] do_lookup+0x220/0x253
Mar 23 19:36:48 Tower kernel:  [<c10922e8>] path_lookupat+0xdb/0x4ff
Mar 23 19:36:48 Tower kernel:  [<c1020b08>] ? ptep_set_access_flags+0x38/0x40
Mar 23 19:36:48 Tower kernel:  [<c1075418>] ? do_wp_page+0x2c9/0x5fd
Mar 23 19:36:48 Tower kernel:  [<c10915ba>] ? getname_flags+0x21/0xbd
Mar 23 19:36:48 Tower kernel:  [<c109272a>] do_path_lookup+0x1e/0x50
Mar 23 19:36:48 Tower kernel:  [<c1092903>] user_path_at_empty+0x40/0x6a
Mar 23 19:36:48 Tower kernel:  [<c1076670>] ? handle_mm_fault+0x129/0x138
Mar 23 19:36:48 Tower kernel:  [<c1092947>] user_path_at+0x1a/0x1f
Mar 23 19:36:48 Tower kernel:  [<c108ca69>] vfs_fstatat+0x42/0x68
Mar 23 19:36:48 Tower kernel:  [<c108caac>] sys_fstatat64+0x1d/0x31
Mar 23 19:36:48 Tower kernel:  [<c1025ca6>] ? wait_task_continued+0x11c/0x11c
Mar 23 19:36:48 Tower kernel:  [<c1026d16>] ? sys_waitpid+0x27/0x29
Mar 23 19:36:48 Tower kernel:  [<c134262d>] syscall_call+0x7/0xb
Mar 23 19:36:48 Tower kernel: Code: f6 03 0f 74 1f 80 3d 60 79 47 c1 01 74 16 ba 4d 05 00 00 b8 39 32 3d c1 e8 85 b3 f8 ff c6 05 60 79 47 c1 01 85 f6 89 73 50 74 2c <83> 7e 04 00 74 03 83 0b 01 83 7e 08 00 74 03 83 0b 02 83 3e 00
Mar 23 19:36:48 Tower kernel: EIP: [<c1098dd8>] d_set_d_op+0x59/0x89 SS:ESP 0068:ea43bd9c
Mar 23 19:36:48 Tower kernel: CR2: 000000006c617465
Mar 23 19:36:48 Tower kernel: ---[ end trace ed9070ed2ea69d58 ]---

Message from syslogd@Tower at Sat Mar 23 19:36:48 2013 ...
Tower kernel: Call Trace:

Message from syslogd@Tower at Sat Mar 23 19:36:48 2013 ...
Tower kernel: EIP: [<c1098dd8>] d_set_d_op+0x59/0x89 SS:ESP 0068:ea43bd9c

Message from syslogd@Tower at Sat Mar 23 19:36:48 2013 ...
Tower kernel: Code: f6 03 0f 74 1f 80 3d 60 79 47 c1 01 74 16 ba 4d 05 00 00 b8 39 32 3d c1 e8 85 b3 f8 ff c6 05 60 79 47 c1 01 85 f6 89 73 50 74 2c <83> 7e 04 00 74 03 83 0b 01 83 7e 08 00 74 03 83 0b 02 83 3e 00
Mar 23 19:36:49 Tower kernel: BUG: unable to handle kernel paging request at 4e52645a
Mar 23 19:36:49 Tower kernel: IP: [<c10a60b1>] statfs_by_dentry+0x15/0x48
Mar 23 19:36:49 Tower kernel: *pdpt = 000000003138d001 *pde = 0000000000000000
Mar 23 19:36:49 Tower kernel: Oops: 0000 [#2] SMP
Mar 23 19:36:49 Tower kernel: Modules linked in: md_mod xor vmxnet(O) vsock(O) vmsync(O) vmhgfs(O) vmci(O) vmblock(O) ata_piix sg coretemp hwmon mptsas mptscsih vmxnet3 mptbase i2c_piix4 i2c_core piix mpt2sas scsi_transport_sas raid_class [last unloaded: md_mod]
Mar 23 19:36:49 Tower kernel:
Mar 23 19:36:49 Tower kernel: Pid: 2574, comm: emhttp Tainted: G      D    O 3.4.36-unRAID #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform
Mar 23 19:36:49 Tower kernel: EIP: 0060:[<c10a60b1>] EFLAGS: 00210246 CPU: 1
Mar 23 19:36:49 Tower kernel: EIP is at statfs_by_dentry+0x15/0x48
Mar 23 19:36:49 Tower kernel: EAX: ffffffda EBX: f0c25280 ECX: f0c25280 EDX: 4e52642e
Mar 23 19:36:49 Tower kernel: ESI: f17a1f54 EDI: 00000000 EBP: f17a1f18 ESP: f17a1f0c
Mar 23 19:36:49 Tower kernel:  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Mar 23 19:36:49 Tower kernel: CR0: 8005003b CR2: 4e52645a CR3: 375e3000 CR4: 000007f0
Mar 23 19:36:49 Tower kernel: DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
Mar 23 19:36:49 Tower kernel: DR6: ffff0ff0 DR7: 00000400
Mar 23 19:36:49 Tower kernel: Process emhttp (pid: 2574, ti=f17a0000 task=f0a6b600 task.ti=f17a0000)
Mar 23 19:36:49 Tower kernel: Stack:
Mar 23 19:36:49 Tower kernel:  f17a1f54 f17a1f38 00000000 f17a1f2c c10a60f6 f17a1f38 f17a1f54 00000000
Mar 23 19:36:49 Tower kernel:  f17a1f4c c10a63e0 f17a1f38 f17ad6d0 f0c25280 f17a1f54 00000000 b75fcff4
Mar 23 19:36:49 Tower kernel:  f17a1fac c10a6412 52654973 00001000 1d1bd6d4 00000000 0f4d0259 00000000
Mar 23 19:36:49 Tower kernel: Call Trace:
Mar 23 19:36:49 Tower kernel:  [<c10a60f6>] vfs_statfs+0x12/0x9f
Mar 23 19:36:49 Tower kernel:  [<c10a63e0>] user_statfs+0x31/0x44
Mar 23 19:36:49 Tower kernel:  [<c10a6412>] sys_statfs64+0x1f/0x33
Mar 23 19:36:49 Tower kernel:  [<c134262d>] syscall_call+0x7/0xb
Mar 23 19:36:49 Tower kernel:  [<c1340000>] ? powernowk8_cpu_init+0x222/0x288
Mar 23 19:36:49 Tower kernel: Code: ff ff 89 d8 e8 41 ab fe ff 85 f6 75 ed 83 c4 20 5b 5e 5f 5d c3 90 55 89 e5 57 56 89 d6 53 89 c3 8b 40 54 8b 50 20 b8 da ff ff ff <83> 7a 2c 00 74 28 31 c0 b9 15 00 00 00 89 f7 89 f2 f3 ab 8b 43
Mar 23 19:36:49 Tower kernel: EIP: [<c10a60b1>] statfs_by_dentry+0x15/0x48 SS:ESP 0068:f17a1f0c
Mar 23 19:36:49 Tower kernel: CR2: 000000004e52645a
Mar 23 19:36:49 Tower kernel: ---[ end trace ed9070ed2ea69d59 ]---

Message from syslogd@Tower at Sat Mar 23 19:36:49 2013 ...
Tower kernel: Call Trace:

Message from syslogd@Tower at Sat Mar 23 19:36:49 2013 ...
Tower kernel: Stack:

Message from syslogd@Tower at Sat Mar 23 19:36:49 2013 ...
Tower kernel: EIP: [<c10a60b1>] statfs_by_dentry+0x15/0x48 SS:ESP 0068:f17a1f0c

Message from syslogd@Tower at Sat Mar 23 19:36:49 2013 ...
Tower
Message from syslogd@Tower at Sat Mar 23 19:36:49 2013 ...
Tower kernel: Process emhttp (pid: 2574, ti=f17a0000 task=f0a6b600 task.ti=f17a0000)
kernel: Code: ff ff 89 d8 e8 41 ab fe ff 85 f6 75 ed 83 c4 20 5b 5e 5f 5d c3 90 55 89 e5 57 56 89 d6 53 89 c3 8b 40 54 8b 50 20 b8 da ff ff ff <83> 7a 2c 00 74 28 31 c0 b9 15 00 00 00 89 f7 89 f2 f3 ab 8b 43
Mar 23 19:36:53 Tower kernel: BUG: unable to handle kernel paging request at 4e52645a
Mar 23 19:36:53 Tower kernel: IP: [<c10a60b1>] statfs_by_dentry+0x15/0x48
Mar 23 19:36:53 Tower kernel: *pdpt = 00000000311b7001 *pde = 0000000000000000

Message from syslogd@Tower at Sat Mar 23 19:36:53 2013 ...
Tower kernel: Process vmtoolsd (pid: 1534, ti=f0b1c000 task=f12bc000 task.ti=f0b1c000)

Message from syslogd@Tower at Sat Mar 23 19:36:53 2013 ...
Tower kernel: Stack:
Mar 23 19:36:53 Tower kernel: Oops: 0000 [#3] SMP
Mar 23 19:36:53 Tower kernel: Modules linked in: md_mod xor vmxnet(O) vsock(O) vmsync(O) vmhgfs(O) vmci(O) vmblock(O) ata_piix sg coretemp hwmon mptsas mptscsih vmxnet3 mptbase i2c_piix4 i2c_core piix mpt2sas scsi_transport_sas raid_class [last unloaded: md_mod]
Mar 23 19:36:53 Tower kernel:
Mar 23 19:36:53 Tower kernel: Pid: 1534, comm: vmtoolsd Tainted: G      D    O 3.4.36-unRAID #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform
Mar 23 19:36:53 Tower kernel: EIP: 0060:[<c10a60b1>] EFLAGS: 00010246 CPU: 0
Mar 23 19:36:53 Tower kernel: EIP is at statfs_by_dentry+0x15/0x48
Mar 23 19:36:53 Tower kernel: EAX: ffffffda EBX: f0c25280 ECX: f0c25280 EDX: 4e52642e
Mar 23 19:36:53 Tower kernel: ESI: f0b1df54 EDI: 00000000 EBP: f0b1df18 ESP: f0b1df0c
Mar 23 19:36:53 Tower kernel:  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Mar 23 19:36:53 Tower kernel: CR0: 8005003b CR2: 4e52645a CR3: 30b7c000 CR4: 000007f0
Mar 23 19:36:53 Tower kernel: DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
Mar 23 19:36:53 Tower kernel: DR6: ffff0ff0 DR7: 00000400
Mar 23 19:36:53 Tower kernel: Process vmtoolsd (pid: 1534, ti=f0b1c000 task=f12bc000 task.ti=f0b1c000)
Mar 23 19:36:53 Tower kernel: Stack:
Mar 23 19:36:53 Tower kernel:  f0b1df54 f0b1df38 00000000 f0b1df2c c10a60f6 f0b1df38 f0b1df54 00000000
Mar 23 19:36:53 Tower kernel:  f0b1df4c c10a63e0 f0b1df38 f17ad6d0 f0c25280 f0b1df54 08087408 b7584ff4
Mar 23 19:36:53 Tower kernel:  f0b1dfac c10a6412 52654973 00001000 1d1bd6d4 00000000 0f4d0259 00000000
Mar 23 19:36:53 Tower kernel: Call Trace:
Mar 23 19:36:53 Tower kernel:  [<c10a60f6>] vfs_statfs+0x12/0x9f
Mar 23 19:36:53 Tower kernel:  [<c10a63e0>] user_statfs+0x31/0x44
Mar 23 19:36:53 Tower kernel:  [<c10a6412>] sys_statfs64+0x1f/0x33
Mar 23 19:36:53 Tower kernel:  [<c134262d>] syscall_call+0x7/0xb
Mar 23 19:36:53 Tower kernel: Code: ff ff 89 d8 e8 41 ab fe ff 85 f6 75 ed 83 c4 20 5b 5e 5f 5d c3 90 55 89 e5 57 56 89 d6 53 89 c3 8b 40 54 8b 50 20 b8 da ff ff ff <83> 7a 2c 00 74 28 31 c0 b9 15 00 00 00 89 f7 89 f2 f3 ab 8b 43
Mar 23 19:36:53 Tower kernel: EIP: [<c10a60b1>] statfs_by_dentry+0x15/0x48 SS:ESP 0068:f0b1df0c
Mar 23 19:36:53 Tower kernel: CR2: 000000004e52645a
Mar 23 19:36:53 Tower kernel: ---[ end trace ed9070ed2ea69d5a ]---

Message from syslogd@Tower at Sat Mar 23 19:36:53 2013 ...
Tower kernel: Call Trace:

Message from syslogd@Tower at Sat Mar 23 19:36:53 2013 ...
Tower kernel: Code: ff ff 89 d8 e8 41 ab fe ff 85 f6 75 ed 83 c4 20 5b 5e 5f 5d c3 90 55 89 e5 57 56 89 d6 53 89 c3 8b 40 54 8b 50 20 b8 da ff ff ff <83> 7a 2c 00 74 28 31 c0 b9 15 00 00 00 89 f7 89 f2 f3 ab 8b 43

Message from syslogd@Tower at Sat Mar 23 19:36:53 2013 ...
Tower kernel: EIP: [<c10a60b1>] statfs_by_dentry+0x15/0x48 SS:ESP 0068:f0b1df0c
Mar 23 19:37:07 Tower kernel: BUG: unable to handle kernel paging request at 4e52644a
Mar 23 19:37:07 Tower kernel: IP: [<c108b083>] sync_supers+0x26/0x9f
Mar 23 19:37:07 Tower kernel: *pdpt = 000000002a441001 *pde = 0000000000000000
Mar 23 19:37:07 Tower kernel: Oops: 0000 [#4] SMP

Message from syslogd@Tower at Sat Mar 23 19:37:07 2013 ...
Tower kernel: Process sync_supers (pid: 158, ti=f1e4e000 task=f1e2ef40 task.ti=f1e4e000)
Mar 23 19:37:07 Tower kernel: Modules linked in: md_mod xor vmxnet(O) vsock(O) vmsync(O) vmhgfs(O) vmci(O) vmblock(O) ata_piix sg coretemp hwmon mptsas mptscsih vmxnet3 mptbase i2c_piix4 i2c_core piix mpt2sas scsi_transport_sas raid_class [last unloaded: md_mod]
Mar 23 19:37:07 Tower kernel:
Mar 23 19:37:07 Tower kernel: Pid: 158, comm: sync_supers Tainted: G      D    O 3.4.36-unRAID #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform
Mar 23 19:37:07 Tower kernel: EIP: 0060:[<c108b083>] EFLAGS: 00010202 CPU: 0
Mar 23 19:37:07 Tower kernel: EIP is at sync_supers+0x26/0x9f
Mar 23 19:37:07 Tower kernel: EAX: 4e52642e EBX: f12fd000 ECX: 514e3c17 EDX: 00000017
Mar 23 19:37:07 Tower kernel: ESI: f1f22000 EDI: f1f2203c EBP: f1e4ffa8 ESP: f1e4ff9c
Mar 23 19:37:07 Tower kernel:  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Mar 23 19:37:07 Tower kernel: CR0: 8005003b CR2: 4e52644a CR3: 2a50e000 CR4: 000007f0
Mar 23 19:37:07 Tower kernel: DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
Mar 23 19:37:07 Tower kernel: DR6: ffff0ff0 DR7: 00000400
Mar 23 19:37:07 Tower kernel: Process sync_supers (pid: 158, ti=f1e4e000 task=f1e2ef40 task.ti=f1e4e000)
Mar 23 19:37:07 Tower kernel: Stack:
Mar 23 19:37:07 Tower kernel:  f1e2ef40 00000000 c10705e2 f1e4ffb8 c1070617 00000000 f1c9ff30 f1e4ffe4
Mar 23 19:37:07 Tower kernel:  c1037794 00000000 00000000 00000000 00000000 f1e4ffd0 f1e4ffd0 00000000
Mar 23 19:37:07 Tower kernel:  c103772d f1c9ff30 00000000 c1343376 00000000 00000000 00000000 00000000
Mar 23 19:37:07 Tower kernel: Call Trace:
Mar 23 19:37:07 Tower kernel:  [<c10705e2>] ? bdi_sched_wait+0xc/0xc
Mar 23 19:37:07 Tower kernel:  [<c1070617>] bdi_sync_supers+0x35/0x44
Mar 23 19:37:07 Tower kernel:  [<c1037794>] kthread+0x67/0x6c
Mar 23 19:37:07 Tower kernel:  [<c103772d>] ? kthread_freezable_should_stop+0x49/0x49
Mar 23 19:37:07 Tower kernel:  [<c1343376>] kernel_thread_helper+0x6/0xd
Mar 23 19:37:07 Tower kernel: Code: 5b 5e 5f 5d c3 55 b8 08 dc 4f c1 8
Message from syslogd@Tower at Sat Mar 23 19:37:07 2013 ...
Tower 9 e5 57 56 31 f6 53 e8 1c 73 2b 00 8b 1d d8 b1 45 c1 eb 66 83 bb e0 00 00 00 00 74 5b 8b 43 20 <83> 78 1c 00 74 52 80 7b 0c 00 74 4c ff 43 60 80 05 08 dc 4f c1
kernel: Code: 5b 5e 5f 5d c3 55 b8 08 dc 4f c1 89 e5 57 56 31 f6 53 e8 1c 73 2b 00 8b 1d d8 b1 45 c1 eb 66 83 bb e0 00 00 00 00 74 5b 8b 43 20 <83> 78 1c 00 74 52 80 7b 0c 00 74 4c ff 43 60 80 05 08 dc 4f c1
Mar 23 19:37:07 Tower kernel: EIP: [<c108b083>] sync_supers+0x26/0x9f SS:ESP 0068:f1e4ff9c
Mar 23 19:37:07 Tower kernel: CR2: 000000004e52644a
Mar 23 19:37:07 Tower kernel: ---[ end trace ed9070ed2ea69d5b ]---

Message from syslogd@Tower at Sat Mar 23 19:37:07 2013 ...
Tower kernel: EIP: [<c108b083>] sync_supers+0x26/0x9f SS:ESP 0068:f1e4ff9c

Message from syslogd@Tower at Sat Mar 23 19:37:07 2013 ...
Tower kernel: Call Trace:

Message from syslogd@Tower at Sat Mar 23 19:37:07 2013 ...
Tower kernel: Stack:

 

I should mention all those other shares had data in them to move "movies" "tv shows" "kids tv shows", but log logs clearly they where all skipped.

 

I am seeing this, though not with the mover.

Reboot after mover crash.

 

I have asked this before, no answer from Tom, The question was why are there so many reads and several writes to each and every disk in the array when you first start the array including the parity drive, when no clients are attached. THis reading and writing last for about 10-15 mins. Any and every reboot of unRAID.

 

I'm pretty sure I've seen the same behaviour in previous RC's - not related to mover crashing though. Is this not expected behaviour for unRAID?

 

I'm not home at the moment, but can test and confirm when I return if it would help.

 

Sent from my Nexus 7 using Tapatalk HD

 

The new list of FTP users requires a space as a seperator whereas the list of excluded/included disks requires a comma as a seperator. Is it really a different seperator or can I use both (comma/space) in both fiels?

 

webGui: for 'FTP user(s)', permit multiple usernames separated by spaces

 

For example, to restrict a share to using only disk1, disk2, and disk3, you would set Included disk(s) to disk1,disk2,disk3.

 

Thanks

Harald

 

The question was why are there so many reads and several writes to each and every disk in the array when you first start the array including the parity drive, when no clients are attached. THis reading and writing last for about 10-15 mins. Any and every reboot of unRAID.

 

Are you using cache_dirs?

The question was why are there so many reads and several writes to each and every disk in the array when you first start the array including the parity drive, when no clients are attached. THis reading and writing last for about 10-15 mins. Any and every reboot of unRAID.

 

Are you using cache_dirs?

 

cache_dirs may explain reads if it's being used, but wouldn't be any reason for it to write to the disks, would it?

 

Sent from my Nexus 7 using Tapatalk HD

Upgraded from RC11 to RC12a (unRAID in ESXi 5.1).  Everything seems to be in order so far.  Running parity check @ 118MB/s.

 

John

I skipped rc12 since dirtysanchez reported network problem with our mobo.

 

I can report that rc12a is working fine for me.

 

Ok, found something i think is very interesting.

 

After i tried rc12 with sf 1.0.5 allready on the system i saw the parity check speeds were horrible (40-50MB/s) compared to rc5/sf 1.0.5 (160MB/s)

So i re-installed rc5 and guess what... the SAME horrible speeds! This baffled me.

So i removed SimpleFeatures, and rebooted... (rc5) and speed was back (160MB/s).

I re-installed SF 1.0.5 using installplg and... the speed stayed up high.

 

So, i guess we need an addition to the up- or downgrade procedure, that states that SimpleFeatures should be REMOVED and RE-INSTALLED after an up - or downgrade.

Keeping SF on the system f*cks things up after upgrading. You HAVE to re-install it. Will place this warning at the Sf topic as well.

 

So i tested a bit more. I removed Simplefeatures again, and replaced rc5 with rc12 and rebooted.

Now i have NO simplefeatures, just unmenu and some plugins (sab/sick/dropbox/slimserver).

Parity speeds are now at about 150MB/s... that is still a little bit less then under rc5 (160MB/s) but acceptable.

This speed can be seen at the stock webgui and in unmenu.

 

Guess what. I've installed SimpleFeatures again (1.0.5) and the parity speed goes down to about 90 - 100MB/s... if you actually watch it IN simplefeatures gui.

Once you close the simplefeatures webpage, and go back to unmenu, you will see the parity speed increase to 150MB/s again...

Using the latest SimpleFeatures (1.0.11) is even worse, it basically stops the parity check with speeds from 20-30MB/s, which is unworkable.

 

Basically this means that SimpleFeatures has a huge negative effect on the performance of unraid and should be avoided.

It would be very interesting to find out why this is, and if it can be solved.

 

I know SF is not part of Limetech, but i think a lot of people use SF together with unraid and even regard it as one and the same.

At least Limetech should take a look at this and warn people about the possible sideeffects of SF, and it should be made clear that IF you are using SF, you should re-install it after an up- or downgrade.

 

So, my apologies to Limetech, rc12 is not as bad as i thought, the real problem is SimpleFeatures...

 

Tested this awhile ago after it was reported. Just tested again. SF causes no slow downs for me, but I get slow speeds regardless.

 

Completely stock rc12a, still ~55MB/s parity syncs when I get 120MB/s on beta12a.

Installed rc12a and everything is now working as expected.  Thanks Tom!

Thanks,

 

AFP places the .AppleDesktop\.volinfo and .AppleDouble\.parent per AFP share only on one disk and doesnt change often and not a single one changed today. The db for the apple shares I don't even store on the array or cache drive, I have it on a separate disk off unRAID array/cache drive. Storing in on the array cause a full rebuilt every reboot otherwise, and is unacceptable. So I agree AFP is reading ALOT of something and writes little something (ACL, extended attribute, don't know) per the web gui stats, but nothing clear as to what.

 

Memtest'ed my build 2 years ago for a week straight (ECC fully buffered) passed with flying colors.

850w gold PSU over kill for what I have.

 

Thanks for the suggestion prostuff1

 

Weird, I'm not seeing this behavior.

Do you mean, with AFP enabled when you first start the array, your not seeing the numerous reads and several writes to each disk that is apart of an AFP share? (as well as the parity drive).

Reboot after mover crash.

 

I have asked this before, no answer from Tom, The question was why are there so many reads and several writes to each and every disk in the array when you first start the array including the parity drive, when no clients are attached. THis reading and writing last for about 10-15 mins. Any and every reboot of unRAID.

 

Upon this reboot, and starting the array I did not wait 10-15 minutes for these reads and writes to subside, and launched mover manually.

 

This time not only did mover crashe but a Kernel oops, cant get a syslog, unRAID is frozen, grabbed what was being spit out via a console session:

 

Mar 23 19:36:48 Tower emhttp: shcmd (132): /usr/local/sbin/mover |& logger &
Mar 23 19:36:48 Tower logger: mover started
Mar 23 19:36:48 Tower logger: skipping Backup/
Mar 23 19:36:48 Tower logger: skipping Handbrake/
Mar 23 19:36:48 Tower logger: moving Kids Movies/
Mar 23 19:36:48 Tower logger: ./Kids Movies/Wreck-It Ralph (2012) BRu/Wreck-It.Ralph.2012.PROPER.BluRay.720p.DTS.x264-DON.nfo
Mar 23 19:36:48 Tower logger: .d..t...... ./
Mar 23 19:36:48 Tower logger: rsync: get_xattr_names: llistxattr("Kids Movies",1024) failed: Software caused connection abort (103)
Mar 23 19:36:48 Tower logger: .d..t.....x Kids Movies/
Mar 23 19:36:48 Tower logger: rsync: get_acl: sys_acl_get_file(Kids Movies, ACL_TYPE_ACCESS): Transport endpoint is not connected (107)
Mar 23 19:36:48 Tower logger: rsync: failed to set times on "/mnt/user0/Kids Movies": Transport endpoint is not connected (107)
Mar 23 19:36:48 Tower logger: cd+++++++++ Kids Movies/Wreck-It Ralph (2012) BRu/
Mar 23 19:36:48 Tower logger: rsync: recv_generator: mkdir "/mnt/user0/Kids Movies/Wreck-It Ralph (2012) BRu" failed: Transport endpoint is not connected (107)
Mar 23 19:36:48 Tower logger: *** Skipping any contents from this failed directory ***
Mar 23 19:36:48 Tower logger: rsync: get_acl: sys_acl_get_file(Kids Movies, ACL_TYPE_ACCESS): Transport endpoint is not connected (107)
Mar 23 19:36:48 Tower logger: rsync: get_xattr_names: llistxattr("Kids Movies",1024) failed: Transport endpoint is not connected (107)
Mar 23 19:36:48 Tower logger: rsync: failed to set times on "/mnt/user0/Kids Movies": Transport endpoint is not connected (107)
Mar 23 19:36:48 Tower kernel: shfs[3090]: segfault at 8000000 ip b746368c sp b6b99008 error 4 in libc-2.11.1.so[b73ed000+15c000]
Mar 23 19:36:48 Tower logger: rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1042) [sender=3.0.7]
Mar 23 19:36:48 Tower logger: /usr/local/sbin/mover: line 44:  3197 Killed                  find "./$Share" -depth \( \( -type f ! -exec fuser -s {} \; \) -o \( -type d -empty \) \) -print -exec rsync -i -dIWRpEAXogt --numeric-ids --inplace {} /mnt/user0/ \; -delete
Mar 23 19:36:48 Tower logger: skipping Kids TV Shows/
Mar 23 19:36:48 Tower logger: skipping Movies/
Mar 23 19:36:48 Tower logger: skipping NZBDrop/
Mar 23 19:36:48 Tower logger: skipping TV Shows/
Mar 23 19:36:48 Tower logger: skipping Test Movies/
Mar 23 19:36:48 Tower logger: skipping iDownloads/
Mar 23 19:36:48 Tower logger: mover finished
Mar 23 19:36:48 Tower kernel: BUG: unable to handle kernel paging request at 6c617465
Mar 23 19:36:48 Tower kernel: IP: [<c1098dd8>] d_set_d_op+0x59/0x89
Mar 23 19:36:48 Tower kernel: *pdpt = 000000002ab9c001 *pde = 0000000000000000
Mar 23 19:36:48 Tower kernel: Oops: 0000 [#1] SMP
Mar 23 19:36:48 Tower kernel: Modules linked in: md_mod xor vmxnet(O) vsock(O) vmsync(O) vmhgfs(O) vmci(O) vmblock(O) ata_piix sg coretemp hwmon mptsas mptscsih vmxnet3 mptbase i2c_piix4 i2c_core piix mpt2sas scsi_transport_sas raid_class [last unloaded: md_mod]
Mar 23 19:36:48 Tower kernel:
Mar 23 19:36:48 Tower kernel: Pid: 3197, comm: find Tainted: G           O 3.4.36-unRAID #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform
Mar 23 19:36:48 Tower kernel: EIP: 0060:[<c1098dd8>] EFLAGS: 00210202 CPU: 0
Mar 23 19:36:48 Tower kernel: EIP is at d_set_d_op+0x59/0x89
Mar 23 19:36:48 Tower kernel: EAX: e9a99600 EBX: e9a99600 ECX: f12fd000 EDX: 6c617461
Mar 23 19:36:48 Tower kernel: ESI: 6c617461 EDI: e9a99641 EBP: ea43bda4 ESP: ea43bd9c

Message from syslogd@Tower at Sat Mar 23 19:36:48 2013 ...
Tower kernel: Process find (pid: 3197, ti=ea43a000 task=f1660360 task.ti=ea43a000)
Mar 23 19:36:48 Tower kernel:  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Mar 23 19:36:48 Tower kernel: CR0: 8005003b CR2: 6c617465 CR3: 2a445000 CR4: 000007f0
Mar 23 19:36:48 Tower kernel: DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
Mar 23 19:36:48 Tower kernel: DR6: ffff0ff0 DR7: 00000400
Mar 23 19:36:48 Tower kernel: Process find (pid: 3197, ti=ea43a000 task=f1660360 task.ti=ea43a000)
Mar 23 19:36:48 Tower kernel: Stack:
Mar 23 19:36:48 Tower kernel:  e9a99600 ea56c01d ea43bdc0 c1098f02 f12fd000 ea43beb8 f0d90b00 ea43bdff
Mar 23 19:36:48 Tower kernel:  ea43beb8 ea43bdd0 c1098f68 00000000 ea43bdff ea43bdf0 c1090f5e ea43be0c
Mar 23 19:36:48 Tower kernel:  ea43beb0 f0d90b00 f0d90b00 ea43be68 ea43beb0 ea43be0c c1090f92 ea43bdff
Mar 23 19:36:48 Tower kernel: Call Trace:
Mar 23 19:36:48 Tower kernel:  [<c1098f02>] __d_alloc+0xfa/0x10a

Message from syslogd@Tower at Sat Mar 23 19:36:48 2013 ...
Tower kernel: Stack:
Mar 23 19:36:48 Tower kernel:  [<c1098f68>] d_alloc+0xf/0x42
Mar 23 19:36:48 Tower kernel:  [<c1090f5e>] lookup_dcache+0x74/0x8e
Mar 23 19:36:48 Tower kernel:  [<c1090f92>] __lookup_hash+0x1a/0x5a
Mar 23 19:36:48 Tower kernel:  [<c10911f2>] do_lookup+0x220/0x253
Mar 23 19:36:48 Tower kernel:  [<c10922e8>] path_lookupat+0xdb/0x4ff
Mar 23 19:36:48 Tower kernel:  [<c1020b08>] ? ptep_set_access_flags+0x38/0x40
Mar 23 19:36:48 Tower kernel:  [<c1075418>] ? do_wp_page+0x2c9/0x5fd
Mar 23 19:36:48 Tower kernel:  [<c10915ba>] ? getname_flags+0x21/0xbd
Mar 23 19:36:48 Tower kernel:  [<c109272a>] do_path_lookup+0x1e/0x50
Mar 23 19:36:48 Tower kernel:  [<c1092903>] user_path_at_empty+0x40/0x6a
Mar 23 19:36:48 Tower kernel:  [<c1076670>] ? handle_mm_fault+0x129/0x138
Mar 23 19:36:48 Tower kernel:  [<c1092947>] user_path_at+0x1a/0x1f
Mar 23 19:36:48 Tower kernel:  [<c108ca69>] vfs_fstatat+0x42/0x68
Mar 23 19:36:48 Tower kernel:  [<c108caac>] sys_fstatat64+0x1d/0x31
Mar 23 19:36:48 Tower kernel:  [<c1025ca6>] ? wait_task_continued+0x11c/0x11c
Mar 23 19:36:48 Tower kernel:  [<c1026d16>] ? sys_waitpid+0x27/0x29
Mar 23 19:36:48 Tower kernel:  [<c134262d>] syscall_call+0x7/0xb
Mar 23 19:36:48 Tower kernel: Code: f6 03 0f 74 1f 80 3d 60 79 47 c1 01 74 16 ba 4d 05 00 00 b8 39 32 3d c1 e8 85 b3 f8 ff c6 05 60 79 47 c1 01 85 f6 89 73 50 74 2c <83> 7e 04 00 74 03 83 0b 01 83 7e 08 00 74 03 83 0b 02 83 3e 00
Mar 23 19:36:48 Tower kernel: EIP: [<c1098dd8>] d_set_d_op+0x59/0x89 SS:ESP 0068:ea43bd9c
Mar 23 19:36:48 Tower kernel: CR2: 000000006c617465
Mar 23 19:36:48 Tower kernel: ---[ end trace ed9070ed2ea69d58 ]---

Message from syslogd@Tower at Sat Mar 23 19:36:48 2013 ...
Tower kernel: Call Trace:

Message from syslogd@Tower at Sat Mar 23 19:36:48 2013 ...
Tower kernel: EIP: [<c1098dd8>] d_set_d_op+0x59/0x89 SS:ESP 0068:ea43bd9c

Message from syslogd@Tower at Sat Mar 23 19:36:48 2013 ...
Tower kernel: Code: f6 03 0f 74 1f 80 3d 60 79 47 c1 01 74 16 ba 4d 05 00 00 b8 39 32 3d c1 e8 85 b3 f8 ff c6 05 60 79 47 c1 01 85 f6 89 73 50 74 2c <83> 7e 04 00 74 03 83 0b 01 83 7e 08 00 74 03 83 0b 02 83 3e 00
Mar 23 19:36:49 Tower kernel: BUG: unable to handle kernel paging request at 4e52645a
Mar 23 19:36:49 Tower kernel: IP: [<c10a60b1>] statfs_by_dentry+0x15/0x48
Mar 23 19:36:49 Tower kernel: *pdpt = 000000003138d001 *pde = 0000000000000000
Mar 23 19:36:49 Tower kernel: Oops: 0000 [#2] SMP
Mar 23 19:36:49 Tower kernel: Modules linked in: md_mod xor vmxnet(O) vsock(O) vmsync(O) vmhgfs(O) vmci(O) vmblock(O) ata_piix sg coretemp hwmon mptsas mptscsih vmxnet3 mptbase i2c_piix4 i2c_core piix mpt2sas scsi_transport_sas raid_class [last unloaded: md_mod]
Mar 23 19:36:49 Tower kernel:
Mar 23 19:36:49 Tower kernel: Pid: 2574, comm: emhttp Tainted: G      D    O 3.4.36-unRAID #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform
Mar 23 19:36:49 Tower kernel: EIP: 0060:[<c10a60b1>] EFLAGS: 00210246 CPU: 1
Mar 23 19:36:49 Tower kernel: EIP is at statfs_by_dentry+0x15/0x48
Mar 23 19:36:49 Tower kernel: EAX: ffffffda EBX: f0c25280 ECX: f0c25280 EDX: 4e52642e
Mar 23 19:36:49 Tower kernel: ESI: f17a1f54 EDI: 00000000 EBP: f17a1f18 ESP: f17a1f0c
Mar 23 19:36:49 Tower kernel:  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Mar 23 19:36:49 Tower kernel: CR0: 8005003b CR2: 4e52645a CR3: 375e3000 CR4: 000007f0
Mar 23 19:36:49 Tower kernel: DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
Mar 23 19:36:49 Tower kernel: DR6: ffff0ff0 DR7: 00000400
Mar 23 19:36:49 Tower kernel: Process emhttp (pid: 2574, ti=f17a0000 task=f0a6b600 task.ti=f17a0000)
Mar 23 19:36:49 Tower kernel: Stack:
Mar 23 19:36:49 Tower kernel:  f17a1f54 f17a1f38 00000000 f17a1f2c c10a60f6 f17a1f38 f17a1f54 00000000
Mar 23 19:36:49 Tower kernel:  f17a1f4c c10a63e0 f17a1f38 f17ad6d0 f0c25280 f17a1f54 00000000 b75fcff4
Mar 23 19:36:49 Tower kernel:  f17a1fac c10a6412 52654973 00001000 1d1bd6d4 00000000 0f4d0259 00000000
Mar 23 19:36:49 Tower kernel: Call Trace:
Mar 23 19:36:49 Tower kernel:  [<c10a60f6>] vfs_statfs+0x12/0x9f
Mar 23 19:36:49 Tower kernel:  [<c10a63e0>] user_statfs+0x31/0x44
Mar 23 19:36:49 Tower kernel:  [<c10a6412>] sys_statfs64+0x1f/0x33
Mar 23 19:36:49 Tower kernel:  [<c134262d>] syscall_call+0x7/0xb
Mar 23 19:36:49 Tower kernel:  [<c1340000>] ? powernowk8_cpu_init+0x222/0x288
Mar 23 19:36:49 Tower kernel: Code: ff ff 89 d8 e8 41 ab fe ff 85 f6 75 ed 83 c4 20 5b 5e 5f 5d c3 90 55 89 e5 57 56 89 d6 53 89 c3 8b 40 54 8b 50 20 b8 da ff ff ff <83> 7a 2c 00 74 28 31 c0 b9 15 00 00 00 89 f7 89 f2 f3 ab 8b 43
Mar 23 19:36:49 Tower kernel: EIP: [<c10a60b1>] statfs_by_dentry+0x15/0x48 SS:ESP 0068:f17a1f0c
Mar 23 19:36:49 Tower kernel: CR2: 000000004e52645a
Mar 23 19:36:49 Tower kernel: ---[ end trace ed9070ed2ea69d59 ]---

Message from syslogd@Tower at Sat Mar 23 19:36:49 2013 ...
Tower kernel: Call Trace:

Message from syslogd@Tower at Sat Mar 23 19:36:49 2013 ...
Tower kernel: Stack:

Message from syslogd@Tower at Sat Mar 23 19:36:49 2013 ...
Tower kernel: EIP: [<c10a60b1>] statfs_by_dentry+0x15/0x48 SS:ESP 0068:f17a1f0c

Message from syslogd@Tower at Sat Mar 23 19:36:49 2013 ...
Tower
Message from syslogd@Tower at Sat Mar 23 19:36:49 2013 ...
Tower kernel: Process emhttp (pid: 2574, ti=f17a0000 task=f0a6b600 task.ti=f17a0000)
kernel: Code: ff ff 89 d8 e8 41 ab fe ff 85 f6 75 ed 83 c4 20 5b 5e 5f 5d c3 90 55 89 e5 57 56 89 d6 53 89 c3 8b 40 54 8b 50 20 b8 da ff ff ff <83> 7a 2c 00 74 28 31 c0 b9 15 00 00 00 89 f7 89 f2 f3 ab 8b 43
Mar 23 19:36:53 Tower kernel: BUG: unable to handle kernel paging request at 4e52645a
Mar 23 19:36:53 Tower kernel: IP: [<c10a60b1>] statfs_by_dentry+0x15/0x48
Mar 23 19:36:53 Tower kernel: *pdpt = 00000000311b7001 *pde = 0000000000000000

Message from syslogd@Tower at Sat Mar 23 19:36:53 2013 ...
Tower kernel: Process vmtoolsd (pid: 1534, ti=f0b1c000 task=f12bc000 task.ti=f0b1c000)

Message from syslogd@Tower at Sat Mar 23 19:36:53 2013 ...
Tower kernel: Stack:
Mar 23 19:36:53 Tower kernel: Oops: 0000 [#3] SMP
Mar 23 19:36:53 Tower kernel: Modules linked in: md_mod xor vmxnet(O) vsock(O) vmsync(O) vmhgfs(O) vmci(O) vmblock(O) ata_piix sg coretemp hwmon mptsas mptscsih vmxnet3 mptbase i2c_piix4 i2c_core piix mpt2sas scsi_transport_sas raid_class [last unloaded: md_mod]
Mar 23 19:36:53 Tower kernel:
Mar 23 19:36:53 Tower kernel: Pid: 1534, comm: vmtoolsd Tainted: G      D    O 3.4.36-unRAID #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform
Mar 23 19:36:53 Tower kernel: EIP: 0060:[<c10a60b1>] EFLAGS: 00010246 CPU: 0
Mar 23 19:36:53 Tower kernel: EIP is at statfs_by_dentry+0x15/0x48
Mar 23 19:36:53 Tower kernel: EAX: ffffffda EBX: f0c25280 ECX: f0c25280 EDX: 4e52642e
Mar 23 19:36:53 Tower kernel: ESI: f0b1df54 EDI: 00000000 EBP: f0b1df18 ESP: f0b1df0c
Mar 23 19:36:53 Tower kernel:  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Mar 23 19:36:53 Tower kernel: CR0: 8005003b CR2: 4e52645a CR3: 30b7c000 CR4: 000007f0
Mar 23 19:36:53 Tower kernel: DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
Mar 23 19:36:53 Tower kernel: DR6: ffff0ff0 DR7: 00000400
Mar 23 19:36:53 Tower kernel: Process vmtoolsd (pid: 1534, ti=f0b1c000 task=f12bc000 task.ti=f0b1c000)
Mar 23 19:36:53 Tower kernel: Stack:
Mar 23 19:36:53 Tower kernel:  f0b1df54 f0b1df38 00000000 f0b1df2c c10a60f6 f0b1df38 f0b1df54 00000000
Mar 23 19:36:53 Tower kernel:  f0b1df4c c10a63e0 f0b1df38 f17ad6d0 f0c25280 f0b1df54 08087408 b7584ff4
Mar 23 19:36:53 Tower kernel:  f0b1dfac c10a6412 52654973 00001000 1d1bd6d4 00000000 0f4d0259 00000000
Mar 23 19:36:53 Tower kernel: Call Trace:
Mar 23 19:36:53 Tower kernel:  [<c10a60f6>] vfs_statfs+0x12/0x9f
Mar 23 19:36:53 Tower kernel:  [<c10a63e0>] user_statfs+0x31/0x44
Mar 23 19:36:53 Tower kernel:  [<c10a6412>] sys_statfs64+0x1f/0x33
Mar 23 19:36:53 Tower kernel:  [<c134262d>] syscall_call+0x7/0xb
Mar 23 19:36:53 Tower kernel: Code: ff ff 89 d8 e8 41 ab fe ff 85 f6 75 ed 83 c4 20 5b 5e 5f 5d c3 90 55 89 e5 57 56 89 d6 53 89 c3 8b 40 54 8b 50 20 b8 da ff ff ff <83> 7a 2c 00 74 28 31 c0 b9 15 00 00 00 89 f7 89 f2 f3 ab 8b 43
Mar 23 19:36:53 Tower kernel: EIP: [<c10a60b1>] statfs_by_dentry+0x15/0x48 SS:ESP 0068:f0b1df0c
Mar 23 19:36:53 Tower kernel: CR2: 000000004e52645a
Mar 23 19:36:53 Tower kernel: ---[ end trace ed9070ed2ea69d5a ]---

Message from syslogd@Tower at Sat Mar 23 19:36:53 2013 ...
Tower kernel: Call Trace:

Message from syslogd@Tower at Sat Mar 23 19:36:53 2013 ...
Tower kernel: Code: ff ff 89 d8 e8 41 ab fe ff 85 f6 75 ed 83 c4 20 5b 5e 5f 5d c3 90 55 89 e5 57 56 89 d6 53 89 c3 8b 40 54 8b 50 20 b8 da ff ff ff <83> 7a 2c 00 74 28 31 c0 b9 15 00 00 00 89 f7 89 f2 f3 ab 8b 43

Message from syslogd@Tower at Sat Mar 23 19:36:53 2013 ...
Tower kernel: EIP: [<c10a60b1>] statfs_by_dentry+0x15/0x48 SS:ESP 0068:f0b1df0c
Mar 23 19:37:07 Tower kernel: BUG: unable to handle kernel paging request at 4e52644a
Mar 23 19:37:07 Tower kernel: IP: [<c108b083>] sync_supers+0x26/0x9f
Mar 23 19:37:07 Tower kernel: *pdpt = 000000002a441001 *pde = 0000000000000000
Mar 23 19:37:07 Tower kernel: Oops: 0000 [#4] SMP

Message from syslogd@Tower at Sat Mar 23 19:37:07 2013 ...
Tower kernel: Process sync_supers (pid: 158, ti=f1e4e000 task=f1e2ef40 task.ti=f1e4e000)
Mar 23 19:37:07 Tower kernel: Modules linked in: md_mod xor vmxnet(O) vsock(O) vmsync(O) vmhgfs(O) vmci(O) vmblock(O) ata_piix sg coretemp hwmon mptsas mptscsih vmxnet3 mptbase i2c_piix4 i2c_core piix mpt2sas scsi_transport_sas raid_class [last unloaded: md_mod]
Mar 23 19:37:07 Tower kernel:
Mar 23 19:37:07 Tower kernel: Pid: 158, comm: sync_supers Tainted: G      D    O 3.4.36-unRAID #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform
Mar 23 19:37:07 Tower kernel: EIP: 0060:[<c108b083>] EFLAGS: 00010202 CPU: 0
Mar 23 19:37:07 Tower kernel: EIP is at sync_supers+0x26/0x9f
Mar 23 19:37:07 Tower kernel: EAX: 4e52642e EBX: f12fd000 ECX: 514e3c17 EDX: 00000017
Mar 23 19:37:07 Tower kernel: ESI: f1f22000 EDI: f1f2203c EBP: f1e4ffa8 ESP: f1e4ff9c
Mar 23 19:37:07 Tower kernel:  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Mar 23 19:37:07 Tower kernel: CR0: 8005003b CR2: 4e52644a CR3: 2a50e000 CR4: 000007f0
Mar 23 19:37:07 Tower kernel: DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
Mar 23 19:37:07 Tower kernel: DR6: ffff0ff0 DR7: 00000400
Mar 23 19:37:07 Tower kernel: Process sync_supers (pid: 158, ti=f1e4e000 task=f1e2ef40 task.ti=f1e4e000)
Mar 23 19:37:07 Tower kernel: Stack:
Mar 23 19:37:07 Tower kernel:  f1e2ef40 00000000 c10705e2 f1e4ffb8 c1070617 00000000 f1c9ff30 f1e4ffe4
Mar 23 19:37:07 Tower kernel:  c1037794 00000000 00000000 00000000 00000000 f1e4ffd0 f1e4ffd0 00000000
Mar 23 19:37:07 Tower kernel:  c103772d f1c9ff30 00000000 c1343376 00000000 00000000 00000000 00000000
Mar 23 19:37:07 Tower kernel: Call Trace:
Mar 23 19:37:07 Tower kernel:  [<c10705e2>] ? bdi_sched_wait+0xc/0xc
Mar 23 19:37:07 Tower kernel:  [<c1070617>] bdi_sync_supers+0x35/0x44
Mar 23 19:37:07 Tower kernel:  [<c1037794>] kthread+0x67/0x6c
Mar 23 19:37:07 Tower kernel:  [<c103772d>] ? kthread_freezable_should_stop+0x49/0x49
Mar 23 19:37:07 Tower kernel:  [<c1343376>] kernel_thread_helper+0x6/0xd
Mar 23 19:37:07 Tower kernel: Code: 5b 5e 5f 5d c3 55 b8 08 dc 4f c1 8
Message from syslogd@Tower at Sat Mar 23 19:37:07 2013 ...
Tower 9 e5 57 56 31 f6 53 e8 1c 73 2b 00 8b 1d d8 b1 45 c1 eb 66 83 bb e0 00 00 00 00 74 5b 8b 43 20 <83> 78 1c 00 74 52 80 7b 0c 00 74 4c ff 43 60 80 05 08 dc 4f c1
kernel: Code: 5b 5e 5f 5d c3 55 b8 08 dc 4f c1 89 e5 57 56 31 f6 53 e8 1c 73 2b 00 8b 1d d8 b1 45 c1 eb 66 83 bb e0 00 00 00 00 74 5b 8b 43 20 <83> 78 1c 00 74 52 80 7b 0c 00 74 4c ff 43 60 80 05 08 dc 4f c1
Mar 23 19:37:07 Tower kernel: EIP: [<c108b083>] sync_supers+0x26/0x9f SS:ESP 0068:f1e4ff9c
Mar 23 19:37:07 Tower kernel: CR2: 000000004e52644a
Mar 23 19:37:07 Tower kernel: ---[ end trace ed9070ed2ea69d5b ]---

Message from syslogd@Tower at Sat Mar 23 19:37:07 2013 ...
Tower kernel: EIP: [<c108b083>] sync_supers+0x26/0x9f SS:ESP 0068:f1e4ff9c

Message from syslogd@Tower at Sat Mar 23 19:37:07 2013 ...
Tower kernel: Call Trace:

Message from syslogd@Tower at Sat Mar 23 19:37:07 2013 ...
Tower kernel: Stack:

 

I should mention all those other shares had data in them to move "movies" "tv shows" "kids tv shows", but log logs clearly they where all skipped.

 

I am seeing this, though not with the mover.

Hey speeding_ant, can you elaborate? Are you getting a kernel oops or ...?

Reboot after mover crash.

 

I have asked this before, no answer from Tom, The question was why are there so many reads and several writes to each and every disk in the array when you first start the array including the parity drive, when no clients are attached. THis reading and writing last for about 10-15 mins. Any and every reboot of unRAID.

 

I'm pretty sure I've seen the same behaviour in previous RC's - not related to mover crashing though. Is this not expected behaviour for unRAID?

 

I'm not home at the moment, but can test and confirm when I return if it would help.

 

Sent from my Nexus 7 using Tapatalk HD

Are you referring to the reads and writes upon array start up? If so I investigated and noticed that if SMB is enabled and AFP is disabled this does not occur. If SMB is enabled AND AFP is enabled it does occur.

The question was why are there so many reads and several writes to each and every disk in the array when you first start the array including the parity drive, when no clients are attached. THis reading and writing last for about 10-15 mins. Any and every reboot of unRAID.

 

Are you using cache_dirs?

No cache_dirs, no SF, no unMenu, no Plex, etc... nothing except VMTools (by Zeron), as Tom never fixed the kernel oops errors I had with my SM motherboard and xeon proc (abandoned ), so virtual is the only way unRAID run for me. 2 LSI (OEM LSI) controller's in pass-through to all the disks. It makes no difference to me whether unRAID runs on metal or virtual, but I don't have the choice to run in on metal. This was explained to Tom back in 8-2011, that the only way I could get it running was virtual. Promises made to purchase a SM X8SIL-F MB and Xeon proc (back in 7-19-2011 by him) to resolve but nothing ever happened. I will not run with plugins until 5.0 (hopefully final) is working as it should. Then I can look at what interests me to possible add-on.

 

 

 

 

What is the official (accepted) way to test parity speeds when not running add-on?

 

What is the official (accepted) way to test copy speeds to an array drive when not running add-ons? both locally (disk to disk) and over the network.

 

What version of slackware is this release based on?

I want to build a development VM and recompile the kernel.

Ok, found something i think is very interesting.

 

After i tried rc12 with sf 1.0.5 allready on the system i saw the parity check speeds were horrible (40-50MB/s) compared to rc5/sf 1.0.5 (160MB/s)

So i re-installed rc5 and guess what... the SAME horrible speeds! This baffled me.

So i removed SimpleFeatures, and rebooted... (rc5) and speed was back (160MB/s).

I re-installed SF 1.0.5 using installplg and... the speed stayed up high.

 

So, i guess we need an addition to the up- or downgrade procedure, that states that SimpleFeatures should be REMOVED and RE-INSTALLED after an up - or downgrade.

Keeping SF on the system f*cks things up after upgrading. You HAVE to re-install it. Will place this warning at the Sf topic as well.

 

So i tested a bit more. I removed Simplefeatures again, and replaced rc5 with rc12 and rebooted.

Now i have NO simplefeatures, just unmenu and some plugins (sab/sick/dropbox/slimserver).

Parity speeds are now at about 150MB/s... that is still a little bit less then under rc5 (160MB/s) but acceptable.

This speed can be seen at the stock webgui and in unmenu.

 

Guess what. I've installed SimpleFeatures again (1.0.5) and the parity speed goes down to about 90 - 100MB/s... if you actually watch it IN simplefeatures gui.

Once you close the simplefeatures webpage, and go back to unmenu, you will see the parity speed increase to 150MB/s again...

Using the latest SimpleFeatures (1.0.11) is even worse, it basically stops the parity check with speeds from 20-30MB/s, which is unworkable.

 

Basically this means that SimpleFeatures has a huge negative effect on the performance of unraid and should be avoided.

It would be very interesting to find out why this is, and if it can be solved.

 

I know SF is not part of Limetech, but i think a lot of people use SF together with unraid and even regard it as one and the same.

At least Limetech should take a look at this and warn people about the possible sideeffects of SF, and it should be made clear that IF you are using SF, you should re-install it after an up- or downgrade.

 

So, my apologies to Limetech, rc12 is not as bad as i thought, the real problem is SimpleFeatures...

 

Hi Jowi,

 

Thanks for doing that testing. I'm of two minds, but will need to do some serious investigation. No way should a PHP function cause cpu stalls.

 

Either  way, thankfully you've proved that the speed is the same unless you view the web gui. Unless you are refreshing the GUI for 8 hours straight you won't see a huge difference.

 

I'll need to review the code to inspect what changes might be causing this slowdown. Whatever it will be, IT IS NOT DANGEROUS. It will simply be something that causes I/O interruption, something that browsing a share while parity check is running will do as well.

What version of slackware is this release based on?

I want to build a development VM and recompile the kernel.

 

Seems to be:

------------------------------------

cat /etc/unraid-version = version=5.0-rc12a

cat /etc/slackware-version = Slackware 13.1.0

cat /proc/version = Linux version 3.4.36-unRAID (root@Develop) (gcc version 4.4.4 (GCC) ) #1 SMP Wed Mar 20 12:54:40 PDT 2013

------------------------------------

 

Sorry if its a stupid question, Isnt Slackware 13.1.0 based on Linux 2.6.29 kernel and GCC 4.3.3, is mixing Slack, Kernel, GCC supported?

 

 

I'll need to review the code to inspect what changes might be causing this slowdown. Whatever it will be, IT IS NOT DANGEROUS. It will simply be something that causes I/O interruption, something that browsing a share while parity check is running will do as well.

From Tom's post... "every time a smartctl report is requested of a drive it seems to flush all the existing requests and reset itself." 

 

See here: http://lime-technology.com/forum/index.php?topic=26648.msg233533#msg233533

 

Thus, a UI that constantly checks for temperature and other disk related info every few seconds using "smartctl" will slow down lengthy disk operations such as a parity check.

 

Joe L.

I'll need to review the code to inspect what changes might be causing this slowdown. Whatever it will be, IT IS NOT DANGEROUS. It will simply be something that causes I/O interruption, something that browsing a share while parity check is running will do as well.

From Tom's post... "every time a smartctl report is requested of a drive it seems to flush all the existing requests and reset itself." 

 

See here: http://lime-technology.com/forum/index.php?topic=26648.msg233533#msg233533

 

Thus, a UI that constantly checks for temperature and other disk related info every few seconds using "smartctl" will slow down lengthy disk operations such as a parity check.

 

Joe L.

 

Hi Joe,

 

Already aware of that, the temp plugin was polling smartctl in the background. Bonienl has made a few changes which I haven't reviewed properly in the last version, so I will need to go back through and find if there are any changes that may be causing this behaviour.

 

Cheers

Archived

This topic is now archived and is closed to further replies.

Go to topic listing

Account

Navigation

Search

Search

Configure browser push notifications
Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.