garycase

There are a number of different buffers being used here. The buffer cache buffers filesystem and file data. The dentry cache buffers directory entry filesystem data. The md/unraid buffers. From what I know the dentry and md/unraid buffers are in low memory. The do not normally impact one another. If there is no cache pressure, then the dentry cache will exist until the dentry expires. Normally you wont see an impact unless you have so many files (like I did) that they cannot all be stored in the dentry cache. Then the dentry cache starts dropping entries to hold newer entries. As this happens you start reading directories from the disk instead of the hash table. That's when it could impact parity checks. A couple questions ... (a) How many files do you have? [ballpark] (b) How can I tell what the current cache pressure setting is? I read somewhere that UnRAID defaults this to 60 ... is that no longer true?

Thanks. I had assumed as much, but just wanted to confirm that I wasn't overlooking something. If this parity check completes in the same 7:41 it normally takes, I'll be (pleasantly) surprised !! Maybe Cache_Dirs doesn't need to suspend itself after all !! It just SEEMS like all those buffered reads during a parity check would impact the cache buffers and result in a LOT of extra Finds that would thrash the disks a bunch and add a modest number of minutes to the process ... but Robj's results certainly didn't indicate that was the case.

Question for Joe ==> I'm not going to try this while my parity check is running, but if I was to access the share via Windows Explorer to look at the directories, does that cause any activity that might change the impact of Cache_Dirs ?? I'd assume not ... i.e. I should be able to browse the folders with ZERO impact on the ongoing parity test and Cache_Dirs functionality (as long as I don't actually open any of the files) => but am interested in whether you agree.

Okay, I'll post back in ~ 8 hrs with the results. Started Cache_Dirs; gave it 20 minutes to ensure it had ample time to populate the cache; cleared the statistics; did a Spinup all drives; and started a parity check at exactly 10:30 local time. I've done a LOT of parity checks recently, as I "tuned" my parameters ... and it now runs almost exactly 7:41 => so in 8 hours I'll know for sure whether Cache_Dirs has any impact on that time. Just to ensure there's no impact from excessive refreshes of the Web GUI, I don't plan to even look at it until 8 hours have passed

If you like the Lian-Li PC343B, check out the D8000 => basically the same case, but a much "cleaner" front panel without all the 5.25" bays ... instead it's got 20 drive cages that you access by popping off the front panel (it just pulls off) => you can either directly cable the drives; or you can buy optional hot-swap panels that mount in the back of the cages to turn all 20 into hot-swaps. VERY nice case ... by far my favorite for a high-drive-count system in a tower system. And SUPERB cooling ... 6 120mm fans blow air directly across the drives.

Very interesting ... and surprising ... results. I didn't expect a big difference, but I DID expect that it would be better with Cache_Dirs NOT running. It is, in fact, very hard to understand how Cache_Dirs could actually IMPROVE the time !! One obvious factor is how many files you have cached. Is Cache_Dirs set to cache ALL of your files? ... My v5 server has, for example, 270,128 files in 20,651 folders. Your results are definitely intriguing, however => I'm going to start Cache_Dirs, give it a few minutes to populate the cache; and then fire up a parity check to see how it compares to the very-consistent 7:41 it's been taking.

Five minutes sounds okay to me. If the Find loop runs every 10 seconds, that's about 30 iterations in 5 minutes ... so even if every iteration resulted in a 50-100ms "thrash & cache" [directory read] that would only be an extra couple seconds for the parity check. Sounds like the process is a bit more complex than I envisoned ... I thought it could simply be a fixed test for parity check/disk rebuild with two exits: (a) do nothing; or (b) do the next Find. Sounds like you need a completely different loop that tests for an in-process parity check/rebuild and sets or clears a "suspend" flag for Cache_Dirs. If it's easier, I'd be quite happy with a simple button in UnMenu (perhaps on the User Scripts page) that would suspend Cache_Dirs [With, of course, a corresponding one to "un-suspend it" ] Wouldn't be as nice as an automatic suspension, but simple enough to just do it before running a parity check. [Which also makes me wonder why you've never added Cache_Dirs to Unmenu ??]

I was going to do exactly that, but since you've already started it, I'll wait and see what your results are. It can, of course, depend on your tunable disk parameters ... I have mine set to use significantly more buffers during parity checks than the default (which changed my parity check times from ~ 8:25 to 7:41). I do not, by the way, anticipate a major difference in the times ... but I do think it will take longer with Cache_Dirs active; and don't see any reason to have the unnecessary disk thrashing going on when it can easily be avoided.

Clearly the amount of memory in the system; the settings of the various tunable disk parameters; the number of directory entires that need to be cached; any other activity that may be going on; etc. can all have some impact. But a check that simply says "Don't do any disk activity if a parity check is in progress" would certainly be at worst neutral (if no Finds were needed); and at best would stop all Cache_Dirs related disk I/O during the parity check if Finds were necessary to update the directories. All this will do is GUARANTEE that no physical disk I/O will be initiated by Cache_Dirs until the parity check has completed By the way, Joe indicated he's going to also do this for disk rebuilds ... which is certainly a good idea; as these also are other completely sequential I/O operations on the disks, so any unnecessary thrashing will slow them down as well.

Running Cache_Dirs slows down parity checking ... disabling it does not. (see next comment) Indeed, they are two independent operations. But Cache_Dirs definitely DOES do some physical I/O ... whenever the buffers containing the directories are overwritten it has to re-read the directory info. Parity checking is obviously VERY I/O intensive ... reading ALL of the disks as quickly as it can and confirming that the parity is correct. Think of this process ... every disk is read IN ORDER, so there's virtually NO head movement except for single-cylinder seeks as the disk is traversed. A LOT of data is being buffered, so the data buffers that are holding the directory info for Cache_Dirs are clearly going to be overwritten ... and when Cache_Dirs does its next check, it's going to re-read the directory entries to try and keep the buffered directory info up-to-date. THOSE reads are going to require some seeks -- which has two impacts: (1) the disks get thrashed a bit by the extra seek operations; and (2) the time for these reads is added to the parity check time, since no parity checking can be done until it can continue reading data for the check. Note that, while quick, seeks are nevertheless the "long pole in the tent" in terms of disk operations ... i.e. they're VERY LONG compared to all the other things that are going on [10-15ms sounds quick, but when you do it enough thousands of times it adds up]. The same thing is true for ANY ongoing accesses during a parity check. Streaming a movie; writing a bunch of new data; copying files from the array; etc. all cause significant disk thrashing that will notably slow down the parity check time. NOT a particularly large amount of time in most cases, but nevertheless it's unnecessary disk thrashing ... which I like to avoid. [i NEVER watch a movie during a parity check ... or do anything else on the array either] By the way, think about the process: IF you were right and there was NO physical I/O required by Cache_Dirs, then the impact of a check that says "If Parity Check in progress, do not start a Find operation" would be ZERO => since no Find would be required anyway. So all this check does is GUARANTEE that no physical disk I/O will be initiated by Cache_Dirs until the parity check has completed You're absolutely right -- I had a "senior moment" when I wrote that My newest system has all 3TB WD Reds; but my older media server has a mix of 1, 1.5, and 2TB drives and the 1 & 1.5's are indeed spun down by the end of a parity check ... so the first time Cache_Dirs "asks" if a parity check is in progress and the answer's "No", so it starts another Find, those drives will likely have to spin up. Not a big deal ... but definitely a wrong statement on my part !!

Certainly didn't mean to imply "now" ==> just sometime in the relatively near future ... anytime in the next few weeks is fine by me. I'd be nice if you'd post a note when it's done. I'm sure I'm not the only one who'd appreciate that modification.

Does this comment also apply to my note r.e. suspending Cache_Dirs during parity checks? It sure seems that would be a VERY useful/nice feature. Seems like a simple "If parity check in progress, don't start the next Find" check in Cache_Dirs would basically suspend it => at least after the current Find completed. No reason to shut down Cache_Dirs ... it would simply keep checking at the current intervals, but as long as the parity check was in progress, wouldn't initiate any more Finds ... thus not interfering with the check. ... and of course once the parity check was over, the next time Cache_Dirs checked all the disks would still be spinning, so it'd be very quickly up-to-date. It does this today (puts itself to sleep) when the "mover" runs, so adding the logic for a parity check/disk rebuild is fairly easy. I thought it might be. Does that mean you're going to add it and update the Cache_Dirs download?

Does this comment also apply to my note r.e. suspending Cache_Dirs during parity checks? It sure seems that would be a VERY useful/nice feature. Seems like a simple "If parity check in progress, don't start the next Find" check in Cache_Dirs would basically suspend it => at least after the current Find completed. No reason to shut down Cache_Dirs ... it would simply keep checking at the current intervals, but as long as the parity check was in progress, wouldn't initiate any more Finds ... thus not interfering with the check. ... and of course once the parity check was over, the next time Cache_Dirs checked all the disks would still be spinning, so it'd be very quickly up-to-date.

Joe => I have no idea how "doable" this is ... but is there a way to have CacheDirs "suspend itself" if a parity check is in process? Not shut itself down (which would then require re-starting it) ... but just basically ask "Is parity check in process?" before it kicks off the threads to read the directories. Logically it seems like that'd be fairly simple, but I'm just not a Linux guy, so I don't really know.

Probably the easiest option ... in fact, it's exactly the same as the one distributed with RC14 EXCEPT it doesn't have the 4 lines that force the 4GB option. Or just not update the syslinux.cfg at all and leave the one from RC12a or RC13. That's what I did.

Remember that UnRAID is NOT a typical RAID access scenario ... the only times when more than 2 drives at a time are being accessed are (a) parity checks/builds; or (b) if multiple clients are accessing the array at the same time and streaming/using different disks. And if the accesses are writes, and there's a cache drive, then even then it's only one disk being accessed. Bottom line: While any port-multiplier scenario results in reduced bandwidth per/disk, in most cases it's just like Bob outlined for his Windows experience ... and you'll get very good bandwidth. Probably the major "issue" (and whether this is an issue or just a lack of patience is debatable) is that parity checks will take longer

Fine! Very detailed ... I suspect some actual numbers would be a bit more useful !!

Thanks for pointing out the need for a low-profile card. I overlooked that (I don't have one of these systems) ... and I'm surprised Sans-Digital included cards on its list that didn't meet that criteria. As for the 622 not supporting port multipliers .... where did you see that note? I looked at the Newegg link and it's not on any of their descriptive pages, and in fact one of the reviewers noted: "... Wanted a card that supports port multiplication to just access individual drives. It wasn't clear in the specs, at the maufacturer's website, or in the reviews that this card will do anything besides RAID or JBOD, but it works fine ..." That, plus the fact it's on Sans Digital's list of "eSATA Port Multiplier" cards that they reference in their product descriptions would tend to support that it should work! [ http://www.sansdigital.com/esata-port-multiplier/index.php ] Have you actually tried that card?

There are a few cards referenced throughout the thread that should work. The safest approach is to use one of the cards on the SansDigital list of cards known to work with their port multiplier cases: http://www.sansdigital.com/esata-port-multiplier/index.php This inexpensive card is on the list: http://www.newegg.com/Product/Product.aspx?Item=N82E16816115073 ... and would work in the PCIe x1 slot in the enclosure. If your x16 slot is available, this x4 card (also on the list) would give you far more bandwidth -- you could add up to 4 of the enclosures http://www.newegg.com/Product/Product.aspx?Item=N82E16816115036

... just to be clear, my recommendation is that you sell all of your existing RAM and simply a pair of larger capacity modules for each of your systems. If you don't want to do that, then put all 4 of your current modules in one of the systems; go into the BIOS and set the memory voltage to 1.65v; and then buy a pair of 4GB modules for your other system. ... if you notice "random" stability issues on the system using all 4 modules, then either remove two of them; or remove them all and buy a pair of higher-density modules for that system as well.

Yes, you can simply put all 4 modules in the same system and have 8GB using 4 2GB modules. HOWEVER, I don't recommend doing so. Here's why: With unbuffered memory systems, you'll have far more reliable memory if you only install 2 modules. The signal degradation from the bus loading with 4 modules installed can have a notable impact on the system's reliability; and this is especially true with high-performance modules that require higher-than-normal voltages, which both sets of these do [they're 1.65v modules; the standard DDR3 voltage is 1.5v]. I suspect you've been running these at the wrong voltage -- voltage is NOT an SPD parameter, so unless you changed the BIOS to use the correct voltage, you've been running them at 10% undervolt I'd buy a pair of 4GB modules for each system and have 8GB with only 2 modules. This will be more reliable than using 4 2GB modules. Note that the Gigabyte board supports 8GB modules, so if you wanted to you could install 2 8GB modules (total of 16GB) in that system while still only populating two slots. In either case, I'd buy standard 1.5v modules. You don't have an "unmatched pair". You have 4 modules with the same specifications. In fact, you lucked out, as BOTH pairs use a non-standard 1.65v (the standard DDR3 voltage is 1.5) ... so if you DO choose to install them all, you can set the voltage in the BIOS to the correct voltage for the modules. As long as you install the RAM in pairs [i.e. a pair of 2GB modules and a pair of 4GB modules], you're fine IF you're running modules that require the same voltage -- so you'd have to buy 1.65v modules for the 2nd pair. But I don't recommend doing this for the same reasons I outlined in the answer to your first question.

Don't forget that you have to map the USB flash drive to the VM that you're booting UnRAID with. If it doesn't "see" a flash drive with the "UnRAID" label and containing your key then it won't allow anything other than basic (3 drive) functionality.

Just curious -- I doubt I'd bother to change. I DO have a spare SSD (an old 60GB unit), but I also almost never reboot my UnRAID server (current uptime on one is 160+ days; my second one is only 45 days or so, since I recently added another 3TB drive to it and had to reboot). If I powered down daily and was frequently waiting for it to boot, it'd be worth doing; but in my typical scenario it really wouldn't make any difference.

Just to confirm -- that means bizimage and bizroot are loaded from the fast disk; but the config folder is processed on the flash drive; logs are written there; etc. ... right? ... I presume this means a "bare metal" system could be configured the same way => boot off an SSD that contains bizimage and bizroom; and as long as there's a USB flash drive labeled UnRAID everything would still work fine, even though the USB flash drive is NOT the boot device ... correct?

The CoolerMaster 4-in-3 units are superb drive mounts -- they do a much better job of cooling your drives than any hot-swap unit I've tried. Hard to beat a 120mm fan blowing directly on the drives -- no hot-swap unit I'm aware of using anything larger than 80mm; and they're rear-mounted so are "pulling" air at an offset ... definitely less effective. Having said that, the hot-swaps DO keep the drives "cool enough".