hey there!

 

new to unRAID, and making the last considerations, before having the new server ready und starting this baby up.

 

Parity Drive characteristics

 

what characteristics are more beneficial for the parity drive?

raw read/write speed? random seek speed?

 

i'll have 5x 6 TB WD Red Pro as Data Drives, later on probably additional 8x 4 TB WD Reds (now in another RAID). i'm now wondering, if it's a better bet to get another WD 6 TB Pro as parity drive, or going with an Seagate Archive 8 TB v2 (128 MB Cache, 150 MB read/190 MB write speed)?

 

---

 

Share Limits

 

one of the tasks the unRAID will be used for is for remote backups. that means massive amounts of files (and therefore terrabytes of data on several drives). now all this runs beautifully on Apple Mac hardware with hardware-raid 5 and the trusted hfs+ journaled filesystem for years.

 

well, when this new server starts its duty, it has more hdd space then the old, more ram, more cpu-power but is obviously linux based (unRAID) and uses samba (maybe also AFP) for it's network filesharing protocol and XFS as the file system. but, the backup-server (still Mac) will access (one or several shares) via Samba- or AFP-protocol and do it's heavy duty remote backup procedure (lots and lots of comparisons in file-/folder structures and then the necessary read/write operations).

 

how well deals unRAID with massive amounts of files stored in shares and them being accessed over the local network (all gigabit-speed, fast switch, etc.)?

how does the amount of files in shares impact negatively the startup time of the array (lets talk of at least 500.000 files per share)? does it makes sense to have a share per customer and keep the amount of files inside as low as possible?

 

---

 

has anybody running a setup with really lots of files, small/big and >300.000 (in one share)?

how are your experiences with access times over network from another machine?

 

 

thanks alot for your thoughts.

 

 

I use my unraid to backup all my macs (4) via time machine. Never tried it with a single share though. I use a separate share for each backup and haven't had any issues for the past year or so. Can't say I've ever actually measured the mount times but there never seemed to be much of a delay.

I'd definitely go with another WD Red Pro for parity.    The shingled Seagate works well for most UnRAID usage patterns, but with multiple shares being simultaneously used you could easily hit the persistent cache limit on the SMR drive -- which would slow things to a VERY slow crawl.    And since none of your drives are going to be > 6TB, there's no reason to use a parity drive larger than that.    The WD Red Pro is an excellent drive -- 1.2TB/platter areal density, 7200rpm, etc. ... and will be an excellent parity drive.

 

I'd definitely go with another WD Red Pro for parity.    The shingled Seagate works well for most UnRAID usage patterns, but with multiple shares being simultaneously used you could easily hit the persistent cache limit on the SMR drive -- which would slow things to a VERY slow crawl.    And since none of your drives are going to be > 6TB, there's no reason to use a parity drive larger than that.    The WD Red Pro is an excellent drive -- 1.2TB/platter areal density, 7200rpm, etc. ... and will be an excellent parity drive.

 

thx. garycase. i do appreciate your insights here.

 

well, mostly i'll see much more read operations at a time (comparing source = remote vs. destination = unraid), and fewer but steady writes (the differences will be pulled and written to disk). anyway, will go with another WD Red Pro drive here.

 

I use my unraid to backup all my macs (4) via time machine. Never tried it with a single share though. I use a separate share for each backup and haven't had any issues for the past year or so. Can't say I've ever actually measured the mount times but there never seemed to be much of a delay.

 

thx. for your input. got a few questions here:

 

do you use a physical disk per share for best performance?

for how long do you already do time machine backups into these shares?

how many files are stored into such a share already?

could you have a look/check, how long it takes for the mac to mount it's time machine share?

 

Good choice.  The Seagate 8TB archive drive actually works very well in UnRAID [Detailed thoughts/experiences here:  http://lime-technology.com/forum/index.php?topic=39526.0 ] ... but unless you're going to use them as data drives (and thus need an 8TB parity unit) there's no real reason to use one.    The 6TB Red Pro will actually outperform the Seagate.

 

Seagate has, however, done an excellent job of mitigating the limits of the shingled technology ... and the drives work much better than anticipated in UnRAID applications, where a high percentage of the activity is reads (where the shingled technology doesn't matter), and most of the write activity is fairly large consecutive file activity (thus the persistent cache very nice "hides" the SMR limitations).

 

But with 6TB data drives, you definitely want a 6TB parity ... otherwise your parity checks would spend a few hours "checking" the unused 2TB on the parity drive.

 

But with 6TB data drives, you definitely want a 6TB parity ... otherwise your parity checks would spend a few hours "checking" the unused 2TB on the parity drive.

 

hmm… i would have thought, that unRAIDs logic behind parity check would only check up to the biggest sized hdd in it's array (or even just the max. used space [highest sector] on that biggest drive), no?

 

I use my unraid to backup all my macs (4) via time machine. Never tried it with a single share though. I use a separate share for each backup and haven't had any issues for the past year or so. Can't say I've ever actually measured the mount times but there never seemed to be much of a delay.

 

thx. for your input. got a few questions here:

 

do you use a physical disk per share for best performance?

for how long do you already do time machine backups into these shares?

how many files are stored into such a share already?

could you have a look/check, how long it takes for the mac to mount it's time machine share?

 

I've seen a few recommendations to use a single disk for each share, but it seemed like a bit of a waste to me and it was easier just to use the complete array (no cache). I just set a limit to the share size for each one. I've been using these shares for about a year or so. I can probably get a rough idea of the mount time later this weekend.

 

---

 

Looks like about 30.5 seconds to mount.

But with 6TB data drives, you definitely want a 6TB parity ... otherwise your parity checks would spend a few hours "checking" the unused 2TB on the parity drive.

 

hmm… i would have thought, that unRAIDs logic behind parity check would only check up to the biggest sized hdd in it's array (or even just the max. used space [highest sector] on that biggest drive), no?

 

No.  The parity check continues through the end of the parity disk, regardless of whether or not there are still other drives involved in the check.

 

My experience of using the Seagate 8TB drives as a parity drive is that for parity build/check they actually outperform the 6TB WD Red that I was previously using for that purpose. I think that for this type of operation where one is working serially through the disk the cache on the drives is able to keep them working at a good speed.

 

In normal use I am using the unRAID array to write a relarivly small number of large media files on a regular basis and have noticed no degradation in performance for this sort of use.  I was worried about the fact that with the 8TB drives write performance can degrade if the drives cache gets full but in practise I do not seem to do anything that triggers it.  I think for most unRAID users their use of unRAID is heavily biased towards reading large media files with a comparitevly small amount of writing so they would experience the same results as me.

 

Since the Seagate 8TB drives are cheaper than the 6TB WD drives this makes them an attractive proposition for use with unRAID.

The Seagate drives do indeed work very nicely in UnRAID.  Seagate has done an excellent job of mitigating the potential performance issues of the shingled technology, and as long as your usage pattern doesn't offset these mitigations they'll work just fine.    I outlined these mitigations ... and others have added some real life experience with the drives in UnRAID arrays ... in the thread I referenced earlier:  http://lime-technology.com/forum/index.php?topic=39526.0

 

I'm not surprised that the Seagate drives slightly outperform WD Reds ... they're 1.33TB/platter units compared to the 1.2TB platters of the Reds, and spin at 5900rpm, which is slightly faster than the Reds (which I've seen reported at both 5400 and 5700rpm, so I'm not sure which is accurate).    However, they will still take a lot longer to do a parity check, simply because it takes longer to go through 8TB than 6TB.    AND the WD Red Pro's the OP is using will easily outperform the Seagates -- the Red's 10% lower density is easily overcome by their 22% faster rotation rate.   

 

Looks like about 30.5 seconds to mount.

 

is this the time it takes, when Time Machine starts up on your Mac and you finally see the mounted share appear on your desktop?

if so, could you do a manual mount from the Finder by yourself and time again?

what kind of data do you see on the unRAID share, which you use for TM destination? TM does create sparse image bundle files, which grow in size as backup'ed data increases. is this the case?

 

My observation is, that it takes quite a bit longer until the share appears, if TM is mounting it (probably it does some stuff already in the background…).

 

But with 6TB data drives, you definitely want a 6TB parity ... otherwise your parity checks would spend a few hours "checking" the unused 2TB on the parity drive.

 

hmm… i would have thought, that unRAIDs logic behind parity check would only check up to the biggest sized hdd in it's array (or even just the max. used space [highest sector] on that biggest drive), no?

 

No.  The parity check continues through the end of the parity disk, regardless of whether or not there are still other drives involved in the check.

 

ok, isn't that then useless wasted time? i could be wrong, but checking for parity which isn't needed/used, makes still no sense. (still considering either our previous example of parity drive = 8 TB and biggest data drive = 6 TB / or fill rate of biggest drive not maximum and so way less pure/valid data to protect by parity information).

But with 6TB data drives, you definitely want a 6TB parity ... otherwise your parity checks would spend a few hours "checking" the unused 2TB on the parity drive.

 

hmm… i would have thought, that unRAIDs logic behind parity check would only check up to the biggest sized hdd in it's array (or even just the max. used space [highest sector] on that biggest drive), no?

 

No.  The parity check continues through the end of the parity disk, regardless of whether or not there are still other drives involved in the check.

 

ok, isn't that then useless wasted time? i could be wrong, but checking for parity which isn't needed/used, makes still no sense. (still considering either our previous example of parity drive = 8 TB and biggest data drive = 6 TB / or fill rate of biggest drive not maximum and so way less pure/valid data to protect by parity information).

No it is not.    It is checking that the rest of the parity drive is zeroes so that if you later add a larger pre-cleared data disk than the ones you already have then assuming the parity disk already contains zeroes for the bit beyond what was previously the largest data disk speeds up that process.  Also, if you have increased the size of the parity disk it is likely you are going to start having data disks of that size.

But with 6TB data drives, you definitely want a 6TB parity ... otherwise your parity checks would spend a few hours "checking" the unused 2TB on the parity drive.

 

hmm… i would have thought, that unRAIDs logic behind parity check would only check up to the biggest sized hdd in it's array (or even just the max. used space [highest sector] on that biggest drive), no?

 

No.  The parity check continues through the end of the parity disk, regardless of whether or not there are still other drives involved in the check.

 

ok, isn't that then useless wasted time? i could be wrong, but checking for parity which isn't needed/used, makes still no sense. (still considering either our previous example of parity drive = 8 TB and biggest data drive = 6 TB / or fill rate of biggest drive not maximum and so way less pure/valid data to protect by parity information).

No it is not.    It is checking that the rest of the parity drive is zeroes so that if you later add a larger pre-cleared data disk than the ones you already have then assuming the parity disk already contains zeroes for the bit beyond what was previously the largest data disk speeds up that process.  Also, if you have increased the size of the parity disk it is likely you are going to start having data disks of that size.

 

ok, no offense here, but it is wasted time (in my opinion) as long as it does this exactly every time a parity check is run. if i want to add a larger data disk, i simply need to follow a few steps to make it happen. in case of our example, i could simply run an extended parity check (probably needed to be implemented in unRAID) which would work as you outlined (going to the last sector and check for pre-cleaned "0"s). the waste is twofold: time for doing the additional space check (beyond biggest data drive capacity) & (maybe) offtime of array.

... ok, no offense here, but it is wasted time (in my opinion) as long as it does this exactly every time a parity check is run. if i want to add a larger data disk, i simply need to follow a few steps to make it happen. in case of our example, i could simply run an extended parity check (probably needed to be implemented in unRAID) which would work as you outlined (going to the last sector and check for pre-cleaned "0"s). the waste is twofold: time for doing the additional space check (beyond biggest data drive capacity) & (maybe) offtime of array.

 

It's true that the extra "checking" is doing nothing more than confirming that the parity disk is still all zeroes ... but the simply fact is that's the way it works.    You can argue that it's wasted time ... but it's also wasted $$ to buy a parity drive larger than you need in the first place.    As itimpi noted, if you buy a parity disk of a certain size, it's very likely you're going to use at least some data drives of that size as well ... so you're not likely to do many parity checks that "waste" that extra checking time.

 

There's no such thing as an "extended parity check" => a parity checks always does a full check of parity ... period.

 

BTW, the array is not offline when you're running a parity check => the performance will be reduced during a check due to all the disks being busy ... but in the case of a parity check that's already past the size of the largest data disk, that will only impact write activity.

 

well, well, i got it. no problem here. but as an ex-programmer (long time ago, pure assembler at that time) i'm runnin' in a constant optimization loop. can't do nothing about it 

 

anyway, the idea behind that 8 TB parity drive was pure speculation into the future. nothing more. somewhen then, i'm surely switching to bigger drives, but then, actually no need to think that far. there are other things which need to be done first.

 

thanks anyway for time spent here.

 

maybe some people do still show up on the other part of the topic "Share Limits".

 

... ok, no offense here, but it is wasted time (in my opinion) as long as it does this exactly every time a parity check is run. if i want to add a larger data disk, i simply need to follow a few steps to make it happen. in case of our example, i could simply run an extended parity check (probably needed to be implemented in unRAID) which would work as you outlined (going to the last sector and check for pre-cleaned "0"s). the waste is twofold: time for doing the additional space check (beyond biggest data drive capacity) & (maybe) offtime of array.

 

It's true that the extra "checking" is doing nothing more than confirming that the parity disk is still all zeroes ... but the simply fact is that's the way it works.    You can argue that it's wasted time ... but it's also wasted $$ to buy a parity drive larger than you need in the first place.    As itimpi noted, if you buy a parity disk of a certain size, it's very likely you're going to use at least some data drives of that size as well ... so you're not likely to do many parity checks that "waste" that extra checking time.

 

There's no such thing as an "extended parity check" => a parity checks always does a full check of parity ... period.

 

BTW, the array is not offline when you're running a parity check => the performance will be reduced during a check due to all the disks being busy ... but in the case of a parity check that's already past the size of the largest data disk, that will only impact write activity.

I think the explanation for why parity goes to the end of the parity disk is probably just simplicity. It simplifies the implementation, it simplifies the definition of valid parity, and it may even simplify the user experience.

 

It might be possible to imagine some scenarios where not having parity "valid to the end" would produce unexpected results.

 

For example, suppose you have a disk with file system corruption that will require rebuild-tree.  Then, before it can be fixed, the drive fails and needs to be replaced with a new drive. Since you are going to buy a new drive, you decide to get a larger drive because you already have a larger parity drive. You rebuild to a larger disk, and then proceed to rebuild-tree. If parity is not valid to the end, then some of the bits at the end of the new disk will be effectively random, and maybe that could affect rebuild-tree.

 

Perhaps this is not a good example, maybe my imagination isn't good enough. But I think simplicity can sometimes trump optimization.

 

I'm sure it's exactly that -- the implementation is easier.

 

The contents of a rebuilt disk when the disk is larger than the original disk will be all zeroes -- the expanded space is cleared after the disk is rebuilt -- so what parity has at that point is irrelevant.

 

But the simple fact is that parity IS zeroed in all the unused bits;  and a parity check confirms that those zeroes haven't changed.    Necessary ??    Probably not ... but also not a big deal => it keeps the implementation straightforward; and as has already been mentioned a couple times it's very likely that if you've added an xTB parity drive, you're likely to be adding an xTB data drive in the not-too-distant future