prostuff1 Posted July 16, 2011 Share Posted July 16, 2011 Lots of information Very good information and well said. I think Tom will find this very interesting and it may lead to a change in for the dbpath variable. Quote Link to comment
Nezil Posted July 16, 2011 Share Posted July 16, 2011 Thanks prostuff. A couple of things that I probably should add to what I said before. Going through and deleting all of your .AppleDouble files may not be a good idea. These files don't only contain CNID database cache, they also contain resource forks, which from my understanding can be important to Mac users. I've tried to find more information about exactly what would be in a resource fork, but have not been able to find out a lot. It seems that on older Macintosh systems, each file had two components; a data fork, and a resource fork. Only Apple file systems support the apple resource components, and .AppleDouble files are therefore created to hold these resource fork information. On newer Mac OS X systems, I don't believe there is anything important in these resource forks, but I have heard that some MS Office for Mac applications do use them. In my unRAID server, the only files I have are media files, with all the information in the data fork. I can therefore be pretty confident in deleting the .AppleDouble files. If this is not the case for you, YOU HAVE BEEN WARNED. Deleting the .AppleDouble files could have bad consequences. A few people, including me, have noticed error messages like this in the syslog: Jul 16 22:29:02 unRAID shfs/user: shfs_setxattr: setxattr: /mnt/disk1/Audio (22) Invalid argument Jul 16 22:29:02 unRAID shfs/user: shfs_setxattr: setxattr: /mnt/disk1/BD-Backup (22) Invalid argument Jul 16 22:29:02 unRAID shfs/user: shfs_setxattr: setxattr: /mnt/disk1/Movies (22) Invalid argument Jul 16 22:29:02 unRAID shfs/user: shfs_setxattr: setxattr: /mnt/disk1/Software (22) Invalid argument Jul 16 22:29:02 unRAID shfs/user: shfs_setxattr: setxattr: /mnt/disk1/TV (22) Invalid argument I turned on afpd logging by adding this line to the /etc/netatalk/afpd.conf file -setuplog “default log_info /var/log/afpd.log” On restarting afpd, I was able to see this information in the afpd.log file: Jul 16 23:07:44.859913 afpd[1858] {volume.c:1907} (W:AFPDaemon): volume "Audio" does not support Extended Attributes, using ea:ad instead Jul 16 23:07:44.860087 afpd[1858] {volume.c:1907} (W:AFPDaemon): volume "BD-Backup" does not support Extended Attributes, using ea:ad instead Jul 16 23:07:44.860233 afpd[1858] {volume.c:1907} (W:AFPDaemon): volume "Movies" does not support Extended Attributes, using ea:ad instead Jul 16 23:07:44.860384 afpd[1858] {volume.c:1907} (W:AFPDaemon): volume "Software" does not support Extended Attributes, using ea:ad instead Jul 16 23:07:44.860490 afpd[1858] {volume.c:1907} (W:AFPDaemon): volume "TV" does not support Extended Attributes, using ea:ad instead Which corresponds to the messages above (ignore the time differences, I had to reboot; see below!). I think this means that the errors in the syslog can be safely ignored. Quote Link to comment
Nezil Posted July 16, 2011 Share Posted July 16, 2011 As I was writing the last post, I had the annoying Kernel Oops message regarding my USB HDD for apps. This time it happened when I stopped the array in the web UI, but in the past it's happened when I request a reboot. The important lines from the syslog are: Jul 16 22:57:59 unRAID kernel: BUG: unable to handle kernel NULL pointer dereference at (null) Jul 16 22:57:59 unRAID kernel: IP: [] queue_delayed_work_on+0x33/0xbf Jul 16 22:57:59 unRAID kernel: *pdpt = 00000000377fb001 *pde = 0000000000000000 Jul 16 22:57:59 unRAID kernel: Oops: 0000 [#1] SMP Jul 16 22:57:59 unRAID kernel: last sysfs file: /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/host10/target10:0:0/10:0:0:0/block/sdh/stat Jul 16 22:57:59 unRAID kernel: Modules linked in: md_mod xor mvsas i2c_i801 r8169 libsas ahci i2c_core scsi_transport_sas libahci [last unloaded: md_mod] Jul 16 22:57:59 unRAID kernel: Jul 16 22:57:59 unRAID kernel: Pid: 9857, comm: umount Not tainted 2.6.37.6-unRAID #3 To be filled by O.E.M. To be filled by O.E.M./H67MP-S/-V/H67MP Jul 16 22:57:59 unRAID kernel: EIP: 0060:[] EFLAGS: 00210246 CPU: 2 Jul 16 22:57:59 unRAID kernel: EIP is at queue_delayed_work_on+0x33/0xbf Jul 16 22:57:59 unRAID kernel: EAX: f8522138 EBX: ffffffff ECX: f8522134 EDX: 00000000 Jul 16 22:57:59 unRAID kernel: ESI: 00000000 EDI: f8522134 EBP: f6fb5e44 ESP: f6fb5e38 Jul 16 22:57:59 unRAID kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Jul 16 22:57:59 unRAID kernel: Process umount (pid: 9857, ti=f6fb4000 task=f7506b10 task.ti=f6fb4000) Jul 16 22:57:59 unRAID kernel: Stack: Jul 16 22:57:59 unRAID kernel: f8512000 df6e9b54 df6e9b00 f6fb5e50 c1038a6f 0000000a f6fb5eb4 c10d467a Jul 16 22:57:59 unRAID kernel: f8512000 00000012 00000000 f0b97700 0001c499 037da370 00000000 00000010 Jul 16 22:57:59 unRAID kernel: df6e9b18 00000012 00000004 f8512000 00001da9 00000000 dfe73000 d7085fc0 Jul 16 22:57:59 unRAID kernel: Call Trace: Jul 16 22:57:59 unRAID kernel: [] ? queue_delayed_work+0x1b/0x1e Jul 16 22:57:59 unRAID kernel: [] ? do_journal_end+0x747/0x92a Jul 16 22:57:59 unRAID kernel: [] ? journal_end_sync+0x5b/0x63 Jul 16 22:57:59 unRAID kernel: [] ? reiserfs_sync_fs+0x32/0x51 Jul 16 22:57:59 unRAID kernel: [] ? __sync_filesystem+0x53/0x65 Jul 16 22:57:59 unRAID kernel: [] ? sync_filesystem+0x2c/0x40 Jul 16 22:57:59 unRAID kernel: [] ? generic_shutdown_super+0x1d/0xb5 Jul 16 22:57:59 unRAID kernel: [] ? kill_block_super+0x1d/0x31 Jul 16 22:57:59 unRAID kernel: [] ? reiserfs_kill_sb+0x7d/0x80 Jul 16 22:57:59 unRAID kernel: [] ? deactivate_locked_super+0x1a/0x36 Jul 16 22:57:59 unRAID kernel: [] ? deactivate_super+0x32/0x36 Jul 16 22:57:59 unRAID kernel: [] ? mntput_no_expire+0xb0/0xcc Jul 16 22:57:59 unRAID kernel: [] ? sys_umount+0x8f/0x98 Jul 16 22:57:59 unRAID kernel: [] ? sys_oldumount+0xd/0xf Jul 16 22:57:59 unRAID emhttp: shcmd (124): cp /etc/netatalk/AppleVolumes.default- /etc/netatalk/AppleVolumes.default Jul 16 22:57:59 unRAID kernel: [] ? syscall_call+0x7/0xb Jul 16 22:57:59 unRAID kernel: Code: d6 53 89 c3 f0 0f ba 29 00 19 d2 31 c0 85 d2 0f 85 9d 00 00 00 83 79 10 00 74 04 0f 0b eb fe 8d 41 04 39 41 04 74 04 0f 0b eb fe 06 02 b8 08 00 00 00 75 19 89 c8 e8 9d e6 ff ff 85 c0 74 08 Jul 16 22:57:59 unRAID kernel: EIP: [] queue_delayed_work_on+0x33/0xbf SS:ESP 0068:f6fb5e38 Jul 16 22:57:59 unRAID kernel: CR2: 0000000000000000 Jul 16 22:57:59 unRAID kernel: ---[ end trace cf51328d94327b1e ]--- I'll have to do a hard reset to get things going again. This might be similar to MrLondon's post further up the thread. Quote Link to comment
madburg Posted July 16, 2011 Share Posted July 16, 2011 I am no unable to shutdown my unRaid server, I used the unmenu user script shutdown server and as soon as I done that I could see on the console some kind of fsraiser error message and even after 8 hours it still has not shutdown. This started to happen after upgrading to beta8d and still happens with beta9. I have to press the power button to shut it down. Any ideas? Via the console I still get the login screen so I can issues commands, just cannot get into the web interace anymore and smb is also not working. Really don't want to press the power button for 5 sec again. Please post the hardware you are using please (Motherboard, Processor, any Controllers, how many, what firmware version, etc..). I would like to see if there is any commonality. I have been experiencing this as of 5.0Beta7. Working with Tom to resolve (he's working on it, I am just providing details). Quote Link to comment
madburg Posted July 16, 2011 Share Posted July 16, 2011 As I was writing the last post, I had the annoying Kernel Oops message regarding my USB HDD for apps. This time it happened when I stopped the array in the web UI, but in the past it's happened when I request a reboot. The important lines from the syslog are: Jul 16 22:57:59 unRAID kernel: BUG: unable to handle kernel NULL pointer dereference at (null) Jul 16 22:57:59 unRAID kernel: IP: [] queue_delayed_work_on+0x33/0xbf Jul 16 22:57:59 unRAID kernel: *pdpt = 00000000377fb001 *pde = 0000000000000000 Jul 16 22:57:59 unRAID kernel: Oops: 0000 [#1] SMP Jul 16 22:57:59 unRAID kernel: last sysfs file: /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/host10/target10:0:0/10:0:0:0/block/sdh/stat Jul 16 22:57:59 unRAID kernel: Modules linked in: md_mod xor mvsas i2c_i801 r8169 libsas ahci i2c_core scsi_transport_sas libahci [last unloaded: md_mod] Jul 16 22:57:59 unRAID kernel: Jul 16 22:57:59 unRAID kernel: Pid: 9857, comm: umount Not tainted 2.6.37.6-unRAID #3 To be filled by O.E.M. To be filled by O.E.M./H67MP-S/-V/H67MP Jul 16 22:57:59 unRAID kernel: EIP: 0060:[] EFLAGS: 00210246 CPU: 2 Jul 16 22:57:59 unRAID kernel: EIP is at queue_delayed_work_on+0x33/0xbf Jul 16 22:57:59 unRAID kernel: EAX: f8522138 EBX: ffffffff ECX: f8522134 EDX: 00000000 Jul 16 22:57:59 unRAID kernel: ESI: 00000000 EDI: f8522134 EBP: f6fb5e44 ESP: f6fb5e38 Jul 16 22:57:59 unRAID kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Jul 16 22:57:59 unRAID kernel: Process umount (pid: 9857, ti=f6fb4000 task=f7506b10 task.ti=f6fb4000) Jul 16 22:57:59 unRAID kernel: Stack: Jul 16 22:57:59 unRAID kernel: f8512000 df6e9b54 df6e9b00 f6fb5e50 c1038a6f 0000000a f6fb5eb4 c10d467a Jul 16 22:57:59 unRAID kernel: f8512000 00000012 00000000 f0b97700 0001c499 037da370 00000000 00000010 Jul 16 22:57:59 unRAID kernel: df6e9b18 00000012 00000004 f8512000 00001da9 00000000 dfe73000 d7085fc0 Jul 16 22:57:59 unRAID kernel: Call Trace: Jul 16 22:57:59 unRAID kernel: [] ? queue_delayed_work+0x1b/0x1e Jul 16 22:57:59 unRAID kernel: [] ? do_journal_end+0x747/0x92a Jul 16 22:57:59 unRAID kernel: [] ? journal_end_sync+0x5b/0x63 Jul 16 22:57:59 unRAID kernel: [] ? reiserfs_sync_fs+0x32/0x51 Jul 16 22:57:59 unRAID kernel: [] ? __sync_filesystem+0x53/0x65 Jul 16 22:57:59 unRAID kernel: [] ? sync_filesystem+0x2c/0x40 Jul 16 22:57:59 unRAID kernel: [] ? generic_shutdown_super+0x1d/0xb5 Jul 16 22:57:59 unRAID kernel: [] ? kill_block_super+0x1d/0x31 Jul 16 22:57:59 unRAID kernel: [] ? reiserfs_kill_sb+0x7d/0x8 Jul 16 22:57:59 unRAID kernel: [] ? deactivate_locked_super+0x1a/0x36 Jul 16 22:57:59 unRAID kernel: [] ? deactivate_super+0x32/0x36 Jul 16 22:57:59 unRAID kernel: [] ? mntput_no_expire+0xb0/0xcc Jul 16 22:57:59 unRAID kernel: [] ? sys_umount+0x8f/0x98 Jul 16 22:57:59 unRAID kernel: [] ? sys_oldumount+0xd/0xf Jul 16 22:57:59 unRAID emhttp: shcmd (124): cp /etc/netatalk/AppleVolumes.default- /etc/netatalk/AppleVolumes.default Jul 16 22:57:59 unRAID kernel: [] ? syscall_call+0x7/0xb Jul 16 22:57:59 unRAID kernel: Code: d6 53 89 c3 f0 0f ba 29 00 19 d2 31 c0 85 d2 0f 85 9d 00 00 00 83 79 10 00 74 04 0f 0b eb fe 8d 41 04 39 41 04 74 04 0f 0b eb fe 06 02 b8 08 00 00 00 75 19 89 c8 e8 9d e6 ff ff 85 c0 74 08 Jul 16 22:57:59 unRAID kernel: EIP: [] queue_delayed_work_on+0x33/0xbf SS:ESP 0068:f6fb5e38 Jul 16 22:57:59 unRAID kernel: CR2: 0000000000000000 Jul 16 22:57:59 unRAID kernel: ---[ end trace cf51328d94327b1e ]--- I'll have to do a hard reset to get things going again. This might be similar to MrLondon's post further up the thread. Please post the hardware you are using please (Motherboard, Processor, any Controllers, how many, what firmware version, etc..). I would like to see if there is any commonality. Does not matter if it is a shutdown or reboot. It was dismissed when I posted about it 5.0Beta7 by others but like i stated back then this will end up affecting others, its just a matter of time for others to post. Like Tom stated he is aware, anything we can discover to help would be great. He knows what changed from Beta6x to 7, but thats when it showed itself, prior with the same hardware it was fine (but then we did not have drive spin down support on drives that were on SAS controllers). I would like to rule out processor types, and controllers, but people need to post the hardware they are using when they run into this issue. Also IF you are using any old drives (below 1.5 TB). Quote Link to comment
madburg Posted July 16, 2011 Share Posted July 16, 2011 I'll start (even thought Tom knows my config). Motherboard: SuperMicro X8SI6-F Processor: Intel Xeon X3470 Not using any onbard SATA ports Controller#1: onboard LSI SAS2008 chipset (8 ports - same as an external LSI SAS9211-8i card) Firmware: LSI (P10) IT mode Drives on this Controller (2 & 3 TB Hitach's harddrive all green drives) factory firmware Controller#2: LSI SAS9201-16i (16 ports - LSI SAS2116 chipset) Firmware: LSI (P10) IT mode Drives on this Controller (2 TB Hitach's harddrive all green drives) and (4) 160GB Hitachi's & (1) 250GB Seagate) factory firmware Backplanes: Norco 4224 backplanes Cabling: All cabling via SFF-8087 from controllers to backplanes The old drives are the last drives (Disk 16 -> 20) Up coming tests: Will be moving the older drives up to be the first drives and the new drives being the last drives if I see the same behavior. Will remove the single 3TB drive from the array, check behavior. Will remove all old drives (16GB->250GB), check the behavior. Will remove the only external card (LSI SAS9201-16i), check the behavior. Will disable the onbaord SAS controller put back the external card (LSI SAS9201-16i), check the behavior. I know it should not matter but worth it for me to scratch off the list of what I tried to troubleshoot this issue with from my end. And believe me I have been testing quite a few scenarios. Quote Link to comment
MrLondon Posted July 16, 2011 Share Posted July 16, 2011 I am no unable to shutdown my unRaid server, I used the unmenu user script shutdown server and as soon as I done that I could see on the console some kind of fsraiser error message and even after 8 hours it still has not shutdown. This started to happen after upgrading to beta8d and still happens with beta9. I have to press the power button to shut it down. Any ideas? Via the console I still get the login screen so I can issues commands, just cannot get into the web interace anymore and smb is also not working. Really don't want to press the power button for 5 sec again. Please post the hardware you are using please (Motherboard, Processor, any Controllers, how many, what firmware version, etc..). I would like to see if there is any commonality. I have been experiencing this as of 5.0Beta7. Working with Tom to resolve (he's working on it, I am just providing details). Asus P7H55-M LX motherboard, 6 Samsung F4 drives of the motherboard and a controller 3.1.15N firmware. Current 6 drives. all 2tb, 2x Hitachi 5c3000 and 3x WD green drive and another Samsung F4 connected to that controller. i3-340 processor and 4gb of Corsair ram. The motherboard has the lastest firmware 0405. Anything else you need? Quote Link to comment
madburg Posted July 16, 2011 Share Posted July 16, 2011 I am no unable to shutdown my unRaid server, I used the unmenu user script shutdown server and as soon as I done that I could see on the console some kind of fsraiser error message and even after 8 hours it still has not shutdown. This started to happen after upgrading to beta8d and still happens with beta9. I have to press the power button to shut it down. Any ideas? Via the console I still get the login screen so I can issues commands, just cannot get into the web interace anymore and smb is also not working. Really don't want to press the power button for 5 sec again. Please post the hardware you are using please (Motherboard, Processor, any Controllers, how many, what firmware version, etc..). I would like to see if there is any commonality. I have been experiencing this as of 5.0Beta7. Working with Tom to resolve (he's working on it, I am just providing details). Asus P7H55-M LX motherboard, 6 Samsung F4 drives of the motherboard and a controller 3.1.15N firmware. Current 6 drives. all 2tb, 2x Hitachi 5c3000 and 3x WD green drive and another Samsung F4 connected to that controller. i3-340 processor and 4gb of Corsair ram. The motherboard has the lastest firmware 0405. Anything else you need? Need a bit of clarification, You have (6) Samsung F4's running off the onboard SATA ports is this correct? The F4 are 2TB right? Then you have some sort of controller with 3.1.15N firmware, you didn't state what type of controller? (AOC-SASLP-MV8 with 3.1.0.15N?) and you have (2) 2TB Hitachi's, (3) WD (what size?) and (1) Samsung F4 on this controller right? Any backplane? or just a forward breakout cable to the drives from the controller? Quote Link to comment
MrLondon Posted July 16, 2011 Share Posted July 16, 2011 Motherboard: Asus P7H55-M LX bios 0405 with 6 onboard SATA 2 connects which have 6 times SAMSUNG_HD204UI AOC-SASLP-MV8 8port SAS to SATA controller (firmware 3.1.15N) with 2x Hitachi_HDS5C3020ALA632, 3x WDC_WD20EARS, 1x SAMSUNG_HD204UI The Hitachi and 2 WD drives are in the coolermaster 4 in 3 cage. The rest of the drives are in their own bay. I use the breakout cable 1 to 4 sata connector to from the AOC controller to 6 drives. Hope this clarifies it. Quote Link to comment
dgaschk Posted July 17, 2011 Share Posted July 17, 2011 Does "Min. Free Space" do what you want? Set your TM share to include only one disk, set the Min. Free Space value to the difference in space that you want it to take up. Select Fill-up as your Allocation method. "Min free space" only applies when creating a new file. If you extend an existing file (open in append mode), nothing will stop it from growing beyond "Min free space". This should still work for TM but not in the general case. TM uses a sparsebundle for storage. A sparsebundle is stored as a directory containing 8MB files. Each file contains a portion of the total backup. The sparsebundle grows by creating a new 8MB file. When the "min free space" is reached it should start trimming the backup and reusing existing 8MB files. That said, I'd still like to have a max size setting for shares. Quote Link to comment
Nezil Posted July 17, 2011 Share Posted July 17, 2011 As requested by Madburg: Case: Lian Li PC-P50B Motherboard: Foxconn H67MP Processor: Intel Core i3 2100 Controller 1: onboard H67 chipset (2 x SATA III, 4 x SATA II) Drives: 2 x WD20EVDS, 2 x WD20EADS, 1 x WD20EARS, 1 x WD10EAVS Controller 2: Supermicro AOC-SASLP-MV8 (8 x SATA II) Firmware: 3.10.21 Drives: 1 x WD10EAVS, 4 x WD10EADS Controller 3: Biostar DCS3A [ASMedia 106x Chipset] (2 x SATA III) Drives: None so far Controller 4: USB HDD Case, Connected and mounted internally Drives: 20GB Samsung SATA HDD (From an XBOX 360) - Used for Plex & Slimserver Apps Backplanes: 3 x IcyDock MB455SPF-B Cabling: Standard SATA Cables from Onboard and Bios Controllers, 3Ware Forward Breakouts from the Supermicro Some Notes: It always seems to be the USB HDD that causes the Kernel Oops (sdh mentioned in the log I posted earlier). This drive is connected to the internal USB Header. The reason for doing this, is that I don't use a cache drive, and want to maximise the available storage in my case, thereby using all 15 drive cages in the backplane for storage. I mount the drive at /mnt/apps, and also 'bind mount' /tmp to a sub-directory on the drive. The /tmp folder needs to be mounted because Plex writes the video chucks for HTTP Live Streaming to the /tmp folder, and it would quickly fill up the RAM disk otherwise. I have a script that is called based on the 'emhttp_event' to start up my add ons. This is necessary because Plex and Slimserver might prevent the array from stopping if they're holding on to files in the array for any reason. I recently added the 'stopped' case to my script, to try and stop the Kernel Oops... it didn't work though! My script is shown below: # A script to start up and shutdown services when the array starts and stops case $1 in svcs_started) if [ -L /dev/disk/by-id/usb-SAMSUNG_HM020GI_A10040007188-0:0-part1 ]; then if ! mount | grep /mnt/apps\ ; then mount /dev/disk/by-id/usb-SAMSUNG_HM020GI_A10040007188-0:0-part1 /mnt/apps fi if ! mount | grep /tmp; then cd /tmp; tar cf - . | (cd /mnt/apps/.tmp; tar xf -) mount --bind /mnt/apps/.tmp /tmp fi if ! ps -ef | grep .Plex/Plex\ Media\ Server | grep -v grep; then /mnt/apps/.Plex/start.sh >> /Library/Logs/.Plex\ Media\ Server.log 2>&1 & logger -t Plex\ Media\ Server Started fi if ! ps -ef | grep slimserver.pl | grep -v grep; then /mnt/apps/.Squeezebox/SqueezeboxServer/slimserver.pl --nosb1slimp3sync --logdir /var/log --cachedir /mnt/apps/.Squeezebox/Cache/ --noupnp --daemon --user neil logger -t Squeezebox\ Server Started fi fi;; svcs_restarted) if [ -L /dev/disk/by-id/usb-SAMSUNG_HM020GI_A10040007188-0:0-part1 ]; then if ! mount | grep /mnt/apps\ ; then mount /dev/disk/by-id/usb-SAMSUNG_HM020GI_A10040007188-0:0-part1 /mnt/apps fi if ! mount | grep /tmp; then cd /tmp; tar cf - . | (cd /mnt/apps/.tmp; tar xf -) mount --bind /mnt/apps/.tmp /tmp fi if ! ps -ef | grep .Plex/Plex\ Media\ Server | grep -v grep; then /mnt/apps/.Plex/start.sh >> /Library/Logs/.Plex\ Media\ Server.log 2>&1 & logger -t Plex\ Media\ Server Started fi if ! ps -ef | grep slimserver.pl | grep -v grep; then /mnt/apps/.Squeezebox/SqueezeboxServer/slimserver.pl --nosb1slimp3sync --logdir /var/log --cachedir /mnt/apps/.Squeezebox/Cache/ --noupnp --daemon --user neil logger -t Squeezebox\ Server Started fi fi;; stopping_svcs) if mount | grep /mnt/apps\ ; then if ps -ef | grep .Plex/Plex\ Media\ Server | grep -v grep; then kill -s INT `ps -ef | grep .Plex/Plex\ Media\ Server | grep -v grep | awk '{print $2}'` logger -t Plex\ Media\ Server Stopped fi if mount | grep /tmp; then umount /tmp fi if ps -ef | grep slimserver.pl | grep -v grep; then kill -s INT `ps -ef | grep slimserver.pl | grep -v grep | awk '{print $2}'` logger -t Sqeezebox\ Server Stopped fi fi;; stopped) if mount | grep /mnt/apps\ ; then umount /mnt/apps; fi;; esac The next thing I will try, is to use the last spare SATA channel from the Biostar card to connect the Samsung 20GB Applications drive rather than use USB. I'm hoping this might solve the issue, but I'm not confident. Quote Link to comment
madburg Posted July 17, 2011 Share Posted July 17, 2011 Many thanks for posting this info Nezil. I would higly recommend posting the entire syslog for Tom. If that previous one is gone, then the next time it happens, please. Just incase it was not clear to others, my request, to post your HW configuration was ONLY to people who experience the hang/crash/Oops (not sure what Tom wants this label as) when they go to shutdown or reboot their unRAID server. and please post you syslog. If Tom does not need this information anymore at some point (HW specs), he will let us know so we dont add to this post. Quote Link to comment
madburg Posted July 17, 2011 Share Posted July 17, 2011 Nezil, you meant a AOC-SASLP-MV8 right? I am tracking something down. Quote Link to comment
madburg Posted July 17, 2011 Share Posted July 17, 2011 Asus P7H55-M LX motherboard, 6 Samsung F4 drives of the motherboard and a controller 3.1.15N firmware. Current 6 drives. all 2tb, 2x Hitachi 5c3000 and 3x WD green drive and another Samsung F4 connected to that controller. i3-340 processor and 4gb of Corsair ram. The motherboard has the lastest firmware 0405. Anything else you need? I cant find a i3-340 spec, is this a typo? Could you please post proc as this is very important. Maybe a Intel® Core™ i3-540 Processor (4M Cache, 3.06 GHz)? Quote Link to comment
Nezil Posted July 17, 2011 Share Posted July 17, 2011 Yes, that's right SASLP, I've modified the original post. Syslog attached from the latest crash on reboot... just now! It looks again like it's /dev/sdh related, though this is my USB Flash Drive now; For this boot, I'd moved the Samsung disk to the SATA controller. Next test... remove the Biostar Card. syslog_17-07-11.txt Quote Link to comment
Nezil Posted July 17, 2011 Share Posted July 17, 2011 So back to the AFP Issues... Having moved these .AppleDB database files to another disk, and noticing a performance benefit from having done so, I have done some investigation to see if I can get these database files to not need to be re-created on every boot. I've also done some testing with the previous Netatalk in beta8d (v2.0.5), again with the dbpath variable set to a separate disk. I'll start with the results from that version: 5.0b8d / Netatalk 2.0.5 After boot up, I removed all the CNID .AppleDB folders, and ran my find . commands on each of the shares to build the CNID databases. Once this was done, browsing was fast on all machines in my network, and I checked the resulting database file sizes by running the du /apps/dbd/ -h --max-depth=1 command, results below: root@unRAID:/apps/dbd# du -h --max-depth 1 452K ./TV 3.0M ./Audio 312K ./Movies 48K ./BD-Backup 32K ./Software 3.8M . Total data for CNID databases is 3.8 MB, quite reasonable. I rebooted the system (which caused a Kernel Oops again - seems it wasn't an issue with the Biostar card!, Syslog attached). After the reboot, the CNID databases were still present, and had the same combined size of 3.8MB; this didn't seem to make browsing any better however, and after running all the find . commands again, the result of another du /apps/dbd/ -h --max-depth=1 command, showed: root@unRAID:/apps/dbd/BD-Backup# du /apps/dbd/ -h --max-depth=1 861K /apps/dbd/TV 4.5M /apps/dbd/Audio 581K /apps/dbd/Movies 48K /apps/dbd/BD-Backup 32K /apps/dbd/Software 6.0M /apps/dbd/ The size had nearly doubled! I wonder how long this will go on for? Stopping and Starting the array also required the CNID databases to be re-created, but with different results; this time the du /apps/dbd/ -h --max-depth=1 command, showed only slightly larger sizes than previous run: 6.4 MB total. A few other bits of information: - Running find /Volumes on the Mac, with all the unRAID AFP shares mounted takes 3 minutes 40 seconds on my system (If these CNID database files were on the array drives, it would take even longer as parity would be involved in writing the files) - Running the same command takes just 3 seconds to complete once the databases are created - The killall -HUP afpd command issued when minor changes to shares are made in the web UI doesn't affect the CNID databases; performance isn't affected - Running /etc/rc.d/rc.atalk restart extends the time for the find command to 11 seconds, for the next run; hardly any effect on performance decrease, and back to normal 3 seconds after that - Starting and stopping the array, or rebooting the system causes the CNID databases to be re-created, probably because the AFP shares in AppleVolumes.default are removed and then re-created in the process. In time this may cause the database files to grow to a potentially large size. As an aside, version 2.0x of Netatalk doesn't ever seem to store a CNID cache in the .AppleDouble files, and these are therefore not created as you browse around as they are by default in 2.1x. The nocnidcache variable therefore seems to have no effect in 2.0x. Time to move on to beta9 testing... 5.0b9 / Netatalk 2.1.5 Running the same tests as before (Deleting all CNID Files, and rebuilding them from scratch with the newer Netatalk) results in the following from a du /apps/dbd/ -h --max-depth=1 command: root@unRAID:/apps/dbd# du . -h --max-depth=1 3.5M ./TV 18M ./Audio 2.5M ./Movies 27MB ./BD-Backup 968K ./Software 51M . - The file sizes are bigger, but it didn't take very much longer to create them - 4 minutes 18 seconds. - Re-running the command gives the same 3 second performance as the previous version. Where did all that data come from? If you look inside the .AppleDB folders, on both Netatalk 2.0.5 and 2.1.5, there are four files called lock, log.0000000001, cnid2.db and db_err.log. Netatalk 2.1.5 however also has several files labelled __db.00x, and it's these that make up the majority of the additional data. Perhaps 2.0.5 is storing these in RAM? When a share is removed, added or changed by making changes to the AppleVolumes.default file, as happens when starting or stopping the array; all of this __db.00x files are deleted, and must be re-created again. - As before, if a killall -HUP afpd command is called, performance is not affected really - If the array is started and stopped, or the system is rebooted, the databases need to be completely rebuilt, slowing everything down again. Conclusion / Suggestion 1. Storring the .AppleDB files on a disk outside the array, or possibly the RAM disk, will improve performance when initially creating the databases. There may also be some compatibility issues with having these on the Fuser disk system that's used for user shares. This can be changed with the dbpath: variable in AppleVolumes.default- 2. Using the .AppleDouble files to store the CNID database cache (introduced in 2.1.5) causes performance and possibly again compatibility issues on user shares. This can be disabled by adding the nocnidcache option to the AppleVolumes.default- file 3. The current method of starting and stopping the array involves continual restarting of the AFP daemons, and moving and making changes to the AppleVolumes.default file. This causes all the CNID databases to be deleted / re-created, which may not be necessary. I would like to try and investigate what happens if you change the order of starting and stopping AFP daemons. For example, AFP daemons are stopped when the array stops, before the AppleVolumes.default- changes are carried out, and then only re-started after the array has started again, and any changes to the AppleVolumes.default- files have taken place. My suggestion for 3. would mean that AFP services would not be running when the array is stopped, but I don't see this as being a problem, as nothing can be connected to in this case anyway. Syslog_2_17-07-11.txt Quote Link to comment
MrLondon Posted July 17, 2011 Share Posted July 17, 2011 Asus P7H55-M LX motherboard, 6 Samsung F4 drives of the motherboard and a controller 3.1.15N firmware. Current 6 drives. all 2tb, 2x Hitachi 5c3000 and 3x WD green drive and another Samsung F4 connected to that controller. i3-340 processor and 4gb of Corsair ram. The motherboard has the lastest firmware 0405. Anything else you need? I cant find a i3-340 spec, is this a typo? Could you please post proc as this is very important. Maybe a Intel® Core™ i3-540 Processor (4M Cache, 3.06 GHz)? Sorry it was late, you were right it is of course the i3-540 processor. Quote Link to comment
Interstellar Posted July 17, 2011 Share Posted July 17, 2011 Everything seems to be working fine here! Time-Machine, user shares, etc. Quote Link to comment
PeterB Posted July 17, 2011 Share Posted July 17, 2011 I am no unable to shutdown my unRaid server, I used the unmenu user script shutdown server and as soon as I done that I could see on the console some kind of fsraiser error message and even after 8 hours it still has not shutdown. This started to happen after upgrading to beta8d and still happens with beta9. I have to press the power button to shut it down. Any ideas? Via the console I still get the login screen so I can issues commands, just cannot get into the web interace anymore and smb is also not working. Really don't want to press the power button for 5 sec again. Please post the hardware you are using please (Motherboard, Processor, any Controllers, how many, what firmware version, etc..). I would like to see if there is any commonality. I have been experiencing this as of 5.0Beta7. Working with Tom to resolve (he's working on it, I am just providing details). I think that I'm also suffering from this problem. I hadn't realised it because I assumed that it was all to do with the fact that I run other server apps on my unRAID system. However, there certainly seems to be problem with shutting down/rebooting (or even simply stopping the array?). I know that I've had to resort to a long press of the power button recently, but have never needed to do that in the past. My hardware configuration is detailed in my signature. The only additional information is that the parity and cache drives are on the mobo. The data drives are all on a single breakout cable from the AOC-USAS2-L8i card. Quote Link to comment
madburg Posted July 17, 2011 Share Posted July 17, 2011 PeterB, please attach a complete syslog to your post, so this way Tom knows to add you as another count to this issue or not. Syslog is required. Fairly simple, start array, copy or delete something from a drive (needs I/O). Try stopping array and then shutdown or rebooting server. once it oops (It can oops on stopping the array and never get to shutdown or restart), telnet in and run "cp /var/log/syslog /boot/syslog.txt", a copy of the syslog is now on the USB key for you, hard reset the server, grab the syslog and post. Many thanks. Quote Link to comment
PeterB Posted July 18, 2011 Share Posted July 18, 2011 PeterB, please attach a complete syslog to your post, so this way Tom knows to add you as another count to this issue or not. Syslog is required. Do you mean like the one attached, from last week, with a kernel: Oops when the powerdown was initiated by apcupsd? syslog-20110712-090909.txt.zip Quote Link to comment
savestheday Posted July 18, 2011 Share Posted July 18, 2011 I've got an odd issue. I've got a directory called /mnt/user0 and it is linked to all the same directories as /mnt/user. I've done 2 things today that could have caused it. I installed Mediatomb for upnp stuff and I pointed sickbeard to /mnt/user/tv. I don't think it was Sickbeard since that's the way I found it. It could be Mediatomb but it seems odd for that to have created that directory. Can I safely remove this dir or would it remove everything in /mnt/user as well? Quote Link to comment
Nezil Posted July 18, 2011 Share Posted July 18, 2011 Saves the day, in an earlier post (about beta8d) by Tom, he explains the purpose of this folder. In short... you need it... don't delete it... unRAID created it for moving files from the cache drive. See this quote: I should add: there's another subtle change in the mover script. You'll see that it now moves to a different user share file system mount point call /mnt/user0. This is same behavior as in past releases. The reason for the change was my clever simplification caused other problems so I had to return to previous method of having two mount points: If cache disk not available: /mnt/user => user share file system mount point If cache disk available: /mnt/user => user share file system mount point, including objects on Cache disk /mnt/user/0 => user share file system mount point, excluding objects on Cache disk Quote Link to comment
savestheday Posted July 18, 2011 Share Posted July 18, 2011 Damn Nezil, thank you so much. I read that and completely forgot about it. Quote Link to comment
limetech Posted July 18, 2011 Author Share Posted July 18, 2011 Where did all that data come from? If you look inside the .AppleDB folders, on both Netatalk 2.0.5 and 2.1.5, there are four files called lock, log.0000000001, cnid2.db and db_err.log. Netatalk 2.1.5 however also has several files labelled __db.00x, and it's these that make up the majority of the additional data. Perhaps 2.0.5 is storing these in RAM? When a share is removed, added or changed by making changes to the AppleVolumes.default file, as happens when starting or stopping the array; all of this __db.00x files are deleted, and must be re-created again. - As before, if a killall -HUP afpd command is called, performance is not affected really - If the array is started and stopped, or the system is rebooted, the databases need to be completely rebuilt, slowing everything down again. Nezil - nice analysis, but unfortunately a lot of it is wrong/misleading. The .AppleDB folder contains the Berkeley Database files used to store CNID-to-file mappings required by AFP. The files starting with "__" such as __db.001, are temporary files used during operation; in my testing they take very little time to create upon startup of AFP daemons. The log.0000000001 file stores DB transactions (ie, a journal of sorts) that lets Berkeley DB recover from a system crash. In my testing, I've found that "restoring" the DB from using this file is what's taking all the time, and I haven't determined why this is the case yet. Conclusion / Suggestion 1. Storring the .AppleDB files on a disk outside the array, or possibly the RAM disk, will improve performance when initially creating the databases. There may also be some compatibility issues with having these on the Fuser disk system that's used for user shares. This can be changed with the dbpath: variable in AppleVolumes.default- You definitely don't want these in a RAM disk, maybe the Cache disk, but probably the extra complication this entails is not worth it, but something I'm looking into. 2. Using the .AppleDouble files to store the CNID database cache (introduced in 2.1.5) causes performance and possibly again compatibility issues on user shares. This can be disabled by adding the nocnidcache option to the AppleVolumes.default- file The .AppleDouble files have always been part of netatalk, and are required to implement resource forks. If you use 'nocnidcache' option, and you lose the main cnid2.db, then all your resource forks are gone. This is not recommended, and adds very little to decrease performance. 3. The current method of starting and stopping the array involves continual restarting of the AFP daemons, and moving and making changes to the AppleVolumes.default file. This causes all the CNID databases to be deleted / re-created, which may not be necessary. I would like to try and investigate what happens if you change the order of starting and stopping AFP daemons. For example, AFP daemons are stopped when the array stops, before the AppleVolumes.default- changes are carried out, and then only re-started after the array has started again, and any changes to the AppleVolumes.default- files have taken place. My suggestion for 3. would mean that AFP services would not be running when the array is stopped, but I don't see this as being a problem, as nothing can be connected to in this case anyway. Again, making changes to AppleVolumes.default does not cause "CNID databases to be deleted /re-created", nor should stop/start of the various AFP daemons. A big change between netatalk 2.0 and 2.1 was requirement of using Berkeley DB 4.6 or later (previously DB 4.4 was requirement). This required me to create a slack package for DB 4.6, which I did by modifying slack build scripts for 4.4. It's possible I have some configure options incorrect for this version. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.