In the interest of full disclosure, I'm not an expert in unRAID.  I'm not even a user of it, yet.  I've been looking at different NAS systems, and unRAID seems tempting versus something using RAID5 because it doesn't have the whole all-or-nothing property.  But, looking through the manual, FAQ and forums, ease of use is a concern.  Not having used the system its hard to say for sure, but it looks like most standard things are sufficiently easy to do.  However, one thing stood out as I was reading: removing drives.

 

From the FAQ and manual, it sounds like the standard way to remove drives is basically to just take it out and let it recreate the parity drive.  I'm a little confused by this, since it isn't clear what happens to the data on the removed drive.  Is it recovered and stored on the remaining drives using the parity drive, or is it simply lost?  I get the impression it is simply lost.  It seems like it would be awfully nice to automate the process of moving that data to other drives.

 

In addition, that procedure wipes out the parity drive, which is really unfortunate since unRAID's big advantage is that its generally much safer.  But in this case you end up unprotected for a while.  I see there is a procedure provided in the FAQ for doing this without losing parity, but it looks pretty involved.

 

It seems like removing drives should be a fairly standard feature that unRAID should handle as automatically as possible.  Are there any plans to incorporate some type of automatic drive removal method in unRAID 5 that doesn't involve losing parity?

 

I should point out this has been discussed here and here, before the workaround was discovered, and here sort of in passing.  I never know when to resurrect old threads or when to create new ones.  Since those were old and covered other topics I created a new one.

I agree with you that the procedure of removing drives could be improved.  However, as it currently is, it's not too bad:

 

1) Copy all the data off the drive to be removed and onto the rest of the array via Windows Explorer or command line. (can take a long time, depending on the amount of data)

2) Go to the devices page and unassign the drive to be removed.

3) Power down the server and physically remove the drive.

4) Power up the server.

5) Click 'I'm sure I want to do this' then 'Restore' to initiate a new parity calculation. (parity protection for the array is lost at this point, and this will take a long time)

 

The only improvement that I can really see making a large difference is making the remove-a-drive-without-losing-parity-protection procedure that you linked above simpler.

 

Also, removing a drive isn't really a common practice among unRAID users.  Most users choose to upgrade their drives (remove an old one and install a new one in one go), which is a very streamlined and automated process.

 

In the year+ that I've been using unRAID there was only one instance where I chose to remove a drive, and it was so that I could convert one of my data drives into a cache drive (so basically I skipped steps 3 and 4 above and added another step at the end).  If you are paranoid about losing parity protection but don't want to go through the process you linked, all you have to do is run a parity check immediately before and immediately after the process I detailed above.  That will give you some piece of mind that your disks can handle being without parity protection for a few hours.

I had asked for a similar feature and while I agree that normally I wouldn't ever remove a drive. I'm actually in a situation where I might be forced to do so.

 

I have a drive that may be going bad on me. Seagate's advance replacement service now costs $20 which is a fair percentage of a new drive for me so I'm reluctant to spend it on advance replacement as opposed to just buying a new drive to swap out and then sent the bad drive.

 

The problem is that if I wasn't willing to buy a replacement drive *OR* pay the advance replacement fee, I really only have 2 options which aren't appealing to me. Option #1, run without protection until I get the drive replaced. Option #2, copy the data and remove the drive. Option #2 assumes I have enough free space to do so as well.

Sure, I think my suggestion falls completely in the range of ease-of-use.  It looks like a lot of people are sort of continuously adding more and more drives, creating fairly massive arrays.  I'm more of the opinion that once you start 2TB drives to an array, you might as well start taking out ~200GB drives since 1) the size is somewhat trivial compared to the 2TB drives, and 2) it seems like it would be nice to get data off those drives before they start to fail.

 

Forgetting losing parity protection for a moment, as you mention its not that hard to remove a drive.  But, it does either involve either moving files from a client box (which is extra slow), or using the command line via telnet/SSH.  Neither is that hard.  But, removing drives seems like a basic function for NAS, and it seems like that should be controllable via the web interface.

 

But, I do realize that that might be difficult to completely automate.  While user shares mostly work around this issue, unRAID still mostly treats individual drives as individual drives, rather than just an extension of the entire array.  And there's a big advantage to doing that, as it lets you do partial data recoveries in the event of big failures.  But, it's not clear how you would automate the process of moving data off of one drive onto the other drives, particularly if you couldn't fit everything on one disk.  I think you could piggy back on the user share balancing logic to do this, but maybe that would represent a big deviation from the "philosophy" of how you're suppose to interact with unRAID systems.  There seems to be am emphasis on giving users as much control over what happens on the NAS as possible, at the expense of automating certain things.  Maybe it would work to restrict this sort of automatic file moving only for drives that only have user shares on them.

 

When it comes to losing parity protection, I don't know.  Maybe its not that big of deal.  But, I'd be a little nervous going into a long, disk-intensive operation without parity protection.  You're basically going to end up reading all the data on all the disks at once. 

 

 

Neither is that hard.  But, removing drives seems like a basic function for NAS, and it seems like that should be controllable via the web interface.

 

I've had a number of lil nas with raid devices. Anything using raid across the drives did not let you remove the drive. The only time a nas device allowed this is if you were using JBOD.

 

There is a way to remove a drive from the array and keeping parity intact.

This involves destruction of the data on the drive to be removed.

By writing all 0's to the drive, the parity gets XOR'ed out of the parity drive.

Then using the "trust my array" procedure, the drive can be removed and forcefully trusted, thus with the end result of keeping parity intact.

 

When it comes to losing parity protection, I don't know.  Maybe its not that big of deal.  But, I'd be a little nervous going into a long, disk-intensive operation without parity protection.  You're basically going to end up reading all the data on all the disks at once.

 

Sometimes I get the feeling that having parity protection adds a feeling of safety but also adds a level of paranoia or "unsafe" feeling if parity goes away for a short time.

 

Remember the days when hard drives were very expensive that raid was a luxury?

Most of those drives ran well and ran for years.

I've had a number of lil nas with raid devices. Anything using raid across the drives did not let you remove the drive. The only time a nas device allowed this is if you were using JBOD.

 

Fair enough.  I don't think you can remove drives in any RAID5 NAS that I can think of.  But, I put unRAID more in league with WHS, and you can do that with WHS.

 

There is a way to remove a drive from the array and keeping parity intact.

This involves destruction of the data on the drive to be removed.

By writing all 0's to the drive, the parity gets XOR'ed out of the parity drive.

Then using the "trust my array" procedure, the drive can be removed and forcefully trusted, thus with the end result of keeping parity intact.

 

Right.  I saw directions for that in the FAQ.  I'm basically saying it would be awfully nice to automate that procedure.

 

 

Sometimes I get the feeling that having parity protection adds a feeling of safety but also adds a level of paranoia or "unsafe" feeling if parity goes away for a short time.

 

I understand your point.  And, to be fair, I've actually never had a drive fail on me in a way that resulted in data loss.  In fact, in 15 years the only drive that ever failed on me was one that came to me defective exhibited weird behavior immediately (an IBM Deskstar).  I've had some drives start making odd noises, in which case I copy the data over to a new drive and discard the old one, but I've never had one fail.

 

But, at the same time I think some of the instances where you are likely to want to remove a drive are instances where it seems like it would be good to maintain parity protection.  I think abeta gave a perfect example of this.  If one drive is (likely) going bad on me, I'd be a little worried that maybe one of the other drives is going bad too.  And, if I'm going into an I/O intensive operation like a rebuild, I'd be a little worried.

 

But, at the same time I think some of the instances where you are likely to want to remove a drive are instances where it seems like it would be good to maintain parity protection.  I think abeta gave a perfect example of this.  If one drive is (likely) going bad on me, I'd be a little worried that maybe one of the other drives is going bad too.  And, if I'm going into an I/O intensive operation like a rebuild, I'd be a little worried.

 

When people purchase large numbers of drives of the same manufacturer from the same vendor and at the same time, then the chances of multiple drive failure are higher. Drive purchases spread out over a period of time are usually fine unless it is a model or firmware issue.

 

Now to dispel one myth and add validation to the concern.

 

A parity rebuild or check is actually gentle on the drives "If that is the only unit of work going on".

I see many mentions of drive "I/O intensity" or churning concern.

One must consider. Each drive is read in a sequential fashion starting from the early sectors till the later ones.  A. the drive is already spinning. B. The head moves gently in one direction.

 

There is more intensity if you are doing other units of work on the array. Each matching sector from a drive plus parity must be read for the "missing" drive. Reads of other drives will not be affected.

 

If you are doing other work to the array while a parity rebuild/check or virtual  drive is being read/written, then the heads will be moving around to handle the reads/writes.

Drobo allows you to remove drives out of the array as long as you have enough available space. ie. If I have 4 2TB drives less than 2TB of data, I can remove 2 of those drives and it'll automatically protect.

 

Someone already pointed out in another thread that maybe you don't want automatic protect as if something is bad, it could be more destructive as well .

I really don't see what's there to 'automate'.

Just move whatever stuff you want to keep, and put it exactly where you want to put it.

Then zero out the disk.  That's all there is to it.

 

The Drobo moves all of that for me and allows me to hotswap the disk or just pull it outright. Moving all of my data without my intervention back into a protected state is automatic to me.

In general, I wish unRAID was a bit more user-friendly, and that the details of what gets stored where would just get abstracted from the user entirely.  If I end up making an unRAID system, I would exclusively use user shares, and spread them across all the drives (still setting the split level, of course).  As much as possible, I don't want to have to think about the array as 6 separate 1TB drives, but one 6TB array.  My made the above feature request in that light, which I understand seems to at least partially go against the conventional wisdom of unRAID users.

 

And I certainly understand Rajahal's point that drive removal is, perhaps for most users, a pretty uncommon task.  And, I could be persuaded that perhaps there are many other things that are more pressing.  But, I don't agree with purko that there isn't anything to automate here.  As it stands, removing a drive is a fairly involved task, particularly if you want to maintain parity.  In general, I'd say any administrative function that involves things outside the web interface is fairly involved, and given the procedures required, removing a drive with parity certainly qualifies.  I'm not necessarily saying that current methods are that hard, I'm just saying they're extra extra work.  And to the extent possible, I'd rather the software do the work than me.  Keeping my SageTV box working has already become a hobby of of its own due to the level of effort required to maintain and update it.  I'd rather not pick up another hobby of maintaining a NAS box.  At least, not anymore than I have to.

 

I'm sure I could follow the procedures given in the FAQ entry, maybe having to post a question or two on the forums to get clarification on something.  But ideally I wish I wouldn't have to look up anything at all to do that.  I wish I could just press a single button next to a drive in the web GUI, and then physically remove the drive when the web GUI says I can.  Between the user share logic and the parity-protecting drive removal procedure given in the FAQ, it seems like the groundwork for this feature is already done.  It seems like it wouldn't be all that hard to write code that would move things from the user shares on a given drive to the same user shares on other physical drives.  I suppose you'd have to throw an error message if user shares aren't on, or if you run out space on the other drives assigned to a share, but that doesn't seem that complicated.

In general, I wish unRAID was a bit more user-friendly, and that the details of what gets stored where would just get abstracted from the user entirely.  If I end up making an unRAID system, I would exclusively use user shares, and spread them across all the drives (still setting the split level, of course).  As much as possible, I don't want to have to think about the array as 6 separate 1TB drives, but one 6TB array.  My made the above feature request in that light, which I understand seems to at least partially go against the conventional wisdom of unRAID users.

I think most of the users here would argue that they want to know where all of there data is going.  If a drive fails in my array I know EXACTLY what was on it and what I would need to do to get it back.

 

And I certainly understand Rajahal's point that drive removal is, perhaps for most users, a pretty uncommon task.  And, I could be persuaded that perhaps there are many other things that are more pressing.  But, I don't agree with purko that there isn't anything to automate here.  As it stands, removing a drive is a fairly involved task, particularly if you want to maintain parity.  In general, I'd say any administrative function that involves things outside the web interface is fairly involved, and given the procedures required, removing a drive with parity certainly qualifies.  I'm not necessarily saying that current methods are that hard, I'm just saying they're extra extra work.  And to the extent possible, I'd rather the software do the work than me.  Keeping my SageTV box working has already become a hobby of of its own due to the level of effort required to maintain and update it.  I'd rather not pick up another hobby of maintaining a NAS box.   At least, not anymore than I have to.

 

I'm sure I could follow the procedures given in the FAQ entry, maybe having to post a question or two on the forums to get clarification on something.  But ideally I wish I wouldn't have to look up anything at all to do that.  I wish I could just press a single button next to a drive in the web GUI, and then physically remove the drive when the web GUI says I can.  Between the user share logic and the parity-protecting drive removal procedure given in the FAQ, it seems like the groundwork for this feature is already done.  It seems like it wouldn't be all that hard to write code that would move things from the user shares on a given drive to the same user shares on other physical drives.  I suppose you'd have to throw an error message if user shares aren't on, or if you run out space on the other drives assigned to a share, but that doesn't seem that complicated.

 

I understand your request and think it does have some valid points.  I don't doubt it could be useful for some (most of the "inexperienced" users) but I would prefer this to be an option so that I could turn it on or off if I like.

I think it should be a knob that you can turn on/off. Even on the Drobo, there are times I wished it wouldn't try to "help" me so quickly and rebuild  .

 

I also think anything you can do to automate mundane tasks it is always good. ie, Saying there's no automation necessary here is like saying auto spindown shouldn't be there because some people want to know exactly when it spins down, etc.

 

Having a knob means they're not exclusive to each to me and everyone can tailor it to their desires/needs.

 

ETA: IMO, mundane tasks should always be automated. Its what computers and automation is good at 

I think most of the users here would argue that they want to know where all of there data is going.  If a drive fails in my array I know EXACTLY what was on it and what I would need to do to get it back.

 

Yeah, I see the tradeoff there.  But, it seems like you're basically picking a side if you make extensive use of of user-shares.  At least, if you write to a user share.  Your point is well-taken though.  Personally, I think I'd have a hard time remembering what was on each drive, even if I was somewhat careful about having an organized folder structure.  If I really wanted to make sure I could figure out what was lost during a massive failure, I'd probably want something, again, more automated.  (I know probably I lose geek points for wanting everything automated ).  Maybe some sort of list of all files and folders on all drives of the array that is either mirrored on all drives, or saved to a separate flash drive.  It seems like it would be nice to be able to get a listing of exactly what files were lost in the event of a fairly catastrophic failure.

 

I understand your request and think it does have some valid points.  I don't doubt it could be useful for some (most of the "inexperienced" users) but I would prefer this to be an option so that I could turn it on or off if I like.

 

Even if the function was there, its not like you'd have to use.  If someone really cared where things went they could manually copy things off the drive, like you have to do now.  And then, if the user so desired, could use the drive-removal function to remove the drive without losing parity (if they were concerned about that) without having to resort to going through that process manually.  So it seems like this would still be a useful feature even for people that want to exercise that sort of control over where files end up.

 

So, out of curiosity, presumably you either don't use user shares, or you only use them for reads, but not writes.

I think most of the users here would argue that they want to know where all of there data is going.

 

After I configure my user shares, I don't care what drive the data is on.

 

I remember reading somewhere that Tom originally envisioned unraid as a plug-in and forget appliance.  If that's the case, I hope he gets closer to it in v5.

 

The ability to remove a drive with the click of a button would be useful - especially after I hit the maximum 12 drives I can fit in my case and need to start thinking about how to fit more in, or retiring the older ones.  If for some reason the automated method didn't put my files where I wanted, I could always move them to a more appropriate location.

 

From my experience in assisting people when a drive has failed on their server I'd say automatic movement of the data to another disk would be the wrong thing to do in a majority of the cases, for many reasons...

 

1.  A drive being taken off-line does not indicate the drive is bad, just that a single "write" to it failed.  It might be as simple as a loose SATA or power cable to the drive.

2.  unRAID users tend to populate disks in their arrays differently than in other RAID arrays where data is stripped across all available drives.  Many users go to great lengths to have as few disks spinning as possible to keep energy costs down.  For that reason, many will only add a new drive when the others are nearly full.  (In other words, as likely as not, there is not a lot of free space to move data)

3.  In a real failure, I'd much rather be in complete control.  Recently we've run into two different users where parity could not be computed reliably on their hardware.  One turned out to be the disk controller card.  The other is still being diagnosed... It might be the motherboard...  You do NOT want anything automatic moving data around when a failure occurs.  (In fact, since the failed drive is "simulated" by use of parity and all the other drives you don't need to do anything except replace the failed drive as soon as practical)

4. I want to know exactly where my data resides.  I purposely use specific disks for specific data.  If I were to need to recover from a 2 disk failure I want to know exactly what was on them, not guess.  Yes, it would be painful to have to re-rip my movie collection, but that would be far more painful it I first had to figure out what was missing.

 

The steps to move your own data to another drive are not too difficult if that is your desire, but you must use the "disk" shares to do it since the "user-shares" will look exactly the same with a failed drive as with all working.    The "Drobo" is FAR more likely to suffer more in a multiple drive failure.  (Basically, you lose ALL your data on ALL disks)  Perhaps for that reason they move the data off the "failed" drive.

While I generally agree with Joe on the topic of replacing a failed disk, I was under the impression (please correct me if I'm wrong) that this was talking more about retiring older disks.

 

From my experience in assisting people when a drive has failed on their server I'd say automatic movement of the data to another disk would be the wrong thing to do in a majority of the cases, for many reasons...

 

I basically agree.  As brainbone indicated, I was really talking about a method for retiring disks, not for handling disk failures.

And I will concur, it could be more automated to remove a small out-dated-drive, but you would still need to somehow decide where to move the data.  For that reason, it is not as simple as it looks at first glance.

 

Perhaps the best compromise is to make the instruction in the wiki more clear.

I remember reading somewhere that Tom originally envisioned unraid as a plug-in and forget appliance.  If that's the case, I hope he gets closer to it in v5.

 

I find that interesting.  As someone looking at unRAID from a "fresh" perspective, I never would have guessed that.  Documentation is a little sparse, with a lot of issues seemingly dealt with by pointing people to a thread where someone is working through a problem.  There seems to be a preference for manual processes and providing a great deal of control to users, over automated processes.  There's certainly a tradeoff there, and there's nothing wrong with choosing power over ease-of-use.  But, I would have expected a "plug-in and forget" type of appliance to choose something closer to the ease-of-use side of that tradeoff.  I have to admit, I'm a relatively technical person (though, my level of comfort in Linux probably doesn't compare well to many unRAID users), but I feel a little overwhelmed after looking through the wiki, FAQ and forum.

And I will concur, it could be more automated to remove a small out-dated-drive, but you would still need to somehow decide where to move the data.  For that reason, it is not as simple as it looks at first glance.

 

Well, I think I underestimated how much people care where data goes.  Like brainbone, I don't care.  prostuff1 gave a good reason for caring, it just requires more thought than I'm likely to give to a NAS.  If you don't care where things go, then you likely set up user shares such that they will split across multiple drives.  In that instance, the logic behind moving data is basically already done.  Basically, its a lot like removing that drive from each user share, and writing the folders/files back to the appropriate user shares.  unRAID's existing allocation method for writing to user shares would decide where to move data to.

 

Perhaps the best compromise is to make the instruction in the wiki more clear.

 

That might help a little, but it doesn't really address my concern.  I'm sure I could handle the drive removal process as-is, at least if I didn't care about parity protection.  I could probably handle that too, if I was a little careful.  My concern isn't over being able to figure things out.  It's over having to go the grunt work of moving things around manually and following a set of procedures.  Computers are better at following a (mostly) fixed set of procedures than I am.

And I will concur, it could be more automated to remove a small out-dated-drive, but you would still need to somehow decide where to move the data.  For that reason, it is not as simple as it looks at first glance.

 

Well, I think I underestimated how much people care where data goes. 

 

<snip>

 

My concern isn't over being able to figure things out.  It's over having to go the grunt work of moving things around manually and following a set of procedures.  Computers are better at following a (mostly) fixed set of procedures than I am.

I will not disagree with that statement.  Computers are far better at following fixed set of instructions, but FAR worse at reacting to unknown circumstances and problems in hardware it has no control over.

 

As far as people wanting to know where their data is stored... It becomes a much bigger issue when you are trying to minimize the number of disks that must spin up when a folder is accessed.    Yes, you could treat all the disks as one huge virtual disk, but when you start getting 15 or more disks and a large collection of media, it is easier on you and your electric bill to only spin up the few that are needed.

 

As an example, I have a moderately large collection of DVDs in my physical library.  Most are on the server.  Several of the media-players in my home simply give a file-listing of the files in a folder.  They can traverse through sub-folders, but that gets cumbersome since I must first select the file-server on the lan, then the "share", then the movie.  If I had a single "Movies" share the resulting list would be un-manageable as only 15 show on the screen at a time and I have roughly 1000 file names to scan through.

 

To help in the selection of a movie I have created links to my movie files so they show up in the "Movies" share and also in the appropriate "Movies A-D", "Movies E-J", "Movies K-O", "Movies P-S" and "Movies T-Z" shares.  ( I have a script I wrote to perform this step automatically)

 

Each of those presents a fifth of the total listing and is far more user-friendly when know the title we want to watch.    To keep from spinning up ALL the disk drives when browsing a listing I keep each range of titles on as few as possible disks.  I have also balanced the free space among the drives so they all have roughly the same percentage of their total space available as free.  I wrote a script to allocate files to available space and move the files to group them as needed respecting their individual sizes and other content I did not want to move. (data backups of PCs, etc).  When I first set out to run the script it took repeated runs of it over the course of about a week to get all the files into their respective disks from those when I randomly just added them as I added space.  To me, then end result was worth it.

 

Now, when watching a movie, or even browsing through an alpha range, only a few drives spin up.  To me, that is an advantage.  I know what files are on each drive... to me that is another advantage, just in case something goes wrong.

 

Clearly, I have different needs than you.    I've only had to "remove" a drive from my array once in about 4 years... when I was trouble shooting what eventually turned out to be a bad power splitter.  I elected to "remove" the failing drive and rebuild parity on the remaining drives until I could figure out the intermittent  errors.

 

As already said, take an inventory of the number of disks in your house that are not protected by a raid array.    I've got at least 10 or 12 in various devices, laptops, dvr's, etc...  If they can go their entire lifetimes with no parity protection, my array can go for as long as it needs to re-compute parity It is a risk... but so is every other spinning disk in my house..    unRAID is not a replacement for backups of important files... on hard media, physically elsewhere.

 

Joe L.

As an example, I have a moderately large collection of DVDs in my physical library.  Most are on the server.  Several of the media-players in my home simply give a file-listing of the files in a folder.  They can traverse through sub-folders, but that gets cumbersome since I must first select the file-server on the lan, then the "share", then the movie.   If I had a single "Movies" share the resulting list would be un-manageable as only 15 show on the screen at a time and I have roughly 1000 file names to scan through.

 

To help in the selection of a movie I have created links to my movie files so they show up in the "Movies" share and also in the appropriate "Movies A-D", "Movies E-J", "Movies K-O", "Movies P-S" and "Movies T-Z" shares.  ( I have a script I wrote to perform this step automatically)

 

Each of those presents a fifth of the total listing and is far more user-friendly when know the title we want to watch.    To keep from spinning up ALL the disk drives when browsing a listing I keep each range of titles on as few as possible disks.  I have also balanced the free space among the drives so they all have roughly the same percentage of their total space available as free.  I wrote a script to allocate files to available space and move the files to group them as needed respecting their individual sizes and other content I did not want to move. (data backups of PCs, etc).  When I first set out to run the script it took repeated runs of it over the course of about a week to get all the files into their respective disks from those when I randomly just added them as I added space.  To me, then end result was worth it.

 

Sorry to moderately derail, but isn't it a lot easier to just use a different media player that allows you to view more than 15 items on screen at once?  I'm pretty sure XBMC does this, and I believe I have it set to 25 or so items.  How many items you choose obviously depends on how large your TV is.  I also have a lot of movies to browse (maybe 500ish? not sure), but XBMC makes it quite pleasant to do so.  It scrolls at just the right speed where you can read titles as they go by, plus it lets you jump to a particular letter by pressing the corresponding key on the remote (similar to an old school text message interface - press '7' four times for 's', for example).  It also gives you a scroll bar that is operable by the remote, which lets you manually scroll much faster through a large collection.  Press 'right' on the remote to select the scroll bar, then press 'up' and 'down' as normal.

As an example, I have a moderately large collection of DVDs in my physical library.  Most are on the server.  Several of the media-players in my home simply give a file-listing of the files in a folder.  They can traverse through sub-folders, but that gets cumbersome since I must first select the file-server on the lan, then the "share", then the movie.   If I had a single "Movies" share the resulting list would be un-manageable as only 15 show on the screen at a time and I have roughly 1000 file names to scan through.

 

To help in the selection of a movie I have created links to my movie files so they show up in the "Movies" share and also in the appropriate "Movies A-D", "Movies E-J", "Movies K-O", "Movies P-S" and "Movies T-Z" shares.  ( I have a script I wrote to perform this step automatically)

 

Each of those presents a fifth of the total listing and is far more user-friendly when know the title we want to watch.    To keep from spinning up ALL the disk drives when browsing a listing I keep each range of titles on as few as possible disks.  I have also balanced the free space among the drives so they all have roughly the same percentage of their total space available as free.  I wrote a script to allocate files to available space and move the files to group them as needed respecting their individual sizes and other content I did not want to move. (data backups of PCs, etc).  When I first set out to run the script it took repeated runs of it over the course of about a week to get all the files into their respective disks from those when I randomly just added them as I added space.  To me, then end result was worth it.

 

Sorry to moderately derail, but isn't it a lot easier to just use a different media player that allows you to view more than 15 items on screen at once?  I'm pretty sure XBMC does this, and I believe I have it set to 25 or so items.  How many items you choose obviously depends on how large your TV is.  I also have a lot of movies to browse (maybe 500ish? not sure), but XBMC makes it quite pleasant to do so.  It scrolls at just the right speed where you can read titles as they go by, plus it lets you jump to a particular letter by pressing the corresponding key on the remote (similar to an old school text message interface - press '7' four times for 's', for example).  It also gives you a scroll bar that is operable by the remote, which lets you manually scroll much faster through a large collection.  Press 'right' on the remote to select the scroll bar, then press 'up' and 'down' as normal.

I'm currently in the process replacing one of the media players with an Aspire Revo running XBMC.  Just un-boxed an AR1600 yesterday.  Still making sure it works under Win-Xp before replacing the OS. (I actually loaded up the windows version of XBMC initially)  But that still leaves two others in other rooms in the house... perils of being ahead of the curve...  I've been using them for about three years or so... XBMC is very new by comparison, and when you have to replace multiple media players, can be expensive.) 

 

Organizing the data on the server for XBMC to the exclusion of the other media players would NOT make my wife happy.  I still need my alpha range shares, and still want to control where I store my media files. 

I will not disagree with that statement.  Computers are far better at following fixed set of instructions, but FAR worse at reacting to unknown circumstances and problems in hardware it has no control over.

 

I agree.  So its sort of a matter of 1) the likelihood of of things going wrong in a way that requires user interaction, and 2) how much control someone wants/needs to exercise in a given situation to do what he needs to accomplish.  I don't think 1) is really a concern in the case of retiring a drive, but 2) certainly could be.

 

The example you gave makes sense for why you care where data goes.  And prostuff1 gave another example.  I'm sure there are a million more examples that we could come up with.  I wouldn't have thought where data physically gets stored would matter that much to a lot people.  Maybe I'm wrong about that.  In general, I would expect 1) people, in general, would opt for convenience, 2) in most instances, where things are wouldn't matter, and 3) in many instances where it might, there would be better ways of doing things such that it wouldn't matter.

 

Prostuff1's point about knowing what goes missing in the event of a multi-drive failure is a good one.  If I had a better memory, and was more organized than I am, I might be inclined to carefully organize my drives for the very same reason.  I'd rather have directory listings backed-up to take care of that for me (and, I guess that's easy enough to add yourself with a simple script, since you can access individual drives), but for someone like prostuff1 that's probably not worth it.

 

I'm not completely sure how people are using unRAID, but it seems like its really best for archiving stuff- big stuff, in particular, that isn't likely to be modified very often. I'd expect a fair number of things don't really get accessed very often, but are just there in case something bad happens somewhere else (e.g., backup images, and other types of backups).  I'd expect almost everything else is media files, mostly music and video, along with some pictures.

 

This is probably less true with pictures, but in my opinion once you start dealing with large numbers of music or video files finding things by directory isn't so convenient anymore.  I used to do that with music, but quite a while ago I stopped trying to organize them in folders (except to keep albums in a single older), and I let music management software handle the tags and organize it for me.  I understand its harder to do that with video, although SageTV does have some third-party utilities to do similar things.  In these cases, you really end up browsing a database synchronized to your files, rather than browsing a directory structure.  You can do this with SageTV's HD200 (you can browse too, its just slower), but I've heard you can't do that with a lot of other media streamers.

 

I don't really know how user shares end up working in unRAID.  Out of curiosity, if you provide a user share path to a file, will all the drives associated with that user share spin up, or does unRAID know where to find the file without having to search for it?

 

Clearly, I have different needs than you.

 

I think mainly we just have different thoughts on what sort of trade-offs we'd like to make.  Probably our "needs", in the end, aren't all that different.

 

As already said, take an inventory of the number of disks in your house that are not protected by a raid array.    I've got at least 10 or 12 in various devices, laptops, dvr's, etc...   If they can go their entire lifetimes with no parity protection, my array can go for as long as it needs to re-compute parity It is a risk... but so is every other spinning disk in my house..    unRAID is not a replacement for backups of important files... on hard media, physically elsewhere.

 

True, but when it comes to my workstation and laptop, my important data is backed-up in a convenient way.  I might have physical copies of DVDs/Blu-rays around, but I don't consider those convenient backups.  That's particularly true for TV show DVDs, which I rip then encode in Handbrake.  Losing those wouldn't mean I'd lose the data, per se, it just means I'd have thousands of hours of Handbrake encoding to do again.  When I was thinking about getting a ReadyNAS I was considering getting an extra drive as an offline backup for the things that would be a pain to replace.  I was more concerned about a catastrophic data loss with a ReadyNAS than an unRAID server.  But, maybe I should go back to that plan.