garycase

Okay, what you've described is this: (a) Wake the PC via WOL (b) Wait for it to sleep © Press power switch and the PC will do a hard reboot instead of waking up. Is that correct ?? If so, then see if this does the same thing: (a) Wake the PC via WOL (b) Wait for it to sleep © Wake the PC via WOL ... and see if it also does a hard reboot If so, then clearly (b) isn't actually entering sleep mode, but is simply killing power ... which is, correctly, being seen by UnRAID as an unclean shutdown -- whence the automatic parity check. Assuming this is the case, then either your motherboard (or one of your add-on cards) isn't supporting S3 properly; or some setting has changed in the BIOS relative to sleep. One thing I'd do before "messing" with it is change your motherboard battery (probably a CR2032) ... but in case the issue is simply that your CMOS settings aren't being preserved due to a failed battery.

Agree ... the main driver in how much power you need is the potential spin-up current for a fully loaded system (e.g. 10 drives). The Seagate SMR drives are rated at 2A of startup current, so with 10 drives that's 20 amps => 240 watts of 12v draw for spinning up. Since during drive spin-up a lot of other electronics are likely also drawing their max initial current surges (CPU, GPU, etc.) I'd want at least 75% more current available on the 12v bus. Any high-quality 80+ power supply with a single 12v bus will meet that requirement. For example, this excellent Seasonic can supply 37 amps on the 12v bus: http://www.newegg.com/Product/Product.aspx?Item=N82E16817151124

FWIW my oldest server (full of media) has 16 disks ... parity plus 15 data. 1 of the data disks is 99% full (I keep a few GB free on it, as that's where I keep the ONE file that changes as I update my media ... the DVD Profiler database backup); 12 of them are 100% full (less than a GB of free space on a 2TB drive); and the other 2 have a fair amount of free space [recently updated this server to v6.1.3 and updated parity and these 2 drives to 4TB). ALL of the drives are Reiser ... and as I have no intention of adding additional drives, they will remain that way [since any new capacity will be gained by replacing a 2TB with a 4TB drive]. On the other hand, my test server is all-XFS; and my backup server is mixed Reiser and XFS, since I updated it to v6.1.3 and as I add drives they'll be XFS. Since I DO have "... meticulous MD5s ..." AND a complete set of backups I CAN confirm that there's not been any corruption on my drives ... just did a complete MD5 verification after moving to v6 "just for grins." I doubt very much that Reiser support is going to be removed from any version of UnRAID for a LONG time to come ... and it will be very well tested as they evolve, since a very high percentage of users still have RFS data disks. Certainly nothing "wrong" about migrating disks to XFS ... but I certainly don't think there's any "compelling reason" to do so -- which was the question.

Given the number of folks still on v5 (or even v4.7 for that matter) there's a VERY large number of UnRAID systems that are still using Reiser. As these folks ultimately migrate to v6, that's a lot of RFS disks that will be moved forward. The RFS bug in the v6 Beta (I forget which #) was found VERY quickly and indeed only caused problems in a very specific situation. I'm fairly confident LimeTech will thoroughly test any kernel updates to ensure proper RFS support moving forward -- they simply have too many folks still using Reiser to not do so. Users are FAR more likely to encounter the infamous "user share copy" bug -- which results in total data loss -- than a bug in Reiser support. Indeed, I've seen a LOT of folks lose data in the past year because of that bug, which they encountered as they were trying to migrate their data from Reiser to XFS disks !! I think there's been enough publicity about this that it's relatively unlikely now -- but as I noted above, there's simply no compelling reason to change. ESPECIALLY if the Reiser disks are full and are effectively "read only" ... which a lot of them probably are in existing media servers. Notwithstanding that, I agree that NEW disks added to an array should be formatted with XFS. But if you then want to move data off of an older Reiser-formatted disk, be sure you do it VERY cautiously and that you understand the details of the user share copy bug ... otherwise you'll lose all of the data !!

You'll likely get other opinions, but IMHO there is NO compelling reason to change your current drives to XFS. I'm certainly NOT doing that with any of my old Reiser-formatted drives.

What's unusual is that it ever wakes from the reset switch => the POWER switch should wake it, but the reset switch should actually reboot the PC regardless of its state.

This is true of course ... but that effectively shuts down the array for the duration of your pre-clears => which, with modern drives (and 2-3 passes) could easily be several days. Not, in most cases, a very desirable way to go. One of the key benefits of pre-clearing is you don't have an unavailable array during a clear operation.

There was indeed a lot of discussion about limiting the attached devices ... and as Rob noted, the way it ended up is with the 3 (trial), 6 (Basic), and 12 (Plus) device limits. Limetech did eliminate the 25 device limit for Pro ... so folks with maxed out systems who have a few spare ports for other uses (e.g. pre-clears and/or occasional attached drives that are "outside" of the array) won't encounter any limits. It can be an occasional nuisance, but it's easily avoided by just upgrading to a Pro key

You'll get a "too many attached devices" message and the array will refuse to start. This limit was imposed starting with v6 => it's 3 devices for the trial; 6 for Basic, and 12 for Plus. The 25 devices supported by Pro WAS initially also a limit for attached devices, but that's been removed.

Depends. If you're running v5, there's no limit on how many physical devices can be attached to the system. If you're running v6, the license limits the number of physical devices you can have in the system UNLESS you have a Pro license.

Just curious what levels you ended up with for the 3 parameters vs. what you started with. That's a VERY nice improvement in speed !!

Just to be clear ... did you change the port to 587 ?? ... one other thing: I don't think anything changed that would impact this, but nevertheless I'd upgrade to 6.1.3 just so you're on the current version.

Yes, redundant supplies are very nice. It's certainly true that if we're building fault-tolerant servers, with fault-tolerant memory (ECC ... not everyone uses it, but I consider it essential for a server), that it also makes sense to use fault-tolerant power supplies Unfortunately they aren't generally available for desktop form-factor cases ... and we don't all have racks for rack-mount equipment.

Very nicely done -- this is something that I've often wished for.

If you think there's ever a chance you may want to update your processor, I'd go ahead and update to the newest BIOS now ... there have been several versions since the Jan 2014 version [You apparently have v1005; since then there's been 1006, 1008, 2001, 2002, and the current 2003]. The newer versions support the additional Haswell processors that have been released; improve memory compatibility; and provide better support for large drives. Since you don't normally have a display & keyboard attached to the server, it's not a bad idea to go ahead and do the update while you've got them set up. The BIOS has a built-in update capability (EZ Flash 2) ... you just need to have the update file available on a USB flash drive (I believe it has to be formatted with FAT-32).

VERY nicely done !! Thanks to both you & BubbaQ

Looked at the manual for your motherboard => in section 2.6.1 it shows the CPU Configuration options in the BIOS. It does not segregate vt-x and vt-d support; but it does show that virtualization support is Disabled by default. I suspect you simply need to enable this.

It almost certainly will NOT be referred to as IOMMU in the BIOS ... Intel refers to this as "Virtualization Technology for Directed I/O" ... abbreviated vt-d. The BIOS will likely have a vt-d enabled/disabled setting.

Should have refreshed before posting

Check the BIOS -- it's likely just not enabled.

Yes, but if you want to do I/O pass-through you'll need to use a CPU that supports vt-d (i.e. a Core i5 instead of an i3) Just check Intel's Ark site for the CPU you're thinking of using to confirm it has vt-d support.

I misspoke in my earlier comment -- not sure if I misread it, or if there was an error on Silverstone's site that's now been corrected => but in any event, the DS380 is compatible with mini-DTX boards (NOT DTX boards). The mini-DTX form factor is 8" x 6.7" The motherboard you'd like to use is 8.4" x 6.7" ... so without the case in hand, it's impossible to know whether or not it would fit. Perhaps someone with the case could see just how much extra clearance there is beyond their (presumably) mini-ITX motherboard. I'd certainly THINK it will work .. but 0.4" is indeed 0.4" => and if that's too much, it's too much !!

Quite the contrary -- I'm a big fan of the better Corsair units. I do NOT recommend the low-end CX series ... but their TX, RM, HX, and AX units are all superb -- and I've often recommended them in this and other threads.

Hard to say for sure, but looking at the pictures of the V354 on Newegg's site, I'd guess they are indeed the same screws.

As you probably gathered from my last note, the screws on the Q08 side panels are indeed VERY small. It's frustrating that they didn't just use the same little hinge pins they used on a PC-Q25B, where the panel just pushes on or pops off (no screws involved). The Q08 is still a very nice case ... I've used it for several builds, including the most recent system I built for my wife ... but every time I have to remove the side panel I'm wishing it was attached like my Q25B's