alpenwasser

Alright, we have a new stats script for IPS4, with new plots and a new ranking table! Also, added a new rule: A system must now have both more than 10 TB of storage and more than 5 storage drives (due to 8 TB and 10 TB drives now being a thing). So some systems which were previously ranked have now been dropped to the noteworthy list. We now also have some more fancy plots for various things. See here: If you can add some pics, I can your macbook USB creation to the noteworthy list, since we don't count USB drives. Damn, that's a bummer. Updated your config accordingly though. Updated. Added to noteworthy systems (due to the new rule being minimum 5 drives for the main list). Updated. If you upload some pics of that, I can bump you up to the main list. Not too shabby at all, welcome to the list! Added, welcome to the list! Funny, now that I've switched from Perl to Python for the ranking script, somebody bumps in here mentioning Perl! I'll have to give it a look sometime, thanks! Updated. Updated. Very nice, welcome to the rankings! You're lucky, you're just reading the thread, maintaining it is even worse! (okay, it's actually pretty cool, I don't mind) Hardware, sweet hardware, isn't it nice when you get those boxes? Those are some nice numbers, I wouldn't mind getting those at all (although I'm bottlenecked by my network anyway)! Updated. Excellent, welcome to the list! Well, well, well, what have we here? Looks like if you'd just sneezed once or twice during filling your shopping cart, you might have accidentally bumped looney from the #1 spot. Really digging the rack case on wheels. And I shall relay your cat tax to the overlords of the interwebz. Always good to see a nice and compacted system. Added to the noteworthy list (due to the new 5 drives minimum rule). Updated. Ouch! Splendid, added to list! Oh, the tragedy! I've only seen your post now that I was typing out this response, so it's not yet updated, but ah well, such is life. If I have forgotten somebody or there's an error somewhere, please notify me, thanks!

I can't say I know any 5-8 bay prebuilt units which fit your criteria to be honest. WD, Seagate and Netgear all make 4-bay units, maybe you can check out those (I'm not really familiar with their lineups). But I think if you're going for 5-8 bay prebuilts, you'll be spending quite a bit of money, as those units aren't usually intended for the lower market segment.

You mean you can't click it and view the other topic? I don't think it's supposed to expand the post in this thread, as far as I know.

@MoonSpot has a Drobo (or at least used to). See this post:

I suppose that depends on how much technology you see in fonts and typography. It's a pretty complex subject actually. But I think in the context of our forum, Off-Topic is probably the better fit. Therefore, moved.

Since this is now a status update, it looks like I can lock this thread then. Also, negative bonus points for thread title.

Hard to say what's going to be actually useful for you here due to my lack of hands-on experience with FreeNAS, but have you had a look at this one? This is the official vid for 9.3 from the FreeNAS channel. But honestly, for Windows share troubleshooting, I'm really the wrong guy to talk to, I have done very little Windows-ing in the past few years.

You could try to look for a used server on eBay, some of them can be had for pretty cheap. Downside is that they're usually loud, bulky, power-hungrier than current-gen parts and expensive to ship. But in the end, you get what you pay for, for the most part, so if you want to go low-cost, some sacrifices will need to be made.

So, if the array isn't built yet, you're not so much asking if you can replace drives, but if you can build an array with mixed drives in the first place? While it's generally not recommended, you can do it, yes. If the drives have different RPMs, you might get a bit weird performance characteristics though, hard to say. As for desktop drives in RAID, well, you know that already, decision is yours of course. But yeah, you can mix drive types in ZFS pools and vdevs, I've done that as well.

If you actually want to back up your 2 TB drive, you won't use RAID at all. RAID isn't for backing up, it's for increasing uptime (a drive fails, you can keep using your machine as if nothing had happened and replace the drive). If that is what you want, RAID1 (mirroring) is what you'll need to look at. If you want an actual backup however, get an external enclosure or a hotswap bay (or, if you haven't bought the second HDD yet, just get an external 2 TB drive), put the second 2 TB drive into that, and back up at reasonable intervals. Then disconnect the backup drive and keep it safe.

A while back a review site measured them as 5.4k RPM: http://www.silentpcreview.com/article1285-page5.html Whether this is true for all Red drives is another question. Regardless of that though, as far as I know each drive runs at a constant RPM. Having a variable RPM would be power-hungry (accelerating and decelerating the platters) and annoying (they'd emit a tone which changes frequency instead of a constant one, which is far less easy for human hearing to blur into the background) I'd expect. I must admit I'm not a fan of the term "Intellipower" and the "5,400 - 7,200 RPM" thing. Way too much confusion (which I suppose was the point, so well done, marketing?). From what I've been able to find out over the years, the "1 GB of RAM for 1 TB of storage" isn't as strictly true anymore these days as it once was (and it might never have been as strictly true for home use in the first place, the primary purpose of ZFS originally being large-scale deployments where performance is more critical). When ZFS emerged onto the market, HDDs were much smaller. But as HDDs grow bigger, the amount of RAM used for caching (and in the end, that's what most of the RAM gets used for) doesn't seem to grow proportionally with the pool size from what I can tell. I have 32 TB of raw storage (well, more, but that's ZFS) in my server, and 24 GB of RAM, and usually RAM usage hovers between 10 GB and 16 GB with the machine just idling along and not doing anything. I have also run a 17 TB (raw size) pool on another machine with 4 GB of RAM, while also using said machine as a regular desktop. No stability issues, but when ZFS needed to relinquish too much RAM, performance started to degrade (a few times I brought pool speed down to almost a halt). But once it had access to memory again, it just continued as if nothing had happened without any ill effects. I'd start out with a single 8 GB stick, then go from there, as that was the minimum amount recommended for FreeNAS last I checked. I would however look into ECC RAM if you have important data on that machine. It can run fine without it, but that's what I'd recommend. Decision is yours though.

Yeah... this isn't going anywhere we would like threads on these forums to go, sorry. Locked.

To add to the above, if you want to get a bit of an impression of how the various NAS operating systems look and all that, Youtube is your friend: For other NAS operating systems I've only found rather old videos. But you get the idea.

Well, fundamentally, building a NAS isn't much different from building a regular computer. It's less a question of "What do you need?", more a question of "How much money are you willing to spend on feature <x>?" You don't need RAID (hardware or software), you don't need ECC RAM, you don't need to have a strong CPU, you don't need to have lots of RAM, you don't need to have an additional backup on another machine or an external drive etc. (although I'd say not having a backup is a horrible idea, at least of your important data ). BUT: Each of those offers an advantage under certain conditions. RAID is nice to increase uptime since you don't lose access to your data upon drive failure (without RAID, you'd need to restore from backup before you could access your stuff again). ECC RAM is strongly recommended if you go with ZFS (be that FreeNAS or with ZFS on Linux), a strong CPU is nice if you want to run transcoding (Plex and similar), more RAM is nice if you run virtual machines or ZFS (and for ZFS there's also a higher minimum RAM recommendation). And of course, having a backup somewhere else will prevent you from going suicidal if the NAS goes *poof* and you lose your family photos. And so on and so forth. None of those is strictly speaking needed. So before you can decide what to buy, you'll need to figure out which feature is how important to you, how much money you're willing and/or able to spend on it, then go from there. As for NAS operating systems, there's a few choices: FreeNAS is popular, but it carries some non-trivial hardware requirements (or at least strong recommendations). Openmediavault is more frugal in that area, as a counterexample. Amahi would also be a possibility. Installing Linux or BSD and just setting up file shares would also be a way to go. Either way, the basic process is the same as assembling a regular machine: Assess your needs, figure out budget, select components based on the given constraints, order, assemble, install, or something thereabouts.

@MrUnknownEMC Not sure about the FTP, I don't really know FreeNAS that well since I run ZFS on Linux, sorry.

@MrUnknownEMC What you can do after creation: Add more drives to a mirror, remove drives from a mirror, add more vdevs to a pool. What you cannot do after creation: Add more drives to a RAIDZ{1,2,3} vdev, remove drives from a RAIDZ vdev, remove a vdev from a pool So, if you create a mirror now (which is what I'd recommend with two drives), you could add more drives to that mirror (which won't give you any extra space, but more protection, but personally I don't think it makes that much sense for a home server/NAS). The way you will get more space in your pool though is by adding more vdevs. So you can add another mirror, or a RAIDZ vdev. Example: Create pool consisting of a single mirror: # zpool create scratch -m /root/zfs-sandbox/scratch mirror /root/zfs-sandbox/0.img /root/zfs-sandbox/1.img # zpool status scratch pool: scratch state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM scratch ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 /root/zfs-sandbox/0.img ONLINE 0 0 0 /root/zfs-sandbox/1.img ONLINE 0 0 0 errors: No known data errors Add another mirror: #zpool add scratch mirror /root/zfs-sandbox/2.img /root/zfs-sandbox/3.img # zpool status scratch pool: scratch state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM scratch ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 /root/zfs-sandbox/0.img ONLINE 0 0 0 /root/zfs-sandbox/1.img ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 /root/zfs-sandbox/2.img ONLINE 0 0 0 /root/zfs-sandbox/3.img ONLINE 0 0 0 errors: No known data errors And, if you wanted to, you could also add a RAIDZ. Note however that you can get weird performance behavior if you mix different types of vdevs in your pool (mirrors and RAIDZ, or different kinds or RAIDZ). Plus, having different kinds of vdevs also means that you don't get the same level of protection on all of them, which may or may not be an issue to you. Indeed, ZFS will complain at first if you try to do this: # zpool add scratch raidz2 /root/zfs-sandbox/4.img /root/zfs-sandbox/5.img /root/zfs-sandbox/6.img /root/zfs-sandbox/7.img /root/zfs-sandbox/8.img invalid vdev specification use '-f' to override the following errors: mismatched replication level: pool uses mirror and new vdev is raidz So, let's use the force then: # zpool add -f scratch raidz2 /root/zfs-sandbox/4.img /root/zfs-sandbox/5.img /root/zfs-sandbox/6.img /root/zfs-sandbox/7.img /root/zfs-sandbox/8.img # zpool status scratch pool: scratch state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM scratch ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 /root/zfs-sandbox/0.img ONLINE 0 0 0 /root/zfs-sandbox/1.img ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 /root/zfs-sandbox/2.img ONLINE 0 0 0 /root/zfs-sandbox/3.img ONLINE 0 0 0 raidz2-2 ONLINE 0 0 0 /root/zfs-sandbox/4.img ONLINE 0 0 0 /root/zfs-sandbox/5.img ONLINE 0 0 0 /root/zfs-sandbox/6.img ONLINE 0 0 0 /root/zfs-sandbox/7.img ONLINE 0 0 0 /root/zfs-sandbox/8.img ONLINE 0 0 0 errors: No known data errors Whatever you end up doing, the cardinal rule in ZFS is this: You must never, ever have a vdev failure. If you do, your pool is dead and your data is gone.

@biotoxin Good to know, thanks for the info!

@AwesomeUsername Please note that the title of this thread was not in conformance with our Community Standards with regards to flaming and trolling, which is why I've changed it. Furthermore, the opening post does not meet the requirements of our posting guidelines, which is why this thread has been locked. If you wish to have it re-opened, please send me a PM with the revised version and I'll have a look at it.

Alright, two things: Luke happened to be around and saw the answer I gave you guys in the CS thread, okay'd it. So that should be alright. Also clarified the CS a bit on this matter. @Typho They are now called Community Standards and can be found here: