April 10, 201313 yr Maybe an almost dead thread now... but why do so many people mention the old XT but neglect the earlier PC with only 5 expansion slots instead of the newer very closely 8 slot spacing... (which now most MBs only have two or three of?) An even bigger concern may be with 64-bit... would we need to have BOTH a 64-bit CPU and 64-bit capable support chips on the MB? What about hyper-threading (or the AMD equivillent)? and on the security side of things... what about requiring the execution disable bit in the CPU and bios? My only point here is if making a 64-bit jump is indeed worthwhile, it may be also a good idea to jump up to some higher minimum hardware requirement for security or for other benefits... If such a decision were made for a future 64-bit version, a safer security model could be implemented should viruses or some other attacks like malicious code become a concern on unRAID, or linux in general. This was some of the reasoning that MS with Win8 now requires the disable bit to be available in the CPU and supported and enabled in BIOS. They finally released a version that I was willing to buy to do some upgrades with, since I was still running XP and had not used the newer OSes. I was rather disapointed to learn that MOST of my 64-bit even WITH HYPER-THREADING was too old to allow the use of the new Win8 OS. So I only have a small number of dual-boot XP/Win8 machines compared to what I had planned on. - - thought summery - - Even somewhat newer 64-bit capable hardware, may be old enough to NOT be desirable to lock a future version of 64-bit unRAID to be able to run on. At that point either the older 32-bit versions would need to be used, or possibly a less feature rich/or less secure 64-bit version. Where a more robust higher security model 64-bit version would require substantially newer 64-bit hardware. Oh the fun of aging hardware with new stuff being introduced frequently.... So my ideal unRAID world, in light of the ever changing hardware scene would include multiple available versions as follows: 1. Maintain version 4.7 for an available download. (and also a way to get older versions if wanted...) 2. Maintain version 5.x for an available download (32-bit) 3. Maintain a basic 64-bit version for download (for older 64-bit hardware) (if initial support for this level of hardware is decided as a good idea.) 4. Maintain an advanced 64-bit version for download (for newer bit capable hardware) (for more secure hardware/software options) In the 4 categories it would be, in my perfect world, that all 4 versions would remain available for download and use for many many years into the future. That does not mean that they are all getting updates, just that they are available up to the newest issued released sub-version within that major version group. Some of which may, or may not receive periodic updates of drivers, bug fixes, etc... That way even old outdated hardware would still be able to find a good home in use with unRAID, even if it is no longer hardware that would fit the then newly supported versions of unRAID. New is nice, and may have very desirable features, and reasons to make upgrades of a very large benefit. As long as old is still available for use, both in hardware kicking around, and in unRAID versions for download, not much will truly be left behind or abandoned. Things will of course get to a point where active support may become either un-required or not possible. But in the case of these forums, probably never truly dead either... I have also looked at times to alternatives to unRAID, but I just keep re-evaluating and come back to unRAID as being THE solution for my needs. (ZFS is REALLY REALLY COOL THOUGH, and has some great features I would like to see in the future come to unRAID like multiple parity drives... but more CPU power and memory are needed then as compared to the very humble needs of unRAID) After all unRAID does work quite well on an older P4 with only 256 MB of RAM, and an Intel GB NIC! :-)
April 10, 201313 yr ..... I don't understand why you suggest the need to offer both 4.7 and 5.0 32-bit? 5.0 in its current 32-bit version has not removed support for any hardware that works in 4.7. In fact as hard drives get larger I think it's important to get as many people as possible off of it since it does not support 3TB and larger hard drives.
April 10, 201313 yr I might be off but I basically do not understand the most part of your mail.. Maybe an almost dead thread now... but why do so many people mention the old XT but neglect the earlier PC with only 5 expansion slots instead of the newer very closely 8 slot spacing... (which now most MBs only have two or three of?) "The old XT", an XT is the first IBM clone PC that ever came into the homes, it most certainly is not suited for unraid and I would amazed if they are even still around.. And then you mention an even EARLIER pc.. Totally unclear to me what you mean.. And what sense is mentioning the number of expansion slots ? 3 expansion slots will suffice to totally fill an unraid system.. An even bigger concern may be with 64-bit... would we need to have BOTH a 64-bit CPU and 64-bit capable support ships on the MB? What about hyper-threading (or the AMD equivillent)? and on the security side of things... what about requiring the execution disable bit in the CPU and bios? The whole thread is about 64bit support so its not "even bigger", its what we are talking about.. Can you explain what you mean by "64 bit capable support ships on the MB", it does not make sense to me. The disable bit is a hardware based security feature, you can turn it on an off and it has no relevance to unraid. Unraid is not hardened security wise so making this bit a requirement would be like bolting down a window while the door is unlocked.. My only point here is if making a 64-bit jump is indeed worthwhile, it may be also a good idea to jump up to some higher minimum hardware requirement for security or for other benefits... The 64 jump is needed if we want to expand the platform functionality wise to a higher level, more tools running need more memory and more memory makes it necessary to go to 64 bit. Also the fact that 32bit kernels will get less and less development is a good reason. If such a decision were made for a future 64-bit version, a safer security model could be implemented should viruses or some other attacks like malicious code become a concern on unRAID, or linux in general. That is a totally different discussion, it now sounds like you would like unraid to be more secure.. Now things could be done to do that but it is kind of against the way IT is developping right now. It is extremely expensive and complex to add security to every component. It is better, cheaper and easier to lay a layer of security around your datacenter therefor stopping external intrusion, security within that datacentre (and/or cloud if you want to call it that) can be more relaxed and easier to administer. This actually confirms to the setup unraid has chosen. The product is developped to be used in a safe environment. So security against intrusion should be outside of the box itself (close up your network, do not open ports, build a vpn, etc. etc.). Personally I like this train of thought, it makes the unraid system easier to use and more wife friendly. Security wise I only have to make sure my perimiter is as safe as it can be and I do not have to bolt down every door and window. This was some of the reasoning that MS with Win8 now requires the disable bit to be available in the CPU and supported and enabled in BIOS. They finally released a version that I was willing to buy to do some upgrades with, since I was still running XP and had not used the newer OSes. I was rather disapointed to learn that MOST of my 64-bit even WITH HYPER-THREADING was too old to allow the use of the new Win8 OS. So I only have a small number of dual-boot XP/Win8 machines compared to what I had planned on. What is the relevance to unraid ? - - thought summery - - Even somewhat newer 64-bit capable hardware, may be old enough to NOT be desirable to lock a future version of 64-bit unRAID to be able to run on. At that point either the older 32-bit versions would need to be used, or possibly a less feature rich/or less secure 64-bit version. Where a more robust higher security model 64-bit version would require substantially newer 64-bit hardware. I think you are saying that some 64bit hardware might not be able to run a 64 bit unraid, do you have a (widely used) example of this ? Oh the fun of aging hardware with new stuff being introduced frequently.... So my ideal unRAID world, in light of the ever changing hardware scene would include multiple available versions as follows: 1. Maintain version 4.7 for an available download. (and also a way to get older versions if wanted...) 2. Maintain version 5.x for an available download (32-bit) 3. Maintain a basic 64-bit version for download (for older 64-bit hardware) (if initial support for this level of hardware is decided as a good idea.) 4. Maintain an advanced 64-bit version for download (for newer bit capable hardware) (for more secure hardware/software options) - 4.7 is allready mothballed, there is no good sense in using it any more (but for "if it aint broke don''t fix it" and there is nothing wrong with that!), so: done - 5.0 32 bit is allready there, so done - There is no 64bit version yet, so lets wait if there indeed will be an issue with "older 64 bit hardware", you bring in the security model again, still don't get how that relates. In the 4 categories it would be, in my perfect world, that all 4 versions would remain available for download and use for many many years into the future. That does not mean that they are all getting updates, just that they are available up to the newest issued released sub-version within that major version group. Some of which may, or may not receive periodic updates of drivers, bug fixes, etc... That way even old outdated hardware would still be able to find a good home in use with unRAID, even if it is no longer hardware that would fit the then newly supported versions of unRAID. So basically whay you are saying is: - keep old versions available for download (allready the case) New is nice, and may have very desirable features, and reasons to make upgrades of a very large benefit. As long as old is still available for use, both in hardware kicking around, and in unRAID versions for download, not much will truly be left behind or abandoned. Things will of course get to a point where active support may become either un-required or not possible. But in the case of these forums, probably never truly dead either... I have also looked at times to alternatives to unRAID, but I just keep re-evaluating and come back to unRAID as being THE solution for my needs. (ZFS is REALLY REALLY COOL THOUGH, and has some great features I would like to see in the future come to unRAID like multiple parity drives... but more CPU power and memory are needed then as compared to the very humble needs of unRAID) After all unRAID does work quite well on an older P4 with only 256 MB of RAM, and an Intel GB NIC! :-) Unraid is great, fulfills a need and is stable. It has a very small footprint hardware wise. My VM never tops 2.5gb of memory and doesn ot use more then 50% of the 2 cores I assigned to it. It is however also a fact that there are more and more options comming in other tools that make it even more nice to use and more secure data-wise. ZFS and ButrFS have has some very decent options where it comes to reverting to previous versions of files, effectively beiing a time machine for your data. Also loss of more then 1 drive is less desctructive. In my head this looks like the airconditioning in my car. When I first bought a car, somewhere like in 1992. Airco was an option considered a luxury, few people had it and it was certainly not considered a base feature. At this moment in time airco is absolutely a base feature, it would be hard if not impossible to find a car without it. This is why it is important to develop and investigate new features, and why even a "it just works product" needs to develop and change. And that is what is happening as far as I see it. Ending the V5 final debate and moving to 64bit are two things needed to make next steps and if we want unraid to remain the great product it is we should help Tom to go that way..
April 11, 201313 yr Sorry for this reply, a bit of a response to responses to earlier somewhat ranting type of post... First, I was only trying to explain, (very poorly perhaps), why I like to keep my old stuff running, possibly with new purposes or hardware or software added... ..... I don't understand why you suggest the need to offer both 4.7 and 5.0 32-bit? 5.0 in its current 32-bit version has not removed support for any hardware that works in 4.7. In fact as hard drives get larger I think it's important to get as many people as possible off of it since it does not support 3TB and larger hard drives. Well, Yes 5 works well, and does a great job. I have had NO concerns with it to date yet. I just DO NOT LIKE the newer look and personally LOVE the older 4.5.3 so much more than the newer 4.7 even that I use it on most of my unRAID machines... even though there are REAL concerns with 4.5.3, that were addressed in 4.5.4, I do not like the change for MY use. I would of course NEVER recommend anything but 5.0 and newer for anyone else to use for a new server. But some times people do have specific likes or dislikes... ( call me odd... my kids do...) **************** I might be off but I basically do not understand the most part of your mail.. I was a bit incoherent I guess... :-( "The old XT", an XT is the first IBM clone PC that ever came into the homes, it most certainly is not suited for unraid and I would amazed if they are even still around.. And then you mention an even EARLIER pc.. Totally unclear to me what you mean.. And what sense is mentioning the number of expansion slots ? 3 expansion slots will suffice to totally fill an unraid system.. I only mentioned the XT because it had been mentioed by many people in the thread. I thought it sad that the earlier IBM PC (and for that matter the PC Jr.) Were NOT mentioned and many people do not even remember them. The PC was the first IBM home computer or as it is named Personal Computer or (PC) it even had a cassette tape interface... And while much more limited than todays computers still had more expansion built into it than many newer computers now... (in number of internal slots at least...) I only have 4 of the old PC computers still... Yes they all still work. but not of much use overall... with no hard drive bios updates and such... While 3 slots may be usable to fully expand unRAID, the required drives per expansion card to get all the drives you can use with a PRO key, does then also reduce the models of add-on cards to pick from... ...Can you explain what you mean by "64 bit capable support ships on the MB", it does not make sense to me. TYPO sorry fixed.. chips as in support chips on the MB. There were some combinations of early 64-bit era hardware that would work together, but would not all be truly 64-bit capable... The disable bit is a hardware based security feature, you can turn it on an off and it has no relevance to unraid. Unraid is not hardened security wise so making this bit a requirement would be like bolting down a window while the door is unlocked.. While not needed for most environments likely... I am paranoid, and only have ONE unRAID server opened for use on a different subnet made available for my kids to access. I never know who may bring over a video game console or laptop or other device and connect to my network. So it would be nice to have the ability to further protect the one unRAID that may indeed be exposed to an interal network threat... I do have everything protected in secured back-ups and on secured unRAID servers, but it is a pain to need to use them for what could have been prevented with additional security... (I guess that would be another good reason for 64-bit hardware with more memory etc... running a Linux friendly ant-virus solution on the unRAID box... ) No my MS rant is not related to unRAID, with the exception of just trying to show why an older unRAID may be prefered by some users, while a future version that does not yet exist may finally attract some to upgrade that otherwise may not... I think you are saying that some 64bit hardware might not be able to run a 64 bit unraid, do you have a (widely used) example of this ? I am just saying that depending on the hardware targeted and included in a build that there may be some hardware left out, that might still otherwise be fully usable on a prior version or different build with potentially different optimizations or compromises... (think of the various driver issues with some NIC chips for example, or some IDE and SATA chips...) Sometimes drivers just do not work well, and at times may be best to either not implement at all, or at least use an older more stable software version driver that may not fully utilize a chips capabilities to make it at least usable and stable... The same thing has happened for some CPU support chip sets, and even some early CPU release dies... ...Ending the V5 final debate and moving to 64bit are two things needed to make next steps and if we want unraid to remain the great product it is we should help Tom to go that way.. I do FULLY agree, 64-bit is the future, (at least till an even better path exists...) Tom has provided a very wonderful and robust platform with unRAID. It just keeps getting better too! Just because I prefer the older 4.x look and feel does not mean I am against the 5.x look it is just not what I like, and till I need the new features, (read 3TB plus drive support), I will likely only play with 5.x on test machines... and keep any new real use unRAID builds (with 2TB drives) back on my favorite 4.5.3 version of unRAID. As another side note - for why keep older version available... I just erased all the old data on my old HP Netserver a PIII 933 Mhz machine. In the hopes of making it my oldest hardware running unRAID... unRAID boots fine after booting with a CD boot-strap, BUT it does not have any driver support for my old SCSI cards, so it can not do anything with all my SCSI drives... :-( So it now is running FreeNAS, it works but it is a far cry from unRAID... :-( :-) But now I have a big whopping 250GB array using as much power as a small microwave oven... in a much larger space than a large microwave oven... I probably will be better off to just use an old Celeron 733 Mhz computer and upgrade with some old 250GB IDE drives... then I can run unRAID on it!
April 11, 201313 yr .......... I just don't understand the logic of loving to use such an old version, especially when it has known issues. These changes make it unsuitable for your use? Bug fixes: - Fix (another) problem where formatted data disks could appear 'unformatted' immediately following array start. This one was due to race condition where md devices could possibly not exist before management utility issues 'mount'. Other: - Generate additional logging information during 'mount'. - Added additional "safeguards" in the code handling 'format' operations. - Removed 'Restore' button from webGui, replacing with new shell command called 'initconfig'. - Updated mc (midnight-commander) utility to slackware's 2010-02-06 version. What is there to 'like or dislike' about those 5 changes, one being a large bug fix? There's no logic to what you're saying. You also say there should be old versions available because you want to run a NAS OS on 13 year old hardware for no other reason than 'just because'. What about the not so savvy new guy who stumbles across unraid looking for a solution for him and decides to look past it because there are four different versions of the operating system and doesn't know which to choose? Even Microsoft realized too many versions was a mistake and paired it down with W8. I think a 5.0.0 being the final 32-bit version and a 64-bit from there on out is more than reasonable. If you want to run a NAS on hardware from when Bill Clinton was in office you're savvy enough to hunt something down on your own. I'm not trying to be rude, I just honestly can not wrap my head around anything you're saying.
April 12, 201313 yr You are correct on all points... But there does not need to be, and seldom is there, logic in anything such as like, love or hate... I really liked the old button that was removed, as it really should have been, not because I have ever used it much, nor because I dislike a command line entry to replace it. I just use it for myself, and am aware of what it will do. When I need that functionality, I would rather just use it from the GUI as it was in the older versions. That is the real reason keeping me on my older version... I do like to test new hardware, (and old) for various new applications and acid test them prior to rolling them into a full time position... The old "restore" button does save me a little time when I need to use it. (also the bug, should it show up... will also let me know I need to look more closely at my hardware configurations to make sure there are no issues there that will compromise performance should I decide to keep a specific hardware combination for full time use. If all passes my initial tests, I am NOT averse to putting a newer version of unRAID on it for further testing and use... I have been very pleased with unRAID, and feel I know what to expect if there are problems with hardware under the version I am normally using... No I do not have problems much except for when testing known marginal hardware. Then I have found that newer versions of unRAID may actually run with no problems, even though the hardware is not what I would want to trust... In this way thee older version, though not as stable perhaps, helps me to identify potential problem hardware earlier in my testing phases... I do not need the additional logging information, for my purposes, (though it is nice for normal use especially if there are problems... I also do not need the additional safeguards for format operations, though fully a welcome update... I never use mc. it remindes me too much of the software it did a good job of copying, which I never really liked much... I prefer command prompts and writing scripts for my file copy, move, and compare operations. I do also agree with your comment about user confusion when faced with too many versions to pick from. I just like full archives, in this case perhaps just even making them available on another "older versions" page might be a good thought. The new page could be accessed from a smaller, not as attention grabbing, link on the normal download page where the only normally displayed versions are the ones that are current, (up to a cut off-point) like the ones that are now always available on the download page.
April 13, 201313 yr ... Well, Yes 5 works well, and does a great job. I have had NO concerns with it to date yet. I just DO NOT LIKE the newer look and personally LOVE the older 4.5.3 so much more than the newer 4.7 even that I use it on most of my unRAID machines... even though there are REAL concerns with 4.5.3, that were addressed in 4.5.4, I do not like the change for MY use. I would of course NEVER recommend anything but 5.0 and newer for anyone else to use for a new server. But some times people do have specific likes or dislikes... ( call me odd... my kids do...)... may i suggest you spend some time (which would be way more helpful on other matters) to just 're-create' a 'vintage' gui for yourself and the huge community demanding this particular feature!? i personally give a damn how the gui looks, as long as it is logical and covers the needs. generally i don't see it!!! well, once it is all set up and running fine... i don't see that for weeks on end. if i see it (means usually changes or probs) i give another damn how it looks, but once again, need a logical interface to sort my prob. as far as i am concerned it could be in green on red unaligned info by lines and check boxes/ textfields, as long as it brings a advantage in usability. the best unraid server is the one that is set up, disappears in a closet (or like in my case the basement) and is only seen to add drives/ other hardware while running rock solid and do what it is supposed to do... store and serve all kinds of data while being reasonable secure concerning hardware issues. 64bit will be a nice evolution, going along with technology in general and open up new possibilities for hardware and software in terms of speed, added features & hardware etc. i personally look forward to it. not expecting to much initially but in the longer run (with third party plugins) it should allow for all kind of emerging technologies (without the 'vintage' gui for me personally ) L
April 17, 201313 yr Could a 64bit version of Unraid support multiple parity drives? and would this be a sought after feature for anybody else?
April 17, 201313 yr That is a different question... 32bit unraid could also support dual parity.. Tom has however hinted at supporting butterfs, and this makes the whole concept of a seperate parity drive possibly redundant..
April 17, 201313 yr That is a different question... 32bit unraid could also support dual parity.. Tom has however hinted at supporting butterfs, and this makes the whole concept of a seperate parity drive possibly redundant.. That was for cache drive only though. Technically you could run your entire array as one huge cache drive but the general consensus is Btrfs is not ready for prime time to run a large many disk array. ZFS is still the only real file system based option for that. Even if you did use a Btrfs cache as your whole array, you'd lose two of unraid's biggest assets: only the disk being read or written to needs to be spun up (plus the parity for writing) and each disk can be read individually outside of the array.
April 17, 201313 yr That is a different question... 32bit unraid could also support dual parity.. Tom has however hinted at supporting butterfs, and this makes the whole concept of a separate parity drive possibly redundant.. Interesting cant wait to see how this develops.
April 17, 201313 yr That is a different question... 32bit unraid could also support dual parity.. Tom has however hinted at supporting butterfs, and this makes the whole concept of a seperate parity drive possibly redundant.. That was for cache drive only though. Technically you could run your entire array as one huge cache drive but the general consensus is Btrfs is not ready for prime time to run a large many disk array. ZFS is still the only real file system based option for that. Even if you did use a Btrfs cache as your whole array, you'd lose two of unraid's biggest assets: only the disk being read or written to needs to be spun up (plus the parity for writing) and each disk can be read individually outside of the array. Mmmm/// when that is true I do not really see the benefit... A bit more protection on a drive that only holds data for a few hours and a whole complete different filesystem setup active against that little advantage...
April 17, 201313 yr That is a different question... 32bit unraid could also support dual parity.. Tom has however hinted at supporting butterfs, and this makes the whole concept of a seperate parity drive possibly redundant.. That was for cache drive only though. Technically you could run your entire array as one huge cache drive but the general consensus is Btrfs is not ready for prime time to run a large many disk array. ZFS is still the only real file system based option for that. Even if you did use a Btrfs cache as your whole array, you'd lose two of unraid's biggest assets: only the disk being read or written to needs to be spun up (plus the parity for writing) and each disk can be read individually outside of the array. Mmmm/// when that is true I do not really see the benefit... A bit more protection on a drive that only holds data for a few hours and a whole complete different filesystem setup active against that little advantage... Well with the plugin system, especially once it goes official and supported, there will be lots of people with potentially lots of data that will only reside on the cache drive. People with Plex and/or XBMC libraries are storing gigs of data on their cache drive. Btrfs will provide a layer of protection for data that can be recreated but is a pain in the ass if you have to recreate it.
April 17, 201313 yr That is a different question... 32bit unraid could also support dual parity.. Tom has however hinted at supporting butterfs, and this makes the whole concept of a seperate parity drive possibly redundant.. That was for cache drive only though. Technically you could run your entire array as one huge cache drive but the general consensus is Btrfs is not ready for prime time to run a large many disk array. ZFS is still the only real file system based option for that. Even if you did use a Btrfs cache as your whole array, you'd lose two of unraid's biggest assets: only the disk being read or written to needs to be spun up (plus the parity for writing) and each disk can be read individually outside of the array. Mmmm/// when that is true I do not really see the benefit... A bit more protection on a drive that only holds data for a few hours and a whole complete different filesystem setup active against that little advantage... Well with the plugin system, especially once it goes official and supported, there will be lots of people with potentially lots of data that will only reside on the cache drive. People with Plex and/or XBMC libraries are storing gigs of data on their cache drive. Btrfs will provide a layer of protection for data that can be recreated but is a pain in the ass if you have to recreate it. That is what I mean... If you need your data to be protected just put it in the array.. If you do not mind it, or it is temporary, then put it on the cachedrive.. I do not see the benefit of an extra protected cache drive... This is going off-topic though, I know enough ;-)
April 17, 201313 yr That is a different question... 32bit unraid could also support dual parity.. Tom has however hinted at supporting butterfs, and this makes the whole concept of a seperate parity drive possibly redundant.. That was for cache drive only though. Technically you could run your entire array as one huge cache drive but the general consensus is Btrfs is not ready for prime time to run a large many disk array. ZFS is still the only real file system based option for that. Even if you did use a Btrfs cache as your whole array, you'd lose two of unraid's biggest assets: only the disk being read or written to needs to be spun up (plus the parity for writing) and each disk can be read individually outside of the array. Mmmm/// when that is true I do not really see the benefit... A bit more protection on a drive that only holds data for a few hours and a whole complete different filesystem setup active against that little advantage... Well with the plugin system, especially once it goes official and supported, there will be lots of people with potentially lots of data that will only reside on the cache drive. People with Plex and/or XBMC libraries are storing gigs of data on their cache drive. Btrfs will provide a layer of protection for data that can be recreated but is a pain in the ass if you have to recreate it. That is what I mean... If you need your data to be protected just put it in the array.. If you do not mind it, or it is temporary, then put it on the cachedrive.. I do not see the benefit of an extra protected cache drive... This is going off-topic though, I know enough ;-) Plugins often keep disks spun up. That's the difference here. Yes you could add a array disk that only stores plugins but that will also keep the parity disk always spun as well. The point here is mission critical data is protected as it always has been and disks will stay spun down as much as possible. Cache data now has some redundancy with Btrfs. Those disks will always be spun up but a dead disk can be replaced without data loss. That is another point. Replacing your dead 120GB Btrfs cache array disk costs a lot less to replace than your 4TB parity drive.
April 17, 201313 yr All good and true and to each his own... Bit if I want my apps more safe I have no problem in one disk more spinning (when there is writing to that disk, not allways).. I would prefer that above a completely new filesystem.. But, to each his own !
April 17, 201313 yr That escalated off-topic quickly so im assuming butterfs can support multiple drive failures, but it would keep all the disks spun up all the time? wouldnt that go against one of the main pros of unraid of only spinning up disks you need? I would think it would just be easier to implement a second parity.
April 17, 201313 yr That escalated off-topic quickly so im assuming butterfs can support multiple drive failures, but it would keep all the disks spun up all the time? wouldnt that go against one of the main pros of unraid of only spinning up disks you need? I would think it would just be easier to implement a second parity. Would you rather have a few cache disks spun up or your parity drive(s)? I know I'd rather have my inexpensive cache disks spun up than the costly disk I'm using for parity. Using Btrfs for your cache pool will keep only those cache disks spun up, not any array disks. Parity for the cache pool spans those cache disks, it does not use the parity disk of your main array.
April 17, 201313 yr Would you rather have a few cache disks spun up or your parity drive(s)? I know I'd rather have my inexpensive cache disks spun up than the costly disk I'm using for parity. Using Btrfs for your cache pool will keep only those cache disks spun up, not any array disks. Parity for the cache pool spans those cache disks, it does not use the parity disk of your main array. Maybe Im just not reading correctly how Btrfs works. So what it sounds like you're saying is that is makes a backup of your cache drive until it has the chance to transfer to the array then it would spin down the array and go back to using the cache + cache backup?
April 17, 201313 yr Would you rather have a few cache disks spun up or your parity drive(s)? I know I'd rather have my inexpensive cache disks spun up than the costly disk I'm using for parity. Using Btrfs for your cache pool will keep only those cache disks spun up, not any array disks. Parity for the cache pool spans those cache disks, it does not use the parity disk of your main array. Maybe Im just not reading correctly how Btrfs works. So what it sounds like you're saying is that is makes a backup of your cache drive until it has the chance to transfer to the array then it would spin down the array and go back to using the cache + cache backup? Do you know what ZFS is? Btrfs is similar to ZFS. The Btrfs cache pool would be an entirely separate "array" from your unraid array. It has it's own parity features and the parity spans all the disks in the pool similar to RAID5. It is not like unraid where there is one parity disk for the while array. It would be similar to running a RAID5 array with a couple of disks to make one large, fast cache disk.
April 18, 201313 yr BTRfs or ZFS would be great for a cache drive, especially if it is also being used, as many people are doing, as an application drive! Adding a new protected array for the cache drive functionality would be a very good use of additional resources made available with the 64-bit hardware now available. If you also add the possibility of multiple parity drives, it makes 64-bit even MORE attractive! Yes these could also be built upon a 32-bit platform, but with many features run together, limitations will be seen much sooner with memory limits, and even code execution. So yes, I would make a switch to 64-bit, (well make another build) with such added features (priority for me would be the multiple drive parity option). There just is not enough horse-power nor resource capability on my 32-bit hardware to properly use such features.
Archived
This topic is now archived and is closed to further replies.