Basically means one more system to set up and maintain, wasted disk space for the VM and its OS. Then there are issues with attributes, symlinks, etc. exposing devices to the VM, all a lot more hassle than just dropping to the shell, physically attaching a drive and issuing an local rsync command, or a cp.
Reminds me of the old phrase: why do it simply when there’s a way to do it complicated… 
Yes.
The Linux way of throwing everything and the kitchen sink in a big bloated kernel is a problem.
The constant, vague accusations about the Linux kernel being “bloated” are getting tiresome and are intellectually lazy. Before throwing around such phrases, how about we look at some actual facts?
Let’s take the example of dm-mod.ko, which is often implicitly criticized in these discussions:
That’s the real “bloat” we’re talking about. This is for a driver that provides fundamental functionalities like LVM, software RAID, and disk encryption—features essential for servers, power users, and complex systems.
For perspective:
The Linux kernel is modular by design. You only load what you need. This architecture perfectly supports everything from minimalist embedded systems to full-featured servers.
So let’s cut the superficial “kernel bloat” chatter. If you have legitimate criticism, please bring concrete numbers, specific use-cases, and substantive arguments. Anything else is just hot air without any real value.
Sure, because it’s so bloated and so insecure must be the reason it’s by a far cry to most used server operating system, adopted by giants like IBM, and many others.
Heck, if it’s so horrible, why did TrueNAS not stick with BSD… 
Sorry, don’t buy it. Feature for feature it’s among the leanest and most well tested and scrutinized kernels out there. Is it perfect? No, but what is, except maybe TeX 
Many many critical systems contain that “bloat” and are perfectly secure, with the vast majority of all security vulnerabilities not originating in the kernel for a long, long time now.
Sorry you are running an enterprise NAS system and the 10GB of space for the VM is what is going to get you? There is nothing to maintain it is a VM that has no public network access it could be a decade out of date and still work. It also doesn’t require any major customization, you could write a shell script to install whatever FS related packages or configure NFS like I mention above and then boot some stock Ubuntu or other image, run the shell script and be up and running in minutes without having to keep anything ‘maintained’.
Rsync is designed to run over network, it would be a perfect way to sync things into truenas.
I think the reason here is to treat truenas as an appliance and not a general purpose OS. There is already OpenZFS for running ZFS in any way you like on any OS you like. A feature of truenas is to be able to download your truenas config blow away your OS partition and recreate truenas without problems. The more you adjust the underlying OS the less likely that is going to work as designed.
When you talk about needing raid, LVM and other features, again it speaks to using a proper VM to do so. That ensures changes in truenas don’t break your ‘complex systems’ as they operate in an OS you control inside a VM.
The developers likely had a reason for removing it, and while I don’t think supporting this specific feature would likely break the bank, the arguments for re-adding it just seem very weak to me. it is a feature request forum though so those who do have this need will certainly continue to vote for it.
It’s a straw man argument when you bring up OS configuration etc.
Nobody said anything about changing the way features work or about exposing anything but ZFS volumes to the UI. So nothing affects the config.
The question is: is support for standard file systems in the kernel and are the relevant CLI tools part of the OS installation. They are all standard Debian packages. There’s no need to configure anything.
It’s simply a question of whether you can drop to the shell, manually mount a device and copy files, or if you can’t.
Absolutely ZERO impact on config files. It adds a negligible number of CLI tools to the installer image and requires the kernel to be compiled without actively stripping support for these file systems. That’s it.
As for setting up a VM: it time, clutter, steals computing resources (RAM, CPU cores, disk space, backup space), eats time through needless extra steps, and yes, administrative effort, because I wouldn’t tolerate random outdated and mismatched OS versions to linger in some VM
Some NAS systems, and mind you I do NOT suggest TrueNAS should be doing this, automatically import data from external volumes like SD cards or portable drives attached to them, convenience features that go too far and give the user too little control, but show that attaching drives and importing data is core to what a NAS appliance should be able to do.
Heck, I’d argue, that this is more central to a storage appliance that running virtual machines on it.
Core is: data import/export, data storage, network shares
(with as many protocols as possible), backup, cloud storage connectivity for backup and data import/export.
Virtualization, as much as I love to have it, is actually NOT central to NAS or a storage server. So if anyone wants to make the case that TrueNAS were too cluttered and bloated, then virtualization would need to go before native ability to import/export data from/to a variety of external data sources formatted in a variety of file systems. Is that a case you want to make?
Thank you for your excellent response.
I fully understand the appliance centric approach the TrueNas team have taken, but like yourself I expect certain core Linux filesystem centric capabilities to be present, including the ability to read encrypted disks plus support for a very wide range of legacy filesystems.
The filesystem support can be largely resolved these days with fuse, but other than using a VM or a secondary device there isn’t a simple way to support dm-crypt unless it is been built for the distribution.
Part of my own personal backup schedule are a bunch of luks encrypted large drives with appropriate rsync scripts to handle crucial data. Whilst I can make this work over the network, it just feels awfully inefficient.
Thank you for submitting this feature request. After keeping it open to gauge community interest, we’re closing it as it hasn’t received enough votes to prioritize for development.
