garycase

Moderators
  • Content count

    13544
  • Joined

  • Last visited

  • Days Won

    1

garycase last won the day on March 8 2017

garycase had the most liked content!

Community Reputation

45 Good

1 Follower

About garycase

  • Rank
    Advanced Member
  • Birthday 12/22/1947

Converted

  • Gender
    Male

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. There are some Linux synchronization utilities, but I still prefer SyncBack. I'd simply run that from a Windows VM.
  2. I'd definitely seal the hole … electrical tape or duct tape should work fine for that purpose.
  3. garycase

    The Power Supply Thread

    Not sure what you're referring to r.e. "... one 6-pin connector". IF the voltages are correct and you wire them correctly, then yes, you could power one of the cages from that feed. But if there's any doubt, I'd just use a splitter, which you KNOW is providing the right voltages to the right places
  4. garycase

    Reallocated sector count

    With only a single reallocated sector I wouldn't be at all concerned -- especially if the count doesn't in crease. And of course with dual parity you're well protected should the drive suddenly decide to fail. I never replace a drive just because of a small # of reallocated sectors; as long as the count stays static. If it gets higher than I like, but is still a stable number, I'll replace the drive and use the one with the reallocated sectors for storing off-line backups.
  5. Rats!! I just saw this and went to Newegg to see if by any chance it'd still work (18 minutes after midnight PST) ... but it does not. Oh well, I guess that saved me $222, as I was going to buy one "just because" to have it available for my next server upgrade -- not because I actually need it That is (was) indeed a VERY good price for a great case.
  6. There's little notable difference in the write speeds with single vs. dual parity -- so I'd certainly use dual parity. But with either you'll notice a significant drop from what you're seeing without parity. Just how much depends on the speed of the drives. With older drives you might see 30-40MB/s. With very high density (1.5TB/platter) 7200rpm 8TB or larger drives you'll probably see closer to 60MB/s (even better while you're writing to the outer cylinders). To maximize the write speeds with parity you can enable "Turbo Write" => this is actually called "reconstruct write" in the settings, but is often referred to as "Turbo Write" in discussions about the feature. This results in faster writes because there are fewer sequential disk operations needed to write a block of data (in the normal method, the current contents of both the parity drive(s) and the disk being written to have to be read before it can do the write). The disadvantage of Turbo Write is that ALL disks need to be spun up to do a write. It's not a bad idea to turn this feature on while you're initially filling your array; but you may not want it on all the time, so an occasional write doesn't spin up all of your disks.
  7. Very interesting. I don't know why Lian-Li doesn't make that case anymore -- it was a GREAT case, and the cooling with the door-mounted fans was superb. But the D800 is certainly a great alternative -- and can hold a lot more "stuff"
  8. You'll love that case -- I've worked with a LOT of cases, and for a large system build there's nothing that comes close except for a another long-discontinued Lian-Li case (PC-80B) which was a superb case for up to 20 drives. But the D600 has even more capacity and clearly is very easy to work in due to the cavernous interior
  9. Perhaps even a bit of overkill in that regard ... I'd also do a bit of measuring and buy some shorter cables.
  10. I tend to agree that drives can last a VERY long time if they don't have any infant mortality issues. The vast majority of drives I replace aren't due to drive failure -- it's to bump up the capacity or replace them with SSDs. I've got a boxful of spare drives (a few dozen) that all test perfectly, but are simply smaller than I'm ever likely to use.
  11. garycase

    User Share Copy Bug

    The "absolutely paranoid and don't want to take ANY chance on losing data" approach to this is to be CERTAIN that the data you plan to move around is BACKED UP on another system But as already noted, as long as you understand how to avoid the issue there shouldn't be any problem with your copies. If you have ANY doubt that you're doing it right; copy ONE file first (being certain you have a backup of that file on another system) ... and confirm that all worked well.
  12. garycase

    My SuperMicro Build

    Looking good => amazing what nearly tripling your airflow (38CFM -> 110CFM = 2.89) does for keeping things cool
  13. garycase

    My SuperMicro Build

    I've looked at a few E-ATX boards over the years; but have always shied away when actually buying simply because of the limits it places on what cases I could use. But if you're building a dual-CPU system you really need to go with E-ATX simply because of the extra space you need to accommodate the CPU's and the other "stuff" you'll want on the board (plenty of memory slots; expansion slots; etc.). I'm not sure just what your issue is, but I don't think it's because the board is E-ATX
  14. garycase

    My SuperMicro Build

    I would really think your current heatsinks should be okay -- but it IS true that the larger fans you referenced have a LOT more airflow than the ones on your current heatsink -- 110CFM vs 38CFM. Moving that much more air would certainly provide better cooling. But I really think re-mounting the heatsinks might be all you need to do [or course if you switch heatsinks you'll be doing that for sure ] Adding the middle row of fans may also provide a big improvement -- clearly it will add a lot more airflow. As I noted earlier, be sure to check the CFM rating for all of your fans and see just how much air they should be moving -- if you're using low-rpm fans that only move ~40CFM that may be the primary issue.
  15. garycase

    Turbo write

    There's no reason you couldn't do that; but why? Turbo-write is generally used to get the quickest possible writes directly to the array, so your data is immediately fault-tolerant and doesn't have to go through the cache. Since you're caching all your writes, then the amount of time it takes to do the actual writes to the array is "hidden" from you anyway, since from the user's perspective that data has already been written to the array. In most cases, those writes are also automatic ... that's the whole idea of the mover script. ... nevertheless, you can simply turn on turbo-write; initiate the mover; and then later just turn off turbo-write.

Copyright © 2005-2018 Lime Technology, Inc.
unRAID® is a registered trademark of Lime Technology, Inc.