Jump to content

JorgeB

Moderators
  • Posts

    63,741
  • Joined

  • Last visited

  • Days Won

    674

Everything posted by JorgeB

  1. It needs to be patched: https://forums.lime-technology.com/topic/12391-re-preclear_disksh-a-new-utility-to-burn-in-and-pre-clear-disks-for-quick-add/?do=findComment&comment=460592
  2. Those are read/write errors on cache2: Apr 26 10:37:14 Tower kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 Apr 26 10:37:14 Tower kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 00 60 08 a0 00 00 20 00 Apr 26 10:37:14 Tower kernel: print_req_error: I/O error, dev sdb, sector 6293664 Check cables, then run a correcting scrub
  3. Yes, those are normal and similar to what I'm seeing, for some reason the test is not accurate, still doensn't mean the OP doens'h have a problem, but doubt it's a general 6.5 issue.
  4. Yes, and did test just /mnt/user after all activity stopped and got a very low speed, like 20 or 30MB/s, but copying from a desktop I get close to around 90/100MB/s on this server (with turbo write on), so not sure what's going on, but on actual use I don't notice any issues.
  5. I didn't have a lot of time to look into it but I did run the test on one of servers and the write speeds on the test were much lower than the actually writes speed I get copying files, there were some writing overlaps. i.e., it started writing to the next disk while still writing (from RAM) to the previous one, resulting in simultaneous parity writes, @John_Mdo you actuality have a slow write speed to user shares (especially using turbo write) like the OP or it's just the test?
  6. I already mentioned earlier but I didn't notice any slowdown on v6.5 on any of my servers, on some of them I write to an user share @ 150MB/s+
  7. Look fine for now, as long as it doesn't keep getting new reallocated sectors it should be OK.
  8. Question is, is it stable? It uses the same chipset as the SAS2LP, so there could be issues with dropped disks, etc.
  9. That's weird. if anything it should be faster, but I'm not seeing any performance issues whit v6.5 and reads/writes, and I always use /mnt/user, so no idea what the problem is.
  10. If direct IO is disable try again with it enable (Settings -> Share Settings)
  11. It's never a good sign, difficult to say more without seeing the diagnostics.
  12. That means it's on a controller that doesn't support trim. Please post current diagnostics.
  13. Try changing cache slots to just 1, if it still doesn't mount best best is to completely wipe the SSDs previously used as cache with blkdiscard and redo the pool, if you need to save data you can use this FAQ entry.
  14. Yep, that's a problem with rsync, especially on initial sync as it creates immediately all folders on the first available disk.
  15. Better than USB (for single drive at least) but I still wouldn't recommended it, eSATA cables are known to be flaky, and port multipliers are definitely not recommended, glad yours is working well but it's likely the exception, I keep finding users with errors related to port multipliers.
  16. I wouldn't bother, either use larger internal disks or go SAS.
  17. Start by running memtest for a few hours, ideally 24.
  18. It's usually an enclosure problem, but like most already told you USB is a bad idea for array use, even if SMART is passed they usually have very bad error handling, if you need to use external use a SAS enclosure.
  19. Just got the first two, which will be used as parities, since they are larger than current ones, will need to do a double parity swap, not surprisingly they look exactly the same, except the sticker, they also weigh the same, was hoping for a small difference to confirm they actually have different internals, obviously weighting the same doesn't prove they don't, also my scale resolution is 5g, so there might be a very small difference unmeasurable by me, I guess time will tell if they have better vibration protection, though Toshiba recommends theses disks for 1 to 8 bays and they will be used on a 21 disk server, but if nothing else they will have an extra year of warranty. On that note some good news, one of two failed 4TB WD is still under warranty, so not a total loss, before checking the serials I was thinking they were both out of warranty since they were some of the first 4TB disks on that server.
  20. In my case it can't be 24x7 use as these servers are archive only, only on for a few hours every week. I always liked the WD green/blue/reds as they are low power and very low noise, and I still have a lot of them without issues, some older 2TB and 4 and 6TB on servers with fewer disks, but those on the biggest servers, especially 3 and 4TB are failing at an alarming rate, and the problem always start the same, they start getting slow sectors (I start noticing low performance on transfers since I always use turbo write), SMART attribute for Raw Read Error Rate starts increasing and after just a few more hours of use they start having read errors. Since I need to replace those last two disks and I've been having good luck with Toshiba disks (and they are very competitively priced) I'm going to do a dual parity swap and upgrade to larger disks, but I'll be using one X300 desktop drive and one N300 NAS drive, and when I need to upgrade or replace more disks on this server will do them 2 by 2, one from each, so after a few years maybe I'll be able to gather if one is really better than the other for larger server use.
  21. Thoughts? I use mostly desktop drives on my servers, lately I've been having disks failures with some regularity, especially my 3 and 4TB WD green/blues are failing like at least one a month, just this weekend I had a double disk failure on one of my servers on two fairly recent and very low power on hours 4TB WD green drives, I'm starting to think at least these drives don't handle vibrations well, but I also have a lot of Samsung, Toshiba, 2TB WD greens and a few Seagate desktop drives and these have been fairly reliable.
×
×
  • Create New...