Joe L. Posted October 17, 2009 Share Posted October 17, 2009 This version seems to be randomly stopping the array for me. Especially when resume from suspend with my browser on http://tower/main.html or when I connect via smb://tower for the first time. Running os-x 10.6 and Safari. Going to revert to 4.5beta6 and see if it continues to happen as its possible its something entirely client related. It almost looks like it keeps "replaying" the "Stop" button from the browser. I agree, it looks odd. Tom will want to look at your syslog. Good that you posted it. I've not experienced anything like it, but then I don't put my array to sleep like you are. Joe L. Quote Link to comment
Chris Pollard Posted October 17, 2009 Share Posted October 17, 2009 I've not experienced anything like it, but then I don't put my array to sleep like you are. Joe L. Just to be clear this happens when my laptop resumes from suspend and I have http://tower/main.htm open in safari. Not 100% sure this is 4.5b7 related at this point however. Quote Link to comment
Joe L. Posted October 17, 2009 Share Posted October 17, 2009 I've not experienced anything like it, but then I don't put my array to sleep like you are. Joe L. Just to be clear this happens when my laptop resumes from suspend and I have http://tower/main.htm open in safari. Not 100% sure this is 4.5b7 related at this point however. Your laptop might be re-sending the "Stop" command to the unRAID server when it is awakened then?... assuming it was the last thing you did with it? Quote Link to comment
Chris Pollard Posted October 17, 2009 Share Posted October 17, 2009 Your laptop might be re-sending the "Stop" command to the unRAID server when it is awakened then?... assuming it was the last thing you did with it? The last thing would have been a start.... Let me see if it comes up again running 4.5b6 I have a funny feeling this is Safari related. Quote Link to comment
Chris Pollard Posted October 17, 2009 Share Posted October 17, 2009 Your laptop might be re-sending the "Stop" command to the unRAID server when it is awakened then?... assuming it was the last thing you did with it? The last thing would have been a start.... Let me see if it comes up again running 4.5b6 I have a funny feeling this is Safari related. OK Confirmed this also happens in 4.5b6. Wireshark shows me sending http://tower/update.htm?startState=STARTED&cmdStop=Stop so this is definitely something Safari related. Apologies for jumping the gun Quote Link to comment
tdoris Posted October 18, 2009 Share Posted October 18, 2009 Currently one of the things I'm trying to use unRAID for is NFS disk storage for some of the non-critical VMs on my XenServer. Pretty much all of the v4.5 betas (including beta7) I've tried cause problems where the NFS storage gets dropped. On the XenServer, I can see NFS connection timeout messages. I know FUSE has a history of issues with NFS and I've seen some other messages here indicating various issues with NFS. Would be best for me to setup things differently (perhaps file based iSCSI disks being accessed via a SMB share on the unRAID box) or is there hope that the NFS issues will be solved soon? Quote Link to comment
MrZammler Posted October 21, 2009 Share Posted October 21, 2009 Currently one of the things I'm trying to use unRAID for is NFS disk storage for some of the non-critical VMs on my XenServer. Pretty much all of the v4.5 betas (including beta7) I've tried cause problems where the NFS storage gets dropped. On the XenServer, I can see NFS connection timeout messages. I know FUSE has a history of issues with NFS and I've seen some other messages here indicating various issues with NFS. Would be best for me to setup things differently (perhaps file based iSCSI disks being accessed via a SMB share on the unRAID box) or is there hope that the NFS issues will be solved soon? I'm using NFS for a couple of months now (since I build my unraid) and while NFS in unraid does have some quirks, it doesn't display the problems you mention. I'm using the latest stable (4.4.2). Quote Link to comment
NAS Posted October 21, 2009 Share Posted October 21, 2009 Is anyone else finding unRAID drops out occasionally especially under heavy load condiditons only to come back on its own with no relevant syslog entries? Quote Link to comment
prostuff1 Posted October 21, 2009 Share Posted October 21, 2009 Is anyone else finding unRAID drops out occasionally especially under heavy load condiditons only to come back on its own with no relevant syslog entries? What do you mean by drops out? I had a problem with my setup originally that was caused by a NIC card/driver that was flaky. It would cause the network connection to be lost and the only way to get it back was to restart the unRAID machine. Quote Link to comment
boof Posted October 21, 2009 Share Posted October 21, 2009 Is anyone else finding unRAID drops out occasionally especially under heavy load condiditons only to come back on its own with no relevant syslog entries? Yes - I can almost reproduce at will with rtorrent loaded with a few torrents at once. Disks thrash (though not parity interestingly) whilst anything interactive locks up. Eventually comes back. Occasionally it goes on for so long rtorrent segfaults with an error akin to not being able to find the free space - I presume it hasn't been able to get it in time and has fallen over. This is on the previous beta release I should caveat but I would imagine it's the same issue. Currently very interested in the other thread discussing schedulers and potential improvements in responsiveness at the expense of overall throughput. Quote Link to comment
WeeboTech Posted October 21, 2009 Share Posted October 21, 2009 Disks thrash (though not parity interestingly) whilst anything interactive locks up. Eventually comes back. Occasionally it goes on for so long rtorrent segfaults with an error akin to not being able to find the free space - I presume it hasn't been able to get it in time and has fallen over. This is on the previous beta release I should caveat but I would imagine it's the same issue. Currently very interested in the other thread discussing schedulers and potential improvements in responsiveness at the expense of overall throughput. I've not had this issue with rtorrent and sometimes my rtorrent is extremely busy. I have had issues in the past when moving DVD's via Samba. I would see the destination disk get very very busy while it was allocating the directory entry (or space). This was before any data moved across the link. Sometimes the copy operation would time out and I would loose the windows connection to the share. I'm wondering if CFQ or DEADLINE scheduler will help this. Quote Link to comment
boof Posted October 21, 2009 Share Posted October 21, 2009 Disks thrash (though not parity interestingly) whilst anything interactive locks up. Eventually comes back. Occasionally it goes on for so long rtorrent segfaults with an error akin to not being able to find the free space - I presume it hasn't been able to get it in time and has fallen over. This is on the previous beta release I should caveat but I would imagine it's the same issue. Currently very interested in the other thread discussing schedulers and potential improvements in responsiveness at the expense of overall throughput. I've not had this issue with rtorrent and sometimes my rtorrent is extremely busy. I have had issues in the past when moving DVD's via Samba. I would see the destination disk get very very busy while it was allocating the directory entry (or space). This was before any data moved across the link. Sometimes the copy operation would time out and I would loose the windows connection to the share. I'm wondering if CFQ or DEADLINE scheduler will help this. Usually happens with either lots of torrents running or torrents which are writing to lots of files (or combo of both!). I've found rtorrent very stressful to machines and seen it crash machines much better spec'd than my unraid server (although granted it was saturating 100mbit almost at fdx when that happened...not just piddly 8mbit downstream) so not overly surprised. Conversely I've never had that issue when doing anything via samba. Quote Link to comment
vca Posted October 21, 2009 Share Posted October 21, 2009 I have had issues in the past when moving DVD's via Samba. I would see the destination disk get very very busy while it was allocating the directory entry (or space). This was before any data moved across the link. Sometimes the copy operation would time out and I would loose the windows connection to the share. I'm wondering if CFQ or DEADLINE scheduler will help this. I ran into the same thing when setting up a TrueCrypt container on an unRAID drive. What I was doing was running TrueCrypt on my Windows PC and just using unRAID to host the TrueCrypt file, so the PC just accessed the file via the samba share (either as a user or disk share). The problem became apparent when I tried to create a container bigger than about 50GB. After some research I came across some samba issue reports that noted that when a file is created with a particular initial size the samba server does not return a response to the samba client until all the disk space has been allocated and cleared. So as the requested file size gets larger, this takes longer, until eventually the windows client end of the connection gives up and reports a vague "network error". If you monitor what is going on (using a telnet session into the unRAID server) you can see the file size growing on the server, until the point in time the windows client gives up, and then (if I recall correctly) the samba server deletes the file. As far as I can recall the samba people considered this to be a bug in the samba server, something to the effect of "the server should just accept the file creation request, check there is sufficient space and if so start the initial fill in the background and return successfully right away rather than forcing the client to wait". Note, all of this happened on initial creation of the file on the server before TrueCrypt started to fill it with random data. In the end I got around the issue by creating the container on a USB drive on the Windows PC, then attaching the drive to the unRAID server and copying the container into the raid. From then on TrueCrypt over the network has no issues with the large file size. Regards, Stephen Quote Link to comment
purko Posted October 21, 2009 Share Posted October 21, 2009 I have had issues in the past when moving DVD's via Samba. I would see the destination disk get very very busy while it was allocating the directory entry (or space). This was before any data moved across the link. Sometimes the copy operation would time out and I would loose the windows connection to the share. I'm wondering if CFQ or DEADLINE scheduler will help this. Weebo, I used to have EXACTLY the same problem you are describing above, and it was driving me insane. Now I can confirm that changing the I/O scheduler TOGETHER with tweaking the max_sectors_kb value solved it for me, as described in that other thread. Notice that changing the scheduler alone did not quite fix my problem, although it was an improvement for me. Nor did changing max_sectors_kb alone do it. Only the two together did some magic to my unRaid box and now things are sweet! As we speak, the array is running a parity check, rtorrent is doing some stuff, my HTPC is playing a DVD movie off the array, and a XP machine is copying a big folder of DVDs to the array. All this without a hickup! (And on a very low-spec server mind you!) I wanted to really push its limits so I can confirm that my problem is fixed. Purko Quote Link to comment
boof Posted October 22, 2009 Share Posted October 22, 2009 I'll post here that changing the scheduler and other kernel parameters as Purko suggested above, and in his other thread, also appears to have completely removed my rtorrent i/o issue and left the entire server far more responsive under heavy i/o load. Highly recommended. I have a slight concern in the back of my head that the scheduler used by default *might* be used for a specific unraid only reason. Any comment? Quote Link to comment
purko Posted October 22, 2009 Share Posted October 22, 2009 I'll post here that changing the scheduler and other kernel parameters as Purko suggested above, and in his other thread, also appears to have completely removed my rtorrent i/o issue and left the entire server far more responsive under heavy i/o load. Highly recommended. Glad to hear that! Quote Link to comment
purko Posted October 22, 2009 Share Posted October 22, 2009 I have a slight concern in the back of my head that the scheduler used by default *might* be used for a specific unraid only reason. Any comment? Currently unraid ships with four i/o schedulers to chose from: noop, anticipatory, deadline, and cfq. If there were any specific unraid-only reason to only use the noop scheduler, then Limetech would have compiled the kernel with noop only. So you shouldn't worry about that at all. Purko Quote Link to comment
Guzzi Posted October 22, 2009 Share Posted October 22, 2009 I have a slight concern in the back of my head that the scheduler used by default *might* be used for a specific unraid only reason. Any comment? Currently unraid ships with four i/o schedulers to chose from: noop, anticipatory, deadline, and cfq. If there were any specific unraid-only reason to only use the noop scheduler, then Limetech would have compiled the kernel with noop only. So you shouldn't worry about that at all. Purko As quoted in the other thread, I am highly interested in solving this "freezing" issue with those parameters; So: Tom, can you please drop a short note/comment from unraid point of view? Thanks! Quote Link to comment
purko Posted October 22, 2009 Share Posted October 22, 2009 As quoted in the other thread, I am highly interested in solving this "freezing" issue with those parameters; So: Tom, can you please drop a short note/comment from unraid point of view? Thanks! Well, Guzzi, just try it and then tell us what happened! The more feedback we get from different people, the better idea Tom will have about what's going on. That's what a "beta" is for after all. Purko Quote Link to comment
limetech Posted October 22, 2009 Author Share Posted October 22, 2009 There should be no problem testing whatever scheduler you want, or tweaking stuff like max_sectors_kb. Several linux kernels ago, I did some testing with the various schedulers and found no appreciable difference in a typical unRAID server. However, that said, I will be releasing -beta8 which has, among other things, these two changes: - set default scheduler to 'cfq' - rebuilt linux kernel with "Voluntary Kernel Preemption" model (has always been "No Forced Preemption") What I want to find out is if this helps in latency. So far I see no difference in testing, but then I'm not running torrent servers either. As for max_sectors_kb - well this just sets the upper limit on an I/O request to a block device (ie, disk drive). The default value of '512' means that the largest request the disk driver will get is 512KB (or 1024 sectors). The largest it "should" see is generally 128K. I don't see how lowering this to 64 would help performance - not saying that it doesn't - just that it's not intuitive that should be the case Quote Link to comment
purko Posted October 22, 2009 Share Posted October 22, 2009 I will be releasing -beta8 Speaking of the next beta, can we possibly include the libata.force patch module in the new build? I have a nice little Norco NS-520 box which has a spot for a 2.5" IDE disk. The disk connects to the motherboard with a 44-pin cable. I put a brand new WD-Scorpio disk in there (the latest-and-greatest) When unRaid boots, it tries to detect a 80-wire cable, fails (obviously), and selects UDMA/33 mode for that disk. Oct 15 22:46:37 Tower kernel: Uniform Multi-Platform E-IDE driver Oct 15 22:46:37 Tower kernel: piix 0000:00:1f.1: IDE controller (0x8086:0x24cb rev 0x02) Oct 15 22:46:37 Tower kernel: piix 0000:00:1f.1: IDE port disabled Oct 15 22:46:37 Tower kernel: piix 0000:00:1f.1: not 100%% native mode: will probe irqs later Oct 15 22:46:37 Tower kernel: ide0: BM-DMA at 0xfc08-0xfc0f Oct 15 22:46:37 Tower kernel: Probing IDE interface ide0... Oct 15 22:46:37 Tower kernel: hda: WDC WD3200BEVE-00A0HT0, ATA DISK drive Oct 15 22:46:37 Tower kernel: hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4 Oct 15 22:46:37 Tower kernel: hda: host side 80-wire cable detection failed, limiting max speed to UDMA33 Oct 15 22:46:37 Tower kernel: hda: UDMA/33 mode selected Oct 15 22:46:37 Tower kernel: ide0 at 0x170-0x177,0x376 on irq 15 Oct 15 22:46:37 Tower kernel: ide-gd driver 1.18 Oct 15 22:46:37 Tower kernel: hda: max request size: 512KiB Oct 15 22:46:37 Tower kernel: hda: 625142448 sectors (320072 MB) w/8192KiB Cache, CHS=38913/255/63 Oct 15 22:46:37 Tower kernel: hda: cache flushes supported I tried to ovverride the 80-wire cable detection by adding libata.force=short40c to the syslinux.cfg, but the syslog shows "unknown command: libata.force=short40c, ignoring." Tried also other libata boot options, like libata.force=80c but nothing worked. Is there something missing in the way this kernel was built? Because these boot options work on other Linux distros. Or... maybe it is not the libata module, but the ide_core module? It also has a parameter to force the 40 wire cable type to be ignored (which is presumably the one being checked in ide-iops.c) options ide_core ignore_cable=0 (the parameter to ignore_cable is the drive id) Can we enable the ide_core boot options in the next build? Yours, Purko Quote Link to comment
purko Posted October 22, 2009 Share Posted October 22, 2009 On a separate note, I need to report a WARNING message I've been getting in my syslog ever since I upgraded from 4.5.6-beta to 4.5.7-beta: Oct 15 22:46:37 Tower kernel: ------------[ cut here ]------------ Oct 15 22:46:37 Tower kernel: WARNING: at arch/x86/mm/ioremap.c:603 check_early_ioremap_leak+0x48/0x5e() Oct 15 22:46:37 Tower kernel: Debug warning: early ioremap leak of 1 areas detected. Oct 15 22:46:37 Tower kernel: Modules linked in: Oct 15 22:46:37 Tower kernel: Pid: 1, comm: swapper Not tainted 2.6.30.8-unRAID #2 Oct 15 22:46:37 Tower kernel: Call Trace: Oct 15 22:46:37 Tower kernel: [<c04659d7>] ? check_early_ioremap_leak+0x48/0x5e Oct 15 22:46:37 Tower kernel: [<c0120a7e>] warn_slowpath_common+0x60/0x77 Oct 15 22:46:37 Tower kernel: [<c046598f>] ? check_early_ioremap_leak+0x0/0x5e Oct 15 22:46:37 Tower kernel: [<c0120ac9>] warn_slowpath_fmt+0x24/0x27 Oct 15 22:46:37 Tower kernel: [<c04659d7>] check_early_ioremap_leak+0x48/0x5e Oct 15 22:46:37 Tower kernel: [<c0101139>] do_one_initcall+0x4c/0x131 Oct 15 22:46:37 Tower kernel: [<c0458502>] kernel_init+0xff/0x150 Oct 15 22:46:37 Tower kernel: [<c0458403>] ? kernel_init+0x0/0x150 Oct 15 22:46:37 Tower kernel: [<c01032df>] kernel_thread_helper+0x7/0x10 Oct 15 22:46:37 Tower kernel: ---[ end trace e899322917d1c384 ]--- Oct 15 22:46:37 Tower kernel: please boot with early_ioremap_debug and report the dmesg. I have no idea what it means. Purko Quote Link to comment
limetech Posted October 22, 2009 Author Share Posted October 22, 2009 I will be releasing -beta8 Speaking of the next beta, can we possibly include the libata.force patch module in the new build? I have a nice little Norco NS-520 box which has a spot for a 2.5" IDE disk. The disk connects to the motherboard with a 44-pin cable. I put a brand new WD-Scorpio disk in there (the latest-and-greatest) When unRaid boots, it tries to detect a 80-wire cable, fails (obviously), and selects UDMA/33 mode for that disk. Oct 15 22:46:37 Tower kernel: Uniform Multi-Platform E-IDE driver Oct 15 22:46:37 Tower kernel: piix 0000:00:1f.1: IDE controller (0x8086:0x24cb rev 0x02) Oct 15 22:46:37 Tower kernel: piix 0000:00:1f.1: IDE port disabled Oct 15 22:46:37 Tower kernel: piix 0000:00:1f.1: not 100%% native mode: will probe irqs later Oct 15 22:46:37 Tower kernel: ide0: BM-DMA at 0xfc08-0xfc0f Oct 15 22:46:37 Tower kernel: Probing IDE interface ide0... Oct 15 22:46:37 Tower kernel: hda: WDC WD3200BEVE-00A0HT0, ATA DISK drive Oct 15 22:46:37 Tower kernel: hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4 Oct 15 22:46:37 Tower kernel: hda: host side 80-wire cable detection failed, limiting max speed to UDMA33 Oct 15 22:46:37 Tower kernel: hda: UDMA/33 mode selected Oct 15 22:46:37 Tower kernel: ide0 at 0x170-0x177,0x376 on irq 15 Oct 15 22:46:37 Tower kernel: ide-gd driver 1.18 Oct 15 22:46:37 Tower kernel: hda: max request size: 512KiB Oct 15 22:46:37 Tower kernel: hda: 625142448 sectors (320072 MB) w/8192KiB Cache, CHS=38913/255/63 Oct 15 22:46:37 Tower kernel: hda: cache flushes supported I tried to ovverride the 80-wire cable detection by adding libata.force=short40c to the syslinux.cfg, but the syslog shows "unknown command: libata.force=short40c, ignoring." Tried also other libata boot options, like libata.force=80c but nothing worked. Is there something missing in the way this kernel was built? Because these boot options work on other Linux distros. Or... maybe it is not the libata module, but the ide_core module? It also has a parameter to force the 40 wire cable type to be ignored (which is presumably the one being checked in ide-iops.c) options ide_core ignore_cable=0 (the parameter to ignore_cable is the drive id) Can we enable the ide_core boot options in the next build? Yours, Purko I don't know what you are asking for here; if you can provide what .config option you want, I can include it. But isn't it working correctly? That is, you are not using an 80-pin cable and linux is correctly not using it... does the drive not work at all? Quote Link to comment
limetech Posted October 22, 2009 Author Share Posted October 22, 2009 I have no idea what it means. Purko Me either Is this happening just at boot or continuously? Quote Link to comment
purko Posted October 22, 2009 Share Posted October 22, 2009 Is this happening just at boot or continuously? Only at boot. Doesn't bother me much since nothing bad happens that I can see. Thought I should report it though as it sounds kind of nasty -- leaks detected and stuff. 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.