Abstraction of paths inside zpool

[Solero]

Hi,

I'm using FreeNAS and access it on a regular basis via ssh.
Right now I have one zpool but plan on creating a second one and move some datasets to it.

What is disturbing to me is the fact, that I have no way in creating a softlink on a high level basis e.g. I have the paths
/mnt/zpool1/home/username/
/mnt/zpool1/film/
/mnt/zpool1/bittorrent/

If I add a new zpool (zpool2) and move 'film' over to this one the new path is:
/mnt/zpool2/film

Every script etc has to be modified in order to account this.

A softlink inside /mnt/ gets deleted after an update or reboot (I'm not sure, but it doesn't last long)

What I would like are paths like:

/symbolic/home/username
/symbolic/film
/symbolic/bittorrent

which do the abstraction to the real path.

I don't want to put softlinks inside a zpool as it only mitigates the problem and is useless if the the zpool the softlink is inside gets destroyed. (And it is ugly as hell, too )

What can I do to achieve my goal?

Regards,
Solero

 

[danb35]

So rather than create a second pool, why not expand the original pool? That's how ZFS is designed to work.

 

[Solero]

I prefer mirros to RAID/ZRAIDx and I dont want to put multiple mirrors as vdevs in one zpool. Therefore I can only grow in storage space by replacing my hdds with bigger ones or
by adding a separate zpool.

Before a discussions starts whether this makes sense or not:
1. This is why I prefer mirrors.
2. I dont want to use vdevs as the only advantage I can think of is merging the storage together. This advantage is negligible to me.
I want to have the chance to take out a single hdd and access the data on any other system which is able reading ZFS. With vdev I would need a whole set of vdevs to do this.

Long story short. I though about pros/cons of my setup and only miss symbolic links or a similar solution.

 

[Mirfster]

Long story short. I though about pros/cons of my setup and only miss symbolic links or a similar solution.

Not that I used symbolic links personally, but in this thread it appears that @anodos does without issues.

 

[anodos]

I prefer mirros to RAID/ZRAIDx and I dont want to put multiple mirrors as vdevs in one zpool. Therefore I can only grow in storage space by replacing my hdds with bigger ones or
by adding a separate zpool.

The storage capacity of a zpool consisting of mirrored vdevs will increase as you replace the hard drives in the vdevs (you do not need to replace all of the drives in your zpool).

1. This is why I prefer mirrors.

But that post says nothing about creating multiple zpools consisting of a single mirrored vdev. In fact, it explicitly states that the example mirrored zpool is a single zpool consisting of 4 mirrored vdevs.

I want to have the chance to take out a single hdd and access the data on any other system which is able reading ZFS. With vdev I would need a whole set of vdevs to do this.

Correct. You will not be able to do this.

Long story short. I though about pros/cons of my setup and only miss symbolic links or a similar solution.

Why not write a script that tests for the existence of the symlinks, and if they don't exist have the script automatically create them? Then set it as an 'Init Script' in the webgui.

A sample ugly bash script is as follows:

Code:

#!/bin/bash

SymlinkArray=(Foo Bar)
for Symlink in ${SymlinkArray[@]};
do
    SourceDir=$"/mnt/Tank/$Symlink"
    TargetDir=$"/mnt/$Symlink"
    if [ ! -L "$TargetDir" ]; then
       ln -s "$SourceDir" "$TargetDir"
    fi
done

 

[danb35]

I dont want to use vdevs as the only advantage I can think of is merging the storage together. This advantage is negligible to me.

...except that it's exactly what you're asking to do, and exactly what ZFS was designed to do. Really, though, symlinks should work, and should even be persistent if you put them on the pool rather than in /mnt. Or you could tinker with the ZFS options and set an alternate mountpoint for the dataset on the second pool to put it under the first pool's tree.

 

[Solero]

...except that it's exactly what you're asking to do, and exactly what ZFS was designed to do. Really, though, symlinks should work, and should even be persistent if you put them on the pool rather than in /mnt. Or you could tinker with the ZFS options and set an alternate mountpoint for the dataset on the second pool to put it under the first pool's tree.

Your are right. The difference between a zpool with two mirror-type vdevs and two zpools is a bit more flexiblity I get from the latter one. I see some advantages:

• I can eg. take the 'movie'-zpool and put it inside a completely new setup and leave my 'userdir'-zpool at its old place.
• In a disaster case I just need one drive to start working and not two (or three, ...). I try to keep things simple when it is really important, like during a disaster. (Sidenote: Up to now I have one Proliant Gen8 server. In my final setup I have an identical system with a nightly syncjob placed at a friend of mine.)

I pay for this flexibility with comfort, I know.

Am I a bit peculiar with my requirements? Perhaps, but what I am about to do with FreeNAS is no hack or anything like that. It is just a - maybe not so common - configuration for someone who is a bit paranoic :)

I guess creating the symlink on boot is the best I can get.

 

[danb35]

This is why I prefer mirrors.

Although I don't agree with most of that article (and the issue of mirrors vs. RAIDZ is irrelevant to your question), most of what I disagree with is debatable opinion. There's at least one place, though, where that author is simply factually incorrect. He correctly notes that you can expand a RAIDZn vdev by replacing disks with larger disks (you can do the same with a mirrored vdev, of course), but then incorrectly states that you must offline a disk to replace it. If you have room for a spare disk temporarily, you can do the replacement with the original disk still in the pool; it is offlined once the replacement is finished. This means that you never need to compromise redundancy in this scenario.

 

[Robert Trevellyan]

There's at least one place, though, where that author is simply factually incorrect

This is the one that boggles my mind: "all of the remaining disks in a RAIDZ vdev are being much more heavily loaded with writes as well as reads during a resilver"

 

[Ericloewe]

"all of the remaining disks in a RAIDZ vdev are being much more heavily loaded with writes as well as reads during a resilver"

I can see it happening, but I expect the guys at Sun to have been smart about it.

 

[Robert Trevellyan]

You have to read the whole paragraph. The author seems to believe that simply resilvering involves writing to all member disks with RAIDZ.

 

[anodos]

You have to read the whole paragraph. The author seems to believe that simply resilvering involves writing to all member disks with RAIDZ.

This is the reason why I try not to read blog posts too carefully. Just skim and look at pictures.

 

[danb35]

"all of the remaining disks in a RAIDZ vdev are being much more heavily loaded with writes as well as reads during a resilver"

Yeah, I didn't think that one was right either, but I figured I'd focus on what I knew to be wrong (from personal experience, no less), rather than just what I believed to be wrong. Known factual errors don't do much for the credibility of the rest of the post. But really, despite OP bringing it up, it's completely orthogonal to his question.

 

[Robert Trevellyan]

The proper source for the 'home users should just use mirrors' argument is this: http://constantin.glez.de/blog/2010/01/home-server-raid-greed-and-why-mirroring-still-best