- Joined
- Jan 1, 2016
- Messages
- 9,703
I have seen a bunch of folks asking about this and I have been thinging about it in terms of how it could be done (and why) and I think maybe there's some merit to a very quick and easy setup that I was thinking could use some input from others...
So, let's start with the "Why would you do that?"
I want to have a server in a super-small chassis that for some reason I just need to store not so much data and will never need to grow beyond what fits in that chassis.
I want the great features offered by TrueNAS and to be able to run plugins/jails (maybe VMs*), I'm just a home user and I don't really care if it's all going to get lost at some point (although it would be nice if it didn't, so maybe I'll replicate it to another one in another room or at a friend's house for the just-in-case).
I want a small box with just a couple of SSDs that runs quiet.
I want to run TrueNAS in the cloud and do something cool with it that I can't do at home.
I want to test out TrueNAS with some very basic hardware (can't count the number of times I see folks saying they want to run it on a laptop).
I think all of those use cases exist and we could get into the details of why you should probably get better hardware and think carefully about how much you love your data (which may just be some videos, music or photos you want to store and look at/listen to or may be your entire life's history/business documents/financial records/important stuff... if it's the former, keep reading, if it's the latter, time to ship out and look at other options).
OK, so we've cleared 2 things if you're still reading at this point...
So, now, How do you do that?
Well, you have options... I'm not claiming to have a monopoly on this idea or an implementation of it, so here are the 2 options (other than mine) that you could look at (1 for each of TrueNAS Core and SCALE) :
www.truenas.com
www.truenas.com
Those methods will land you with an unsupported config that may or may not break with upgrades and are clearly stated as not supported (neither is my option, but more on that in a minute).
Those are fine methods and I'm not poking any holes in them, so don't get me wrong here, I'm trying to propose something much easier to do (not saying it's a better result... maybe it's not as good #).
So, what's your method?
My method uses the concept of a sparsefile (or you could do 2 if you want to account for the potential for metadata corruption somewhere down the line in a single file... be aware this will mean twice the IOPS used for everything and twice the space, so it comes at a price if you do it... maybe worth it on a mirrored setup, I wouldn't recommend it for a single drive).
That sparsefile or sparsefiles live on your boot pool, so should benefit from the fact that your boot drive(s) are on ZFS and being SMART tested and scrubbed occasionally. The sparsefile(s) won't take more space than needed, although crazy things with snapshots wouldn't be a recommendation as reclaiming that space for the boot pool once consumed in the sparsefile pool could be a little tricky (make new sparsefile, resilver it into the pool, remove the old one... must have enough space for that, which might be your problem in the first place).
So here's my method:
You're going to follow the regular install instructions to install to one or more disks (probably SSD(s) and get to the point where you can use the shell via GUI or SSH, choose your poison):
https://www.truenas.com/docs/scale/gettingstarted/ (scale docs not there yet)
tank will be your pool name, so rename as you see fit when you get to those steps
Option 1:
Single/stripe pool version (you can do this on a mirrored boot pool too)
Option 2:
Mirrored pool version (not recommended for a single drive setup, but can be done in both options)
Continue here after you chose mirrored or single/stripe:
Import tank from Storage Pools Add (Import an existing pool).
And there you have it... A TrueNAS server on one or 2 disks (including boot pool).
OK, so what could be the problems with this? (or, Why wouldn't we just do it like this all the time?)
Sparsefile(s) filling the boot pool: You would see warnings as normal for a filling boot pool, but there are several reasons that you could find yourself stuck and needing to reinstall (as mentioned above if you go nuts with snapshots, for example).
Corruption: Your sparsefiles are on a ZFS volume, so there's some protection but as you can see from the "Virtual Devices" manual quote below, it's simply not recommended as stable... doesn't mean it won't work, but certainly doesn't say it will.
Performance: OK, so I'm going to call you out on this one... don't expect miracles. I don't think there's too much complaining that can be done in this area on the hardware we're talking about. That said, maybe we're in the cloud scenario here and you will want to look at options of adding more virtual disks to get more performance... remembering that your data may not be protected by SMART information/direct disk access being fed back to the appliance/ZFS.
What is clear here, is that ZFS running on top of ZFS is going to be generating two checksums for each block, so there will be that overhead/performance hit.
OK; that's it for now... I'm sure there will be some feedback, which I hope will be fair if not positive, so have at it.
* all of this having been said, I think running VMs on this setup is true insanity, but who am I to judge?
# This quote from the zpool command reference from illumos:
So, let's start with the "Why would you do that?"
I want to have a server in a super-small chassis that for some reason I just need to store not so much data and will never need to grow beyond what fits in that chassis.
I want the great features offered by TrueNAS and to be able to run plugins/jails (maybe VMs*), I'm just a home user and I don't really care if it's all going to get lost at some point (although it would be nice if it didn't, so maybe I'll replicate it to another one in another room or at a friend's house for the just-in-case).
I want a small box with just a couple of SSDs that runs quiet.
I want to run TrueNAS in the cloud and do something cool with it that I can't do at home.
I want to test out TrueNAS with some very basic hardware (can't count the number of times I see folks saying they want to run it on a laptop).
I think all of those use cases exist and we could get into the details of why you should probably get better hardware and think carefully about how much you love your data (which may just be some videos, music or photos you want to store and look at/listen to or may be your entire life's history/business documents/financial records/important stuff... if it's the former, keep reading, if it's the latter, time to ship out and look at other options).
OK, so we've cleared 2 things if you're still reading at this point...
- You want a NAS with one or only a couple of disks and no more
- You don't put your crown jewels of data on it
So, now, How do you do that?
Well, you have options... I'm not claiming to have a monopoly on this idea or an implementation of it, so here are the 2 options (other than mine) that you could look at (1 for each of TrueNAS Core and SCALE) :
HOWTO: setup a pair of larger SSDs for boot pool and data
Moderator Warning: This HOWTO will damage the ability of your TrueNAS appliance to properly maintain itself, will break the ability to replace failed drives, and may cause problems with upgrades and updates. TrueNAS is not designed to do this sort of partitioning, and the developers are not...
www.truenas.com
HOWTO: Using a pair of large SSDs with boot and data pools for SCALE
Moderator Warning: This HOWTO will damage the ability of your TrueNAS appliance to properly maintain itself, will break the ability to replace failed drives, and may cause problems with upgrades and updates. TrueNAS is not designed to do this sort of partitioning, and the developers are not...
www.truenas.com
Those methods will land you with an unsupported config that may or may not break with upgrades and are clearly stated as not supported (neither is my option, but more on that in a minute).
Those are fine methods and I'm not poking any holes in them, so don't get me wrong here, I'm trying to propose something much easier to do (not saying it's a better result... maybe it's not as good #).
So, what's your method?
My method uses the concept of a sparsefile (or you could do 2 if you want to account for the potential for metadata corruption somewhere down the line in a single file... be aware this will mean twice the IOPS used for everything and twice the space, so it comes at a price if you do it... maybe worth it on a mirrored setup, I wouldn't recommend it for a single drive).
That sparsefile or sparsefiles live on your boot pool, so should benefit from the fact that your boot drive(s) are on ZFS and being SMART tested and scrubbed occasionally. The sparsefile(s) won't take more space than needed, although crazy things with snapshots wouldn't be a recommendation as reclaiming that space for the boot pool once consumed in the sparsefile pool could be a little tricky (make new sparsefile, resilver it into the pool, remove the old one... must have enough space for that, which might be your problem in the first place).
So here's my method:
You're going to follow the regular install instructions to install to one or more disks (probably SSD(s) and get to the point where you can use the shell via GUI or SSH, choose your poison):
tank will be your pool name, so rename as you see fit when you get to those steps
Option 1:
Single/stripe pool version (you can do this on a mirrored boot pool too)
truncate -s 1T /root/sparsefile (1T means 1 Terabyte... adjust to 100G, 5T or whatever... that space is not immediately consumed, but be warned that setting it any higher than your actual pool capacity... minus a bit for the boot pool... would be folly)zpool create -f -m /mnt/tank tank /root/sparsefileOption 2:
Mirrored pool version (not recommended for a single drive setup, but can be done in both options)
truncate -s 1T /root/sparsefile1truncate -s 1T /root/sparsefile2zpool create -f -m /mnt/tank tank mirror /root/sparsefile1 /root/sparsefile2Continue here after you chose mirrored or single/stripe:
zpool export tankImport tank from Storage Pools Add (Import an existing pool).
And there you have it... A TrueNAS server on one or 2 disks (including boot pool).
OK, so what could be the problems with this? (or, Why wouldn't we just do it like this all the time?)
Sparsefile(s) filling the boot pool: You would see warnings as normal for a filling boot pool, but there are several reasons that you could find yourself stuck and needing to reinstall (as mentioned above if you go nuts with snapshots, for example).
Corruption: Your sparsefiles are on a ZFS volume, so there's some protection but as you can see from the "Virtual Devices" manual quote below, it's simply not recommended as stable... doesn't mean it won't work, but certainly doesn't say it will.
Performance: OK, so I'm going to call you out on this one... don't expect miracles. I don't think there's too much complaining that can be done in this area on the hardware we're talking about. That said, maybe we're in the cloud scenario here and you will want to look at options of adding more virtual disks to get more performance... remembering that your data may not be protected by SMART information/direct disk access being fed back to the appliance/ZFS.
What is clear here, is that ZFS running on top of ZFS is going to be generating two checksums for each block, so there will be that overhead/performance hit.
OK; that's it for now... I'm sure there will be some feedback, which I hope will be fair if not positive, so have at it.
* all of this having been said, I think running VMs on this setup is true insanity, but who am I to judge?
# This quote from the zpool command reference from illumos:
Code:
Virtual Devices (vdevs)
A "virtual device" describes a single device or a collection of devices
organized according to certain performance and fault characteristics. The
following virtual devices are supported:
disk A block device, typically located under /dev/dsk. ZFS can use
individual slices or partitions, though the recommended mode of
operation is to use whole disks. A disk can be specified by a full
path, or it can be a shorthand name (the relative portion of the
path under /dev/dsk). A whole disk can be specified by omitting
the slice or partition designation. For example, c0t0d0 is
equivalent to /dev/dsk/c0t0d0s2. When given a whole disk, ZFS
automatically labels the disk, if necessary.
file A regular file. The use of files as a backing store is strongly
discouraged. It is designed primarily for experimental purposes,
as the fault tolerance of a file is only as good as the file system
of which it is a part. A file must be specified by a full path.
Last edited:
