Question for DEVs RE: Directory Structure & Upgrades

[NASbox]

I need to create a directory for custom scripts (mainly for test/maintenance), and I want this directory totally independent from my storage pools so that I can use it even with my pool disks disconnected from the system.

I used to use a UDF USB Drive, but now that I have upgraded to V11, UDF is not an option.

Since I'm a 120GB SSD (so it's way over provisioned for the task), as my boot volume, it was suggested that the boot volume would be a good place for the custom scripts with a backup on one of the pools.

My plan is to create a directory /custom at the root of the file system. I can't see any reason not to do this, and since it's a non-standard name, I would not expect that it's likely to get overwritten. (As an alternative I could use something link /root/bin /root/local, but I'm worried that my changes might get overwritten as /root contains system created files, and it's not as clean to back up.)

Is there any reason NOT to do this?

Is it going to cause any problems with the existing code?

Is it going to be overwritten by FreeNAS upgrades (other than a complete wipe/reinstall)?

Thanks in advance for input from someone on the Dev Team that knows the system well.

 

[garm]

While we wait for someone from iX to reply I’ll give you my opinion.
To me the main point in running FreeNAS as opposed to self configured FreeBSD or OpenBSD is that I get the OS backup. This is as we know achieved by the configs database.

What that means to me is that the boot pool is “voletile” and I really don’t want to change it in any way outside of the configs database. If I loose it I expect to be back to a known state more or less in the time it takes to reinstall FreeNAS.

Given this, what I do with custom scripts, keys etc is that I create either a jail for them or a separate pool. A USB key with copies=2 for instance is where I keep custom scripts.

 

[NASbox]

Thanks very much for your reply.

While we wait for someone from iX to reply I’ll give you my opinion.
To me the main point in running FreeNAS as opposed to self configured FreeBSD or OpenBSD is that I get the OS backup. This is as we know achieved by the configs database.

What that means to me is that the boot pool is “voletile” and I really don’t want to change it in any way outside of the configs database. If I loose it I expect to be back to a known state more or less in the time it takes to reinstall FreeNAS.

I agree entirely, which is why I want to keep everything under one directory (or if it's OK, maybe even create a dataset). I want it very quick and easy to backup/restore-quick tar/untar should do just fine.

It's just one more small thing to back up. A few hundred kb at most, and for the most part, read only-for my application a jail would be major overkill, and if the jail system changes there would be extra work to get running again. All I have is a few simple backup scripts, restore scripts, diagnostic scripts, utilities - each file being less than (often way less) than 500 lines of python, awk or shell script.

I need to know if the whole drive gets flattened on routine updates. Even if it does, it's not a big deal to pull a copy back after an update as long as what I'm doing doesn't interfere with anything.

Given this, what I do with custom scripts, keys etc is that I create either a jail for them or a separate pool. A USB key with copies=2 for instance is where I keep custom scripts.

Funny thing is I saw the opposite point of view raised which is why I created this thread. The suggestion was to create and use the tools directory on the boot drive and back it to one of the pools (and maybe a second copy on my workstation). USBs are failure prone, and it's great to avoid another piece of hardware if possible.

 

[Arwen]

You know, at present mine are in my user home directory, (in the storage pool). But, I'd not mind a copy on the boot DOMs.

Perhaps a ZFS dataset, (independant from the boot data dataset), but in the boot pool. It would be best if the name and mountpoint were blessed by iXsystems so that at least there was a chance it would be left alone on upgrades. It probably should have a serious quota on it, based on boot device size. Plus, allow "copies=2", for those without mirrored boot devices.

If I get a chance, I may make a bug / feature request for this. And if I do, I will post the number and link here.

 

[NASbox]

You know at present mine are in my user hone directory, (in the storage pool). But, I'd not mind a copy on the boot DOMs.

Perhaps a ZFS dataset, (independent from the boot data dataset), but in the boot pool. It would be best if the name and mountpoint were blessed by iXsystems so that at least there was a chance it would be left alone on upgrades. It probably should have a serious quota on it, based on boot device size. Plus, allow "copies=2", for those without mirrored boot devices.

If I get a chance, I may make a bug / feature request for this. And if I do, I will post the number and link here.

Thanks Arwen - Pardon my ignorance, I'm a real ZFS noob - Is anything preventing creating that dataset now? (Clearly it is subject to removal unless iXsystem blesses it.)
Could a snapshot of that dataset be made to the pool?

That would be great if you could submit a feature request.

 

[Arwen]

Thanks Arwen - Pardon my ignorance, I'm a real ZFS noob - Is anything preventing creating that dataset now? (Clearly it is subject to removal unless iXsystem blesses it.)
Could a snapshot of that dataset be made to the pool?

That would be great if you could submit a feature request.

Yes, as root from the command line you can basically do pretty much anything.
And yes, you could create snapshots of this script storage dataset.

To be clear, many things done from the command line, like organizing your data, (without having it go over the network twice), are perfectly fine. But, anything that changes the hardware configuration, (like network or storage), can be problematic as FreeNAS the application as it may not know about the change.

 

[NASbox]

Yes, as root from the command line you can basically do pretty much anything.
And yes, you could create snapshots of this script storage dataset.

To be clear, many things done from the command line, like organizing your data, (without having it go over the network twice), are perfectly fine. But, anything that changes the hardware configuration, (like network or storage), can be problematic as FreeNAS the application as it may not know about the change.

Thanks for the reply Arwen... my language was very sloppy - I do understand a bit of basic CLI, in fact, I'm more comfortable doing my scrubs and zpool status from the CLI than the GUI.

Let's see if I can ask what I really meant-two things:

There was also a subtext which you picked up with this statement:
"anything that changes the hardware configuration, (like network or storage), can be problematic"
So I am really asking "am I going to break something" if I create this pool?

Is it possible to create a dataset for example "custom" on pool: freenas-boot, make a snapshot of that dataset, and then replicate that dataset to an existing pool: TANK which is the main storage pool? i.e. Can a dataset be copied in one operation, and added to another pool, or does it overwrite the pool?

 

[Arwen]

Thanks for the reply Arwen... my language was very sloppy - I do understand a bit of basic CLI, in fact, I'm more comfortable doing my scrubs and zpool status from the CLI than the GUI.

Let's see if I can ask what I really meant-two things:

There was also a subtext which you picked up with this statement:
"anything that changes the hardware configuration, (like network or storage), can be problematic"
So I am really asking "am I going to break something" if I create this pool?

I think you meant ZFS dataset here, not pool. No, you are not likely to break something by manually creating a dataset on the boot pool. But, if something does go wrong, it may waste time to determine the cause.

Note that the boot pool does not turn on all the ZFS feature flags. I would NOT change that.

Is it possible to create a dataset for example "custom" on pool: freenas-boot, make a snapshot of that dataset, and then replicate that dataset to an existing pool: TANK which is the main storage pool? i.e. Can a dataset be copied in one operation, and added to another pool, or does it overwrite the pool?

Yes, all that can be done. But some of that likely can't be done from the GUI, as automatic snapshots probably won't list the boot pool. And the GUI replication likely won't allow boot pool sources.

Basically:

• Backup your configation off NAS, (and if desired, on NAS to the data pool as well)
• Be careful of space used on the boot pool
• If you do notice something weird, back out your change. If needed, make new clean install and restore configuration.
• Don't do this on un-mirrored USB boot devices, (or perhaps not on USB boot devices at all)
• Leave the boot pool attributes alone
• Leave all the other boot pool dataset attributes alone
• Document your changes

Gee, I make it sound like a real procedure. Probably from working in the industry too long, for 3 letter companies and agencies like NS... Ops, their is no such agency.

 

[Arwen]

I opened up the feature request;

https://bugs.freenas.org/issues/26331

We will see what they have to say.

To be clear, FreeNAS as it's currently designed, is supposed to run off dedicated media. Those of us with larger boot media simply have to understand that.

And of course, like anything, it will be abused. Even in ways none of us can predict.

 

[NASbox]

I opened up the feature request;

https://bugs.freenas.org/issues/26331

We will see what they have to say.

To be clear, FreeNAS as it's currently designed, is supposed to run off dedicated media. Those of us with larger boot media simply have to understand that.

And of course, like anything, it will be abused. Even in ways none of us can predict.

I think we have entered a new era with FreeNAS, the directions were always to install on a USB, now the push is towards SSD. The last time I went to buy an SSD, the smallest/cheapest I could buy locally was 120GB, and I'll bet it won't be long before that's 250GB.

Thanks for taking that on, I appreciate it :) Really nice write up. You said it really well, not for sharing, we have this abundant resource, let it be used intelligently.