anthropoidape

Members
  • Posts

    96
  • Joined

  • Last visited

Everything posted by anthropoidape

  1. Thanks Joe, I have just disabled the drive in question. It seemed like unRAID struggled to even unmount it; it took a long time. Now the whole system is running more smoothly with it "not installed". I should be able to get it replaced by WD as I only bought it last August, but I will get another drive as well while I wait for the replacement. Thank you for the help. Jason
  2. Thanks Joe. Sorry it took me a while to find the info on copying a syslog. I think I've attached one now. With regards to pending sectors, the unraid smart report facility says: Disk 0/SDA: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 1 Disk 1/SDB: 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 Disk 2/SDD: 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 Disk 3/SDC: 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 Disk 4/SDE: 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 Disk 5/SDF: 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 Disk 6/SDH: 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 Disk 7/SDG: 197 Current_Pending_Sector 0x0032 198 198 000 Old_age Always - 680 I now see that disk 7 is a bit of an outlier in this respect. Am I right to think that the 680 is a bad number? BTW the reason I thought the user share vs disk share thing was relevant is just that it is what prompted me to think that I had an issue with a specific disk (the one automatically chosen by unraid), rather than some other kind of problem causing my file transfers to fail. Then I found with some experimenting that disk 7 seemed to be the culprit. The drive in question is "eligible for replacement" according to WD's warranty website. Advice welcome, this is all outside my expertise. If I have provided the wrong info or provided it the wrong way it's unintentional. Thanks, Jason syslog.txt
  3. Hi, I started having weird stability problems a little while ago, but haven't really had time to do much about it. Basically, failed writes of large files, sometimes but not always. I didn't have any signs of a problem in my syslog so I assumed it was a fault at my desktop's end of things. Messing around a bit I noticed that it happend when accessing the unraid server via user shares, but not via disk shares. In other words if I pasted a file to //tower/disk5/videos/ ... no problem. But if I pasted to a user share, craaash. As of yesterday some syslog data has started appearing... lots of it. Basically the following, repeated over and over and over: Feb 12 13:37:39 Lemur kernel: ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Feb 12 13:37:39 Lemur kernel: ata7.00: BMDMA2 stat 0x80d1009 Feb 12 13:37:39 Lemur kernel: ata7.00: failed command: READ DMA EXT Feb 12 13:37:39 Lemur kernel: ata7.00: cmd 25/00:08:58:12:c2/00:00:c8:00:00/e0 tag 0 dma 4096 in Feb 12 13:37:39 Lemur kernel: res 51/40:08:58:12:c2/00:00:c8:00:00/f0 Emask 0x9 (media error) Feb 12 13:37:39 Lemur kernel: ata7.00: status: { DRDY ERR } Feb 12 13:37:39 Lemur kernel: ata7.00: error: { UNC } Feb 12 13:37:39 Lemur kernel: ata7.00: configured for UDMA/100 Feb 12 13:37:39 Lemur kernel: ata7: EH complete SMART test results: SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: read failure 90% 4680 25953144 # 2 Short offline Aborted by host 90% 4680 - # 3 Extended offline Completed: read failure 90% 4678 54840184 # 4 Short offline Completed without error 00% 4430 - Running unRAID Pro v 4.7 Clearly (I think!) this is a problem with disk7 on my server. Can I make any reliable assumptions about what the problem is? Specifically, should I assume it's the HDD itself (it's actually the newest disk in the system, from about August last year), and needs replacing, or should I troubleshoot more such as by replacing cables etc? Basically I don't want to fork for a new drive if I don't need to, but equally I don't want to mess around looking for phantom problems if it is definitely or almost definitely the drive itself. Any suggestions? Thanks, Jason
  4. Hmm, my unraid box doesn't have a screen. It sounds like I may have a different problem to you in that if I just move files internally on the unraid drives, everything seems to work (as far as I can tell, not being all that linuxy I just use Midnight Commander via SSH and everything seems to work properly.) My issue seems to be confined to file transfers over the LAN, usually large ones (4+ GB). It's always the same error message on the windows side: "specified network name is no longer available".
  5. I will watch this thread with interest. I have been having a similar persistent problem, but with 4.7. It occurs mainly with large files - a transfer will get anywhere from 30-80% through and then it will fail with the error message "specified network name is no longer available". The unRaid server is in fact working and there is no noticeable problem with it other than the file transfer problem. I thought it might have been at the desktop end of things but I have done some testing this morning and it happens with a number of different PCs at the other end. I have tried it via a switch (Dell 5224) or via only my router (Netgear WNDR3700). Either way it happens fairly consistently. I have sometimes suspected it happens primarily with one user share but I haven't really been able to confirm this with any certainty. I have searched this forum but I haven't really found anything helpful. Are your symptoms similar to this?
  6. Thanks guys, I think you are right and I will leave well enough alone. The NAS does everything I want it to do now. I will use that Pentium D in a PC I am donating to my brother's kids instead. Based on past experience it will take them at least two months to totally trash it so that I have to set it up from scratch again
  7. Hi all, a quick question. I have a working and stable unraid box, currently with 13TB of HDD space. It is running on an AMD64 3000+ and Asus mobo. I have a Pentium D, one of the early dual cores at 3.0GHz, on a Gigabyte 8i945P Pro motherboard, sitting on a shelf from what was once my main desktop machine. I have two questions (and probably more coming). 1. Is the CPU upgrade likely to show a performance improvement in any particular way? I am imagining write speeds might be faster, but on the other hand I wonder if the bottleneck in this system could be HDD r/w speed anyway. 2. Why do I have a vague memory that there is some issue with Gigabyte motherboards and unraid? If the answer to (1) is "not much" then I probably won't bother messing with my stable NAS. Thanks for any suggestions on this. Jason
  8. Has anyone had any luck with this? I would be grateful to get any info on a successful installation.
  9. Goodo! Thanks for the info. Now I know what the issue is I can just wait until an update fixes it. For my situation it is probably not worth upgrading to a beta version in order to get rid of these messages.
  10. I did a bit of experimenting just now and found something interesting. If I open the file using a path such as \\Tower\Company\Meetings\whatever.docx, I can easily trip the setxattr error by manually saving the file, altering and saving it again, etc, to get a line like: Aug 11 15:23:37 Lemur shfs: shfs_setxattr: setxattr: /mnt/disk6/Company/document.doc (95) Operation not supported If I open the SAME file using a manually entered path such as \\Tower\disk6\Company\Meetings\whatever.docx, I cannot reproduce the error (or at least, not in a few minutes of trying). It's physically the same file. I have no clue whatsoever as to why the error should occur via a user share but not via the disk6 type of access, but I hope it might mean something to someone and not just be a red herring. As said this is a low priority thing in that it doesn't cause any problems in practice, still it is one of those things... you know... a "who is in charge here, me or the unraid box?" kind of thing.
  11. Has anyone got any new clues on this? I have tried the samba config ideas related to file locking and for me too they seem to miss the mark. In my case, the syslog entries are all results of Microsoft Office, and occur either with a manual "save" or with autosave. So quite a lot of syslog entries are generated when I have (as I usually do) a good six or more office documents open and active at the same time. All of this work resides on the unRAID box even when I am working with it. As others have said, there doesn't appear to be any actual problem. I simply want a clean syslog! More importantly, it would just be nice to have an understanding of what is going on... or at least to know that someone smarter than me has an understanding of what is going on. I am running unRAID 4.7, with no modifications or anything. Nothing fancy. Here are a couple of example lines (the ..... are letters I've deleted). Aug 11 14:24:06 Lemur shfs: shfs_setxattr: setxattr: /mnt/disk6/P...../Agenda 2011-07-21/440A0E90.tmp (95) Operation not supported Aug 11 14:24:06 Lemur shfs: shfs_setxattr: setxattr: /mnt/disk6/P...../Agenda 2011-07-21/Agenda 21 July 2011.docx (95) Operation not supported The puzzle for me (and I hardly know anything about this) is that it looks (to me) like an extended file attributes issue, and it seems like there shouldn't really be any trouble with extended file attributes with any recent form of linux. Cheers, Jason
  12. I should add: yep, bought the drive new, but I am 99.99% sure it has been in a PC with a gigabyte MB at some stage, as there are a few of those floating around here. I hadn't heard of HPA before, it now officially annoys me though
  13. Thank you both. I admit I am a bit puzzled, but to cut a long story short I reset the drive to its native maximum using Seatools, and it has now been accepted as a replacement drive by unraid, so a parity rebuild is underway. It is now showing the same size as the other identical drive. I don't really understand how the drive lost 4 more bytes on the reboot/upgrade to be honest, but I guess it doesn't matter as the drive was clearly undersized (because of HPA?) anyway. Thanks again! Jason
  14. Thank you for the quick reply Peter. The motherboard is actually an Asus K8V-X, would HPA be a potential problem there too or is it just gigabyte?
  15. Hi, I upgraded my UnRaid server to version 4.7 yesterday. I believe I did this properly, just overwriting three files with new versions on the flash drive. The result is an inaccessible unraid server, although at least it seems to be running version 4.7! I have attached a screengrab of the problem, in short it is showing a "replacement drive" even though I made no hardware changes and haven't done so for several months. It also believes the replacement drive to be too small by 4 bytes, even though it's the same drive. It should in theory also be the same size as the other 1.5TB drive next to it, and it isn't. The thing is, even if it is a failing drive I would still like to have the server running with a virtual disk, not just failing to run altogether. Also, I did check that everything was running smoothly prior to attempting an upgrade and it all appeared to be okay. Here's the screenshot: As you can imagine it is really not good having no access at all. None of the drives were full anyway, is there anything I can do here? I will be very grateful for any help. Jason