garycase

I'd disagree with that => a single seek on a modern disk typically takes 10-15ms (seek plus latency) ... that's 10,000 - 15,000 usec, which is a LONG time at modern CPU speeds. Thrashing between multiple files on the same disk will result in a LOT of those seek delays. The problem is that even if disk I/O and access time is 1/20th of the total time, UNLESS the entire file is read on a single access, that would expand dramatically as the heads had to re-seek to read the next piece of the file. Granted, if the code was modified to read an entire file; THEN hash it; then it might be advantageous to have multiple threads operating on the same disk (as long as there's enough memory to buffer the files being processed) ... but I think it's simply best to limit any given disk to a single thread.

Definitely agree => you do NOT want multiple simultaneous hashing of different files on the same disk. It's FAR faster to do one-at-a-time in this case ... regardless of the number of CPU cores you have.

My parity checks took notably longer going from v5 to v6; and have slowed down a good bit more as I moved from 6.1 to 6.2, and then even more going to 6.3.2. I had assumed this was due to the higher CPU demands of the v6 releases -- and that seems to fit well with most other folks who have reported on this -- those with higher powered systems tend to have stable times; whereas those with older systems (like the two systems I have on 6.3.2) have seen slowdowns. The exception to that is Steven D's dual-Xeon system, as discussed earlier in this thread. I have no idea why his checks are taking longer. Both of my v6 systems are Pentium E6300's. Note that I also have an Atom D525 system, but it slowed down so much with v6 I decided to simply leave it on v5 ... where it performs perfectly. I also have a test system with an i7-4770, which has no issues at all with parity check speeds ... but that also gets redone a good bit, depending on just what I'm using it for on any given day. I've been tempted for at least a year to build a high-end Xeon-based setup to replace one of my older systems, but they work so well, and I have SO many computers around the house already, that I really can't talk myself into it (at least not yet).

Welcome back Paul. Hope the health issue has been fully resolved. My wife has had 6 surgeries in the past 3 years, so I can definitely relate ... and I had a nearly fatal bout with pneumonia about 3 years ago that was pretty scary. But definitely good to see you're "back in the saddle" -- and as Rob noted, I'm sure once you start pedaling, the skills will come back quickly. Definitely agree, however, that it's good you documented things in writing => there have been MANY times I've wished I had done a better job of that

While that may have a bit of impact; I assume it's been like that all along; so it still doesn't explain why the checks are taking longer with the newer versions. Until you posted, I had simply assumed it was the higher CPU demands of the v6 releases -- but clearly your system doesn't support that conclusion.

Definitely surprised -- dual 2670's score 18353 on PassMark -- my Pentium E6300 scores 1701. So clearly you have PLENTY of "horsepower". I'd have not anticipated ANY slowdown in parity checks with that setup. I presume you haven't made any changes in the disk controllers, memory, or anything else that might have impacted this.

Interesting. I had assumed that my slower times were due to the relatively slow E6300 -- although candidly it should still be plenty fast enough to compute parity in real time (especially on my single parity system -- I have two E6300-based setups, one with single; one with dual parity ... and both have become notably slower with the newest versions). But I'm surprised a dual Xeon setup would have this issue. What model Xeons?

Even slower, but not by a lot. Took about 12 minutes longer with 6.3.2.

It is indeed a low quality PSU that I would generally not recommend, but if it's working well for you then there's no urgent need to replace it. But with a Xeon, an add-in graphics card, and a growing complement of disks, you may indeed want to consider moving to a higher quality unit the next time there's an attractive sale on a high-end Seasonic or Corsair unit. Both Newegg and Amazon have fairly frequent sales on some excellent units.

While I'm continually surprised that folks consider their data important enough to built fault-tolerant servers, but not important enough to back up, it's clear that many people are in this situation. Assuming your data is at least "somewhat" important to you, I wouldn't break parity when it's not really necessary. In your case, I'd first upgrade your parity drive to 6TB; then do one of the following, depending on whether or not you have a spare SATA port: I. If you have a spare SATA port ... (a) Add a 6TB drive, formatted as XFS. (b) Copy all of the data from two of your 3TB drives to the 6TB drive (verify those copies); then format the 2 3TB drives as XFS. (c) Now, one-at-a-time, replace the two empty 3TB drives (the ones you just formatted as XFS) with your other 2 6TB drives -- the rebuilds will take several hours; but when this process is completed you'll have two empty XFS-formatted 6TB drives. (d) Copy all of the data from your other Reiser drives to the 2 6TB drives you just added to the array; then format those drives as XFS. Done . At this point your entire array is XFS, and you have 4 6TB drives and a couple smaller drives in the array. You may want to use one of your 3TB drives to replace the 1TB drive. II. If you do NOT have a spare SATA port ... (a) Replace your 1TB drive with one of the 6TB drives. Note that this will still be a Reiser disk after the rebuild. (b) Copy all of the data from your 1st 3TB drive to the 6TB drive; then reformat that 3TB drive as XFS, and then copy the data back to it. (c) Repeat Step (b) for another 3TB drive. When this is completed you'll have 2 3TB drives with their data intact and in XFS format. (d) Now, one-at-a-time, replace the 2 3TB drives that are in XFS format with your other 2 6TB drives. This will take a long time; but when it's done you'll have 3TB of free space on each of those drives. Copy all of the data from your Reiser 6TB drive (the one that used to be a 1TB drive, so it will only have 1TB of data on it), to one of these new drives; and then reformat the Reiser 6TB drive to XFS -- it will now be an empty 6TB XFS drive. (e) Now copy all of the data from your remaining Reiser disks to the free space on your 6TB XFS disks -- and when done, just reformat the remaining Reiser disks to XFS.

No new config required -- but if you DO want to do it, you can still maintain parity, since this is a single parity system. Since parity will be valid when all is done, you can do a New Config (which will let you re-assign all of the disk numbers reflect the content they originally had) and you can check the "Parity is already valid" box, since the only thing you're doing is re-ordering the disks. Note that you can't do this with dual parity, since the order of the disks matters in that case.

Harro => I assume you're clear now that as long as you do operations within the array, parity will always be maintained and valid -- but it will reflect the current state of those operations ... i.e. if you format disk #1, then parity will represent an empty, freshly formatted, disk 1. etc. But data on the cache drive is NOT protected by parity (as you know), so using that as your intermediate repository for data while you reformat a disk means that data isn't protected during that operation. Personally, I'd just do the copy to the other server; then copy back approach -- which means your data will always be parity protected. But there's an alternative that would let you do most of the copies on your server => (a) copy all of the data from one of your 4TB drives to the 2nd server; (b) reformat the 4TB drive to XFS. But don't copy the data back ... instead, copy all of the data from another 4TB drive to the drive you just formatted as XFS; then reformat the drive you just copied the data from as XFS, and repeat this for another drive; etc. ... until all of your drives are XFS. Then copy the data back from the 2nd server.

I don't think he's talking about physically moving the disks -- but moving the data, which will of course maintain parity on both systems. Other than the time involved (which Harro correctly notes is virtually all "computer time" and almost none of his time), it's not a bad way to do this, as it completely eliminates any chance of "messing up" with copies/moves within the same server (e.g. the user share copy bug). The only caveat I'd add is to be sure the copies in both directions are done with verification. It's not the quickest way, but it's a VERY safe way to do the migration -- and considering that there's really no "rush" to change the format I'd be inclined to just do one "set" every few days until everything's migrated [where a "set" is 2 4TB drives and 1 2TB drive, since there's 10TB available for the data on the 2nd server].

Yes, that will do what you want

I'd think this would be true regardless of whether the two involved drives were "fast" or not. Consider ... If you're copying from Drive A to Drive B: (a) With turbo write: Data is read from drive A (1 seek); then to write it to drive B there's another seek on A (moving it away from where you're reading data); seeks on every other drive in the system (to read the data from all other drives and position drive B to the correct sector); then writes to drive B and parity; then (for the next sector/block) a seek back to the correct position on drive A ... and this cycle repeats until the end of the copy. (b) With read/write/modify: Data is read from drive A (1 seek); then drive B and parity seek to the correct destination and their current data is read; then drive B and parity are re-written (NO additional seek). Now the next sector/block is read from drive A, which is already either at the correct position or a single track away from it; and the cycle repeats. Excluding the initial seek to the data on drive A, that results in the following: For (a) two seek delays (one for ALL drives, and one for drive A to get back to where you're reading the data from); a read from all drives; and a write to drive B and parity (resulting in one rotational latency delay). So 2 seeks, 2 reads, 1 write, and 1 rotational latency delay (counting all simultaneous actions as a single action). For (b) One seek delay (while B and parity get to the proper location); two reads (from drive B and parity); one rotational latency delay (while B and parity rotate); and a write to drive B and parity. So 1 seek, 2 reads, 1 write, and 1 rotational latency delay. Note that this does not factor in the drive's buffering -- which would likely help the turbo-write case by eliminating some of the re-seeks back to the data location on drive A ... but nevertheless any benefit of turbo-write is largely offset by the additional thrashing of the heads between the location where data is being read for the copy and where it needs to read the current data as part of the turbo-write parity calculation. There would be a BIG difference if a copy utility was being used that buffered a significant amount of data before doing the actual writes -- but I don't know what Linux utilities do this (or can be configured to do it).

On my system the parity check times are about 25 minutes longer with 6.3 than they were with 6.2.4 -- about a 6% increase. Not a huge difference, but nevertheless frustrating. This is on an older system (Pentium E6300), so I'm sure it's simply a function a higher CPU load. Not surprising that the times aren't different on a more modern system with a far more capable CPU.

No need to be terrified Realistically the only thing you COULD do that would mess things up would be to assign the wrong drive as parity ... and with the new feature that retains the previous configuration except for changes you specify that's VERY unlikely. It's always a good idea to save a screen shot of the GUI showing your current assignments before doing the New Config -- then you can easily confirm your parity assignments are correct before you Start the array with the new settings ... just to be ABSOLUTELY certain you haven't made an inadvertent change.

I'm not THAT interested. Your choice. Last time I spent 5 minutes on a chat to point out how much higher their price was on an item (compared to other sellers), they sent me the item for free as a courtesy (It was only a $15 item)

If you're at all interested in the bracket, I'd do a "chat" with Amazon customer service and point out the insane discrepancy between the Canadian price and the US price. That has GOT to be a mistake !! ... and I wouldn't be surprised if Amazon would sell you one for FAR less.

As long as they're both on the same subnet, that shouldn't be a problem. As long as the UnRAID server is hard-wired, so it "sees" the network okay, the clients can be WiFi with no problem (although, of course, the transfer rate will generally be much lower with a wireless connection).

Actuality it was my work server, if I was home I would do it on the test server, I was expecting some "disk is being used" error, but rebuild was successful, no harm done Definitely gutsy !! And worth a couple purple hearts !! :) I'd have also expected a "disk is being used" error (ala Windows) ... but clearly it just does what you tell it to and the consequences be damned. Fortunately it's a fault tolerant server -- so as you noted, you just have to rebuild the disabled disk.

Tried it on an array disk: Jan 13 17:09:26 Tower8 kernel: sd 8:0:0:0: [sdg] Synchronizing SCSI cache Jan 13 17:09:26 Tower8 kernel: sd 8:0:0:0: [sdg] Stopping disk Jan 13 17:09:27 Tower8 kernel: ata8.00: disabled Jan 13 17:09:36 Tower8 kernel: md: disk3 read error, sector=244317864 Jan 13 17:09:36 Tower8 kernel: md: disk3 write error, sector=244317864 Disk was disabled, so if this is used it must be done with care. Now let me rebuild that disk Agree with Rob => You deserve an "UnRAID Purple Heart". Gutsy to try that on an array disk ... although I suspect this was on your all-SSD test array -- which we all REALLY appreciate you having, as it allows a LOT of testing that otherwise likely wouldn't get done.

Indeed looks like a "safely remove" equivalent ... although I wouldn't want to do it on a disk that was part of a mounted array. Not sure whether or not Linux would warn you in the case or not -- kind of like Windows will refuse to "safely remove" a drive that's actively in use (e.g. your C: drive). But it should work fine as long as you Stop the array first.

Agree -- and if there is such a command I have no idea what it is in Linux. My Windows workstation is the one system I DO use the hot-swap function ... not for any of the operational drives (system, data, etc.); but to connect or disconnect drives I either want to write data to (e.g. my offline backup drives) or a drive I want to test (using WD's Data Lifeguard). And in those cases I ALWAYS use the "safely remove" function before disconnecting the drive.

Any 1U supply is going to have relatively noisy fans due to their small size (and thus high RPM needed to move a good volume of air). The following unit has a thermally controlled set of dual fans, so will most likely be fairly quiet most of the time, since your system will typically use a very low % of the power supply's capacity. Unfortunately the manufacturer doesn't provide any noise level specifications, so it's impossible to know the actual level without simply trying it. http://www.newegg.com/Product/Product.aspx?Item=9SIA00Y42U9499