Users home directory forced into the /mnt directory and NOT the OSs drive, why? (apps too)

[nothing]

GID:3000
Home Directory:/mnt/CHUNK/$user
Shell:/usr/bin/bash
Email:lmao@happygo.lucky
Password Disabled:false
Lock User:false
Samba Authentication:true
Allowed Sudo Commands:ALL
Allowed Sudo Commands (No Password):ALL

When you attempt to switch it to /home/$user like how the admin user is and every other linux distro on the planet is, it tells you it must start with /mnt or /nonexistent

Why would i want to have my .bash_profile and all other home dir stuff in my raid array? Its meant to have only volumes that will be mounted on windows .. i would prefer to not see linux stuff in there.

also can u just install the apps on the same disk as the OS? its the same issue with the apps, once you enable them they want to sit in your array - so strange you do not have the option to put it on the same disk as the OS.

I updated /etc/passwd file to force $user to have his home where it should be in /home, so far no issues but im sure they did this for a reason and im sure itll likely break something.

 

[danb35]

TrueNAS, and FreeNAS before it, and the other project previously called FreeNAS before that, and m0n0wall before that, all have the same design: the boot device doesn't store user data; it only stores the OS. Which means the answer to:

Why would i want to have my .bash_profile and all other home dir stuff in my raid array?

and

can u just install the apps on the same disk as the OS?

are "because that's now the system is design," and "no," respectively.

every other linux distro

TrueNAS isn't a "Linux distro;" it's an appliance OS that happens to be built on top of Debian.

 

[nothing]

TrueNAS, and FreeNAS before it, and the other project previously called FreeNAS before that, and m0n0wall before that, all have the same design: the boot device doesn't store user data; it only stores the OS. Which means the answer to:

and

are "because that's now the system is design," and "no," respectively.

TrueNAS isn't a "Linux distro;" it's an appliance OS that happens to be built on top of Debian.

thanks for the info!

could I put in a second ssd and create a pool just for that ssd that i can put the applications and users in.. ( i just want to separate it from the main arrays' storage if possible)

or if you have another idea? I am a newbie so just getting started with TrueNAS scale.

 

[nothing]

Also - can we move the ZFS cache to maybe a gen4 m2 instead of using system memory for it?

 

[winnielinnie]

could I put in a second ssd and create a pool just for that ssd that i can put the applications and users in.. ( i just want to separate it from the main arrays' storage if possible)

Yes. Preferably a 2-way mirror at minimum. Better to have redundancy than not.

I'll admit, it kind of sucks that TrueNAS doesn't offer the ability to add datasets to your boot-pool. It would be the perfect place for Apps/Jails and user home dirs. (There is a way to do this manually in the command-line, but it's not officially supported, and can cause issues.)

can we move the ZFS cache to maybe a gen4 m2 instead of using system memory for it?

Are you referring to an L2ARC device? You might not need one, even if you think you do.

 

[nothing]

Yes. Preferably a 2-way mirror at minimum. Better to have redundancy than not.

I'll admit, it kind of sucks that TrueNAS doesn't offer the ability to add datasets to your boot-pool. It would be the perfect place for Apps/Jails and user home dirs. (There is a way to do this manually in the command-line, but it's not officially supported, and can cause issues.)



Are you referring to an L2ARC device? You might not need one, even if you think you do.

You are saying we dont need a read/write cache? Please explain - again im a newbie so genuine question here..I thought since synologys and qnaps allow you to use a read/write cache that truenas would support that as well..

 

[danb35]

You are saying we dont need a read/write cache?

ZFS implements both read and write caching in RAM. You can add a fast SSD as a second-level read cache (L2ARC), but first add RAM--if you've maxed out your RAM and your ARC hit ratio is still low, then look at a L2ARC device. There really isn't an option for a write cache as most people think of it--SLOG, which is ZFS' closest equivalent, is useful only in cases that require sync writes, which are relatively uncommon.

 

[winnielinnie]

You are saying we dont need a read/write cache?

Most home users don't.

Your RAM is your "write cache" anyways. A SLOG is not a write cache. (This has been discussed at length many times in these forums.)


As far as a "read cache" goes, the best device for that, once again, is your RAM. (This is where the ARC lives.) Increase your RAM, hence more room for a larger ARC, hence an improved "read cache".

You can get a dedicated fast device (such as an NVMe) to serve as the pool's L2ARC. This second level is where records (evicted from ARC in RAM) can be stored. If and when they are needed, they can be loaded from the NVMe much faster than if they had to be pulled from the spinning HDDs. (RAM/ARC fastest -> L2ARC fast -> HDD slow)

The catch is that the ARC is usually good at lessening the dependence on pulling data from the HDDs that are frequently demanded, and so your L2ARC might not get that much action. Another catch is that some RAM is used to index what currently lives on your L2ARC. (So it's not even a true "freebie".)


If you spend the money on increasing your RAM, rather than opting for a fast NVMe, you'll likely see more practical benefits.

 

[jgreco]

Also - can we move the ZFS cache to maybe a gen4 m2 instead of using system memory for it?

No. ZFS cache has to come from main memory. This can be augmented with SSD, but typically you need to get 64GB of ARC (meaning 64GB RAM on CORE or 128GB RAM on SCALE) before L2ARC becomes truly useful. Otherwise you end up shuffling stuff in and out of main memory to the SSD that isn't highly effective, wasting the SSD. If you have 64GB of ARC, you can support at least 5x that amount for L2ARC (about 250GB) but probably no more than 10x that amount (so a practical cap around 500GB if you have 64GB ARC).

 

[nothing]

I kind of wish you could move the cache outside of the system memory or at least move a % onto disk because it shares it with VMs, so the more VMs you use the less cache you have available whereas if cache were moved to disk - memory could be better utilized by the system. Sure nvme is not as fast as DDR5 - but im not certain i would notice the difference.

Is this just newbie ignorance? are my concerns about shared memory invalid because i dont know enough about truenas yet?

 

[HoneyBadger]

If the desire is just to avoid seeing the home directories, you can easily create a separate dataset such as /mnt/CHUNK/homedirs and then point home directories there.

If you're just creating new users for them to have access from Windows systems over SMB though, they don't necessarily need a home directory. Are you planning to have these users connect over SSH or otherwise have a shell/scripting level of interaction with your TrueNAS system?

 

[Patrick M. Hausen]

@nothing A metadata vdev that holds (as the name indicates) metadata and small files (if configured that way) might be what you are looking after. You need a redundant vdev for that, because the integrity of your pool depends on it. I use it for all new SMB servers I build. 4x spinning drives, 2x smaller SSDs. Speeds up Samba directory lookups, so file browsing on network shares feels a lot snappier with multiple users.

 

[nothing]

If the desire is just to avoid seeing the home directories, you can easily create a separate dataset such as /mnt/CHUNK/homedirs and then point home directories there.

If you're just creating new users for them to have access from Windows systems over SMB though, they don't necessarily need a home directory. Are you planning to have these users connect over SSH or otherwise have a shell/scripting level of interaction with your TrueNAS system?

yea - while im a newb with truenas - i do have a linux background (started on Debian about 20 years ago) so yea i left root disabled and made myself a user with root privs.. i use ssh to connect and try to learn to do things on the command line. i thought for sure the raidz1 setup was totally independent and not required for installing apps / and or linux os user data however this is just an initial impression immediately after setup with 0 real truenas experience.

Now i find out you cannot even use smb shares in plex (without hacking it, which sucks pretty badly) - so there are alot of obstacles that dont make much sense to me now, however most are likely due to my inexperience with nas setups/truenas.

 

[jgreco]

Is this just newbie ignorance? are my concerns about shared memory invalid because i dont know enough about truenas yet?

There is an apropos saying sourced from @WI_Hedgehog on my profile ...

"ZFS eats RAM like a fat man at an all-you-can-eat fried chicken buffet." -- @WI_Hedgehog

The idea is to add more RAM. Worrying about how VM's share RAM with ARC is basically nonsense; size your filer for the job. If you need more than 32GB of RAM, do not buy a board capped at 32GB and then whine about it. Buy a board capable of 64GB instead, and fill it with 64GB.

I kind of wish you could move the cache outside of the system memory or at least move a % onto disk because it shares it with VMs, so the more VMs you use the less cache you have available whereas if cache were moved to disk - memory could be better utilized by the system. Sure nvme is not as fast as DDR5 - but im not certain i would notice the difference.

You need neither DDR5 nor NVMe. A HDD based system will do just fine with a SATA SSD for L2ARC, or better yet a pair of them. A DDR3 system filled with 512GB of RAM is going to be amazingly better than a pathetic limited-memory 64GB DDR5 system. ZFS has to have the ARC in memory because the ARC is the mechanism that is used to track what is in the L2ARC, so it is advantageous to stuff lots of memory in your system and then take advantage of it. If you come from the world of Linux where people freak out about memory use, you're at a disadvantage. ZFS was built on Solaris and targeted at large-to-massive servers where memory consumption for substantially faster I/O is considered an equitable tradeoff. They're not going to redesign ZFS at this late date just because you'd rather have the cache someplace other than system memory. If you want that, BTRFS is ---> thataway, have a nice day. Otherwise, just load up on sufficient memory for your workload, which includes both ARC and VM considerations.

 

[danb35]

Buy a board capable of 64GB instead, and fill it with 64GB.

Or better yet, buy a board capable of 128 GB or more and populate it with 64GB--and then expand if needed.

 

[jgreco]

Or better yet, buy a board capable of 128 GB or more and populate it with 64GB--and then expand if needed.

Bested by @damnb35 once again. (deliberate typo is a friendly jab, to those in the audience who could not guess)

 

[danb35]

@damnb35

 

[Patrick M. Hausen]

Bested by @damnb35 once again. (deliberate typo is a friendly jab, to those in the audience who could not guess)

I'd expect nothing less of the ambassador.