These options don't exist with most other raid solutions so I come back to unraid time and time again.

 

Just for info FlexRaid and Snapraid will both do the same thing. They differ from unraid in other areas but all allow individual drive recovery / don't touch the data drive contents allowing them to be easily remounted elsewhere.

Just for info FlexRaid and Snapraid will both do the same thing. They differ from unraid in other areas but all allow individual drive recovery / don't touch the data drive contents allowing them to be easily remounted elsewhere.

 

Cheers! Snapraid is a new one on me.  Have you used it?  What's the product like?  What is the community like?

 

I used snapraid for testing and submitted a few bug reports.

 

It works ok. The drawback for me is that it is literally what it says on the tin - if you also want storage pooling you'd have to do something else. And there aren't that many solution that are as good (or perhaps I should say easy) as the unraid user share system or flexraids storage pooling. mhddfs is the usual one trotted out but it falls short in some areas IMO.

 

At which point snapraid starts to look less appealing as to replace unraid it would need combined with 'something else'. Especially when the elephant in the room is Flexraid which does ship a raid engine and pooling implementation in one package - although last time I tested it (which was a while ago granted) I could break it within 5 seconds.

 

Snapraid does work though (the odd bug but they're being fixed), there are suggestions performance could be better but I believe that is also being incrementally worked through.

 

The community seems to basically be the sourceforge forum which isn't great - but the developer is active and responsive to queries there.

 

And the bottom line is that it is fully open source and the code looked pretty reasonable to me. The bugs I reported I would actually have been able to fix myself which is always a fair sign that if even I can manage to understand the code well enough to do that then it's been written quite clearly!

 

Updated to add that as Snapraid can now apparently support symlinks properly, using it in conjunction with greyhole might be a very interesting approach to solve drive pooling : http://sourceforge.net/projects/snapraid/forums/forum/1677233/topic/4661219

 

Topic Split from

Has Unraid stagnated due to lack of support and communication from Limetech?

mhddfs is the usual one trotted out but it falls short in some areas IMO.

 

Can you elaborate more on this?

 

I'm not fond of the shfs on unRAID and was considering this layer.  I would love to know your findings, pros/cons.

 

My beef with shfs is even if I configure a share to limit access to one or two disks. When I access it, it spins up every disk searching for the directory.

This causes me to spin up 19 other disks when I'm only accessing one share that I know is on disk1.

 

The concept of keeping all inodes in memory via repetitious finds does not work on my system since I have so many files. There are inodes/directories that are always flushed out when I do something.

 

This causes me to abandon use of shfs until something else changes.

Did excluding some of those dirs not work for you ?  Also disable spinup groups..

Did excluding some of those dirs not work for you ?  Also disable spinup groups..

 

I used the include field, rather then the exclude field since a number of the shares are only on 1 disk.

Do Flex or Snapraid have support for running sabnzbd or sickbeard?  I guess I could always run these on a separate pc, but I do like the integration that they have with Unraid. 

Do Flex or Snapraid have support for running sabnzbd or sickbeard?  I guess I could always run these on a separate pc, but I do like the integration that they have with Unraid. 

 

They are both modules which go on top of an existing OS whereas the Unraid distribution is both the OS and the filesystem modules on top.  So yep you could install anything you want.

 

For example, instructions on putting Snapraid on an Ubuntu 12.04 installation: http://www.havetheknowhow.com/Configure-the-server/Install-SnapRAID.html

mhddfs is the usual one trotted out but it falls short in some areas IMO.

 

Can you elaborate more on this?

 

I'm not fond of the shfs on unRAID and was considering this layer.  I would love to know your findings, pros/cons.

 

Split levels basically. mhddfs keys primarily off drive with the most free space. Which means you can't attempt to group or control 'sets' of data to individual disks to prevent excess spinups.

 

Flexraid, I believe, does have a similar concept to split levels in it's own pooling software though I forget what they call the feature.

 

Some caveats to this

 

- I might be wrong. mhddfs might support more options but that was the issue I hit up against.

 

- You may not care, I appreciate some people use user shares more as a single read location whilst controlling writes to specific drives themselves manually.

 

- It could be a non-problem given drive sizes these days, there is a good chance we're moving towards having less but higher capacity drives as time goes on. Therefore worrying about lots of drives spinning up becomes less of an issue.

 

- Likewise there is no rebalancing of data in unraid. So split levels work perfectly and as described - until you run out of space on a disk and then they don't. At which point you have to manually intervene and shuffle data yourself in the backend anyway (unless I've missed something that would make my life much easier!)

 

aufs can also do a single namespace but I'm not sure it does anything better to fix the lack of split level and I found it's config and docs quite complicated.

 

My beef with shfs is even if I configure a share to limit access to one or two disks. When I access it, it spins up every disk searching for the directory.

This causes me to spin up 19 other disks when I'm only accessing one share that I know is on disk1.

 

The concept of keeping all inodes in memory via repetitious finds does not work on my system since I have so many files. There are inodes/directories that are always flushed out when I do something.

 

I don't have this problem using the partnership of split level and the cache_dirs script. Or should I say I don't always have this problem. Sometimes I see spin ups where I wouldn't expect it but on the whole things behave as I'd hope. I presume the random spinups depend on the memory pressure from other things happening on the server at the time.

 

Though as you say it does hinge on your file density and memory. When I refreshed my server I shoved in much more memory to help with this - but again appreciate this may not be a good answer for everyone.

 

I don't know if mhddfs would do any better with regards to this, I don't think it does anything clever with metadata but could be wrong. It would be nice for unraid to support a filesystem that allows metadata to be stored on a seperate / specific disk. Not sure what does outside of the enterprise - btrfs might but then it's overall reliability could be a problem!

 

 

My beef with shfs is even if I configure a share to limit access to one or two disks. When I access it, it spins up every disk searching for the directory.

This causes me to spin up 19 other disks when I'm only accessing one share that I know is on disk1.

 

The concept of keeping all inodes in memory via repetitious finds does not work on my system since I have so many files. There are inodes/directories that are always flushed out when I do something.

 

I don't have this problem using the partnership of split level and the cache_dirs script. Or should I say I don't always have this problem. Sometimes I see spin ups where I wouldn't expect it but on the whole things behave as I'd hope. I presume the random spinups depend on the memory pressure from other things happening on the server at the time.

 

Though as you say it does hinge on your file density and memory. When I refreshed my server I shoved in much more memory to help with this - but again appreciate this may not be a good answer for everyone.

 

I don't know if mhddfs would do any better with regards to this, I don't think it does anything clever with metadata but could be wrong. It would be nice for unraid to support a filesystem that allows metadata to be stored on a seperate / specific disk. Not sure what does outside of the enterprise - btrfs might but then it's overall reliability could be a problem!

 

I do realize the caching issue is mine because I have so many files on the system. I think my beef is that the other disk are consulted even though I have includes which means to me, stay on that disk alone. If the other disks were never consulted there would not be an issue.

 

shfs doesn't work for me at the current time. It's not a big deal. I have most of my disks and storage areas memorized and for movies.

I have something like the old norton change directory with tagged directory names for shell navigation and moving files.

I think my beef is that the other disk are consulted even though I have includes which means to me, stay on that disk alone. If the other disks were never consulted there would not be an issue.

And that sounds like a area where shfs can be improved.  (probably not too hard to track the user-shares vs. included/excluded disks when listing a directory.  It is already there for the create file/directory operations..)

 

Submit a bug-report/feature request.

I've been looking at flexraid and it seems to be a viable option for me.  One question though, Would I basically have to build a flexraid system and transfer all of my unraid data to it, or would it be as easy as putting the unraid physical hard drives into the flexraid unit?  I am figuring it would be the former, but hoping for the latter

I've been looking at flexraid and it seems to be a viable option for me.  One question though, Would I basically have to build a flexraid system and transfer all of my unraid data to it, or would it be as easy as putting the unraid physical hard drives into the flexraid unit?  I am figuring it would be the former, but hoping for the latter

 

You should be able to read the unraid disks with no problem so long as your new system can read the reiserfs filesystem. That may exclude windows - but linux should be fine.

 

You could then just mount the drives as normal and configure flexraid to use them as data units and configure your old parity as the new ppu inside flexraid. Flexraid works at the filelevel, not the block level like unraid.

 

You'd be stuck with reiserfs for your existing disks but that may not bother you / once it's all in the new system you can shuffle that round and change it at your leisure.