• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

ZFS & partitioned disks

T

tarnar

n00b
Joined
Feb 23, 2014
Messages
16
Heya folks. I'm new to the world of ZFS and am in the process of piecing together my first storage server. Here's the build quickly:

Supermicro 2U case with 8x3.5" hot swap disks, the backplane doesn't have a SAS expander (i.e. there are 8 SAS/SATA ports on the backplane)
Supermicro X9SRL-F motherboard
Xeon E5-1620 V2
16 GB ECC RAM
Perc H310 cross-flashed to LSI IT firmware
8x 3TB 7200 RPM Seagate Desktop SATA drives
2x 120 GB Sandisk SSDs

The idea is to run ESXi, run OpenIndiana in a VM and pass-thru the LBA to the VM. I have done this, it looks to be working, I can see all the disks in OpenIndiana, hooray!

Now, time for questions.

I was planning to divide the 3 TB drives into three 1 TB partitions. The idea was to build a zraid2 out of eight 1 TB partitions (one per drive of course) to give me 6 TB of useable space. Then I have a bunch of unused disk for future migrations - where I can make a 6 TB zraid2 pool using five 2 TB partitions and yank three disks out. Those slots are then replaceable and therefore upgradable.

(I'm also thinking about a pool of striped mirrors but that doesn't really change the overall nature of my query)

If the future disk capacity is something like 6 TB for a 3.5" disk then the three slots could form a 3-way mirror to migrate the existing pool into, then the other five disks can come out and hooray, the build was future-proof!

The use-case is a home storage server, primarily to host my backups and act as a mirror for a mutual-mirror backup system with some friends. Reliability over performance.

Question 1: Is this completely stupid? Am I over-thinking this?

Question 2: How does this actually work when building pools? I suspect that I partition the disk into 3 partitions and then build pools as normal, but ZFS is never that simple, nor is technology. MBR? GPT? Do I need to worry about which sector the partitions start on? etc. etc.

Any help/advice is appreciated.
 
I would not partition. Especially not with different raid types. If a physical drive fails, you are potentially introducing a very complicate and error-prone failure mode. If this is mainly a backup server, just make a raidz2 pool and be done with it.
 
danswartz said:
I would not partition. Especially not with different raid types. If a physical drive fails, you are potentially introducing a very complicate and error-prone failure mode. If this is mainly a backup server, just make a raidz2 pool and be done with it.
Click to expand...
Thanks for replying. The plan isn't to run other raid types all the time, only when it actually comes time to juggle drives / migrate pools. Which means I'm wasting a lot of drive space by leaving it unallocated most of the time, possibly for years (this is the biggest strike against the plan).

When it comes time to juggle drives I'm going to have a high-reliability backup in place anyway. However, that backup isn't likely to be local to me (in terms of high-speed LAN links) and so some form of a migrate-while-mostly-online strategy seems attractive in my head.

The more I think about this though, the more it seems like very little gain for a bunch of effort.
 
I don't understand. Space is only wasted if you could have used it for something else. A large, sparsely used zfs pool takes no more time to migrate than a smaller, more used one.
 
I always use partitions under my raids and ZFSes. I wrote about it before.

Right now I cluster things so that no per-disk part is bigger than 1 TB.

One major reason is rebuild time. I have different data on different filesystems. I can resync the more important ones first. (I maintain that ZFS should have options to declare on the zfs level which ones are more important inside the same zpool). Keep in mind that a 3 TB 7200 rpm disk takes very long to resync.

Speed. The outside is faster. It syncs faster, too.

Mobility. You can change your mind and build something else on part of a disk.
 
Not going to beat a dead horse, here, but I think this is a really bad idea. Pools which have dependencies such that one drive can cause multiple pools degraded, hard to predict performance issues, due to multiple pools sharing the same spindle (with no way for zfs to act intelligently, etc...)
 
danswartz said:
Not going to beat a dead horse, here, but I think this is a really bad idea. Pools which have dependencies such that one drive can cause multiple pools degraded, hard to predict performance issues, due to multiple pools sharing the same spindle (with no way for zfs to act intelligently, etc...)
Click to expand...

In the Linux world the md raid subsystem knows specifically which parts of raids are backed by the same physical disks. If you then resync several of them it will stack them, doing one first, then the next. ZFS needs that, too and yes there is a way. It's easy.

Of course Linux can't do that if you obscure the path to the physical device with other layers but if you just have raid on partition that is how it works.

But it doesn't matter too much since you can do the resync with more important ones first yourself and stagger the resync of the others.
 
You must log in or register to reply here.
Back
Top