Truenas Scale mount exist ext4 disk for SMB

ptprince

Cadet
Joined
Mar 6, 2021
Messages
4
Hello,

I'm new here and I used openmediavault before.

I had new installed system disk, two existed zpools, and one existed single ext4 disk as data.

For zpools, it's easy to import and share by samba.
However for ext4 disk, I mounted to /mnt/data by edit /etc/fstab,
but when I try to add to smb shares, I got an error "The path must reside within a pool mount point".

Does it mean only dataset in the zpool can be shared by smb?

Regards
 

Arwen

MVP
Joined
May 17, 2014
Messages
3,600
The original FreeNAS / TrueNAS allowed UFS & ZFS. At some point, UFS was deprecated in favor of ZFS.

With the advent of TrueNAS Scale, support for Linux file systems as "first class", (like ZFS), does not seem to have been considered or implemented.

First question: Is their any reason why the data on your EXT4 disk can't be changed over to ZFS?
Next: If so, describe it well enough so that either a bug can be created to support EXT4 shares, or fix using ZFS for that use case.

Note that TrueNAS Core or Scale were not designed for swapping data hard drives on a regular basis. Meaning, if your goal is to remove the EXT4 disk and use it on another Linux server, you can do so with ZFS formatted disks. (I do so with my desktop, media server and laptops backup disks.)

Further, TrueNAS Scale is eventually intended to support clustering. It's not completely clear how at the moment, as I am sure some details are to be worked out.
 

morganL

Captain Morgan
Administrator
Moderator
iXsystems
Joined
Mar 10, 2018
Messages
2,691
Yes, only ZFS pools and datasets can be shared. THe middleware assumes that all the snapshots and replication tasks can be done by ZFS. ZFS Mirrors and RAID-Z provide the data protection.

For SCALE, we'll be adding a scale-out ZFS capability by marrying gluster and ZFS.

So, best approach is to copy EXT3 data to a ZFS dataset that has been set-up for SMB sharing.
 

ptprince

Cadet
Joined
Mar 6, 2021
Messages
4
The original FreeNAS / TrueNAS allowed UFS & ZFS. At some point, UFS was deprecated in favor of ZFS.

With the advent of TrueNAS Scale, support for Linux file systems as "first class", (like ZFS), does not seem to have been considered or implemented.

First question: Is their any reason why the data on your EXT4 disk can't be changed over to ZFS?
Next: If so, describe it well enough so that either a bug can be created to support EXT4 shares, or fix using ZFS for that use case.

Note that TrueNAS Core or Scale were not designed for swapping data hard drives on a regular basis. Meaning, if your goal is to remove the EXT4 disk and use it on another Linux server, you can do so with ZFS formatted disks. (I do so with my desktop, media server and laptops backup disks.)

Further, TrueNAS Scale is eventually intended to support clustering. It's not completely clear how at the moment, as I am sure some details are to be worked out.

Hi Arwen,

Thank you for your reply.

The reason for why data on my Ext4 disk is
I also created an zpool for important data.
But for some unimportant data (like movie downloading disk), single disk is enough for me.

So I would like to use both regular linux file system and zfs system for my different needs.

After Using Truenas Scale one day, I decided to go back to OMV.
I think it is not a good timing to replace to a alpha nas system with data at this moment.
I 'm still interested in Truenas Scale, maybe I will replace to it after release.

Regards
 

ptprince

Cadet
Joined
Mar 6, 2021
Messages
4
Yes, only ZFS pools and datasets can be shared. THe middleware assumes that all the snapshots and replication tasks can be done by ZFS. ZFS Mirrors and RAID-Z provide the data protection.

For SCALE, we'll be adding a scale-out ZFS capability by marrying gluster and ZFS.

So, best approach is to copy EXT3 data to a ZFS dataset that has been set-up for SMB sharing.

Hi morganL,

Thank you.

I would like to use single disk (ext4) for my unimportant data.
As I replied to Arwen, I decided to go back to OMV at this moment.

Hope Scale will be better and better.
 

bodly

Dabbler
Joined
Jan 1, 2021
Messages
16
Hi morganL,

Thank you.

I would like to use single disk (ext4) for my unimportant data.
You can create a single disk ZFS pool.

As I replied to Arwen, I decided to go back to OMV at this moment.

Hope Scale will be better and better.
It is definitely early days yet. But I don't expect that your particular use case (export ext4 filesystem) will be supported.

Best of luck to you with OMV.
 

Arwen

MVP
Joined
May 17, 2014
Messages
3,600
To re-iterate @bodly, you can use single disk ZFS pools. I have them all over for my backup disks, and alternate boot media for my computers, (MicroSDXC card in my media server, USB flash drive on my desktop & laptop).

Their are advantages of using ZFS even in a single disk pool:
  • Compression, (not as important for pre-compressed media files, but does not hurt to enable it)
  • No more long file system check at boot. (Even if it only occurs every 3 months, a 8 or 10TB disk can take hours to perform a file system check with EXT4. I know, tried it in a real production data center...)
  • Scrubs. Even if ZFS can't fix the problem for you, knowing you have a corrupt file makes a serious difference. I have gotten perhaps 8/10 corrupt media files on my media server over the last 5 years, that does not use any redundancy. Most of those were larger, video files, (which I guess increased the statistically probability they would get a bad block). Knowing about the bad files allowed me to restore them from backup.
  • Redundancy for metadata, including directory entries is enabled by default. This can help prevent an entire directories' worth of data vanishing because of a bad block. ZFS CAN and WILL fix these automatically on read, (or scrub), even on a pool without data redundancy.
  • Using "copies=2" on specific datasets for more important data is possible, to get data redundancy on single disk pools.
  • Last, ZFS will never give you a block of data that failed it's checksum. If that means your program trying to access the file fails, so be it. Other file systems will gladly hand you a bad block, and not know better.

But, I do agree, TrueNAS Scale is not quite ready for some people. And OMV may be the best option for you, and others. (That's what is nice today, their ARE options, free ones.)
 
Last edited:

ptprince

Cadet
Joined
Mar 6, 2021
Messages
4
To re-iterate @bodly, you can use single disk ZFS pools. I have them all over for my backup disks, and alternate boot media for my computers, (MicroSDXC card in my media server, USB on my desktop & laptop).

Their are advantages of using ZFS even in a single disk pool:
  • Compression, (not as important for pre-compressed media files, but does not hurt to enable it)
  • No more long file system check at boot. (Even if it only occurs every 3 months, a 8 or 10TB disk can take hours to perform a file system check with EXT4. I know, tried it in a real production data center...)
  • Scrubs. Even if ZFS can't fix the problem for you, knowing you have a corrupt file makes a serious difference. I have gotten perhaps 8/10 corrupt media files on my media server over the last 5 years, that does not use any redundancy. Most of those were larger, video files, (which I guess increased the statistically probability they would get a bad block). Knowing about the bad files allowed me to restore them from backup.
  • Redundancy for metadata, including directory entries is included by default. This can help prevent an entire directories' worth of data vanishing because of a bad block. ZFS CAN and WILL fix these automatically on read, (or scrub), even on a pool without data redundancy.
  • Using "copies=2" on specific datasets for more important data is possible, to get data redundancy on single disk pools.
  • Last, ZFS will never give you a block of data that failed it's checksum. If that means your program trying to access the file fails, so be it. Other file systems will gladly hand you a bad block, and not know better.

But, I do agree, TrueNAS Scale is not quite ready for some people. And OMV may be the best option for you, and others. (That's what is nice today, their ARE options, free ones.)

Hi Arwen,

Thank you.

I am still thinking about migrate to Scale. But I don't have surplus disk for backup my data now.
Moreover Scale release is delay, so I have time to compare OMV and Scale.
 

sretalla

Powered by Neutrality
Moderator
Joined
Jan 1, 2016
Messages
9,702
Just to make another point... I'm not sure where it says that you can share anything other than ZFS on TrueNAS SCALE (just because it's Linux doesn't mean the Middleware will stop caring about ZFS as the only supported filesystem).
 

Arwen

MVP
Joined
May 17, 2014
Messages
3,600
@ptprince Many times you have to make a decision based on time. Meaning a year from now you might make a different decision. I waited about a year before I started building my new NAS. The parts last year were not yet what I wanted.

So, make the best decision for you, now. If that's OMV, good luck to you. I'd rather you have something that works now and meets your needs. Than to try something that is Alpha software, and might give you trouble. And even when Scale leaves Alpha & Beta, it still may not meet everyone's needs.
 
Last edited:

BeardyDude

Dabbler
Joined
Mar 12, 2021
Messages
10
Hm.... sorry for mild necro, but being able to reliably mount and interact with ext4 (or xfs, btrfs, ufs, ntfs, fat32 or any other volumes or arrays via mdadm/lvm etc) via the middleware and the UI would be extremely beneficial in a lot of use cases - importing from old NAS boxes, USB transfer disks, migrating a JBOD from another ecosystem etc etc.

I might be being naive, but it doesn't seem like a lot of work to implement in scale given the debian roots! Surely the volume can be flagged in the middleware with a simple "second class citizen" tag to block it's use in any application that is relying on ZFS specific features. SAMBA, rsync and simple "CP"s though would surely be fine.

I know ZFS is great - this is why I'm running truenas - but beyond easing transitional / temporary arrangements, sometimes ZFS isn't quite right anyway - issues when going over 80% capacity for example, and speed penalties, limiting it's usefulness say for a single SSD scratch share.

But even when ZFS isn't right, that doesn't mean TrueNas couldn't do the job - with a teensy bit of loving for other filesystems :)
 

morganL

Captain Morgan
Administrator
Moderator
iXsystems
Joined
Mar 10, 2018
Messages
2,691
I might be being naive, but it doesn't seem like a lot of work to implement in scale given the debian roots! Surely the volume can be flagged in the middleware with a simple "second class citizen" tag to block it's use in any application that is relying on ZFS specific features. SAMBA, rsync and simple "CP"s though would surely be fine.

But even when ZFS isn't right, that doesn't mean TrueNas couldn't do the job - with a teensy bit of loving for other filesystems :)
It's certainly possible in the future, but we do need to focus on getting SCALE to release quality first.

Importing data from another file system is always interesting. Maintaining data on a less reliable file system has its issues. Does TrueNAS get the blame when there is data loss? Can the community support people through these events? If TrueNAS adds the feature for home users, how do we prevent businesses from seriously hurting themselves?

In any case, we welcome suggestions and upvotes.
 

beagle

Explorer
Joined
Jun 15, 2020
Messages
90
Thinking about the home user and existing consumer NAS UX (think Synology and Qnap) maybe a data migration wizard could be an interesting idea for new users.

Most home users probably have their data accessible on an external disk or SMB share. So, the wizard would guide the user through the process of making their existing data accessible to TrueNAS and transferring the data to the ZFS pools. After the data is transferred the wizard would close the access to the "external" data and the user would access his/her data via TrueNAS as usual. Therefore, there wouldn't be a risk to TrueNAS of having to manage non-ZFS data after the transfer. The wizard wouldn't cover all the possibilities and advanced usages but could easy new or less technical users into TrueNAS.
 

BeardyDude

Dabbler
Joined
Mar 12, 2021
Messages
10
Yep @beagle , full on migration assistance would be a big win - but step one is an easy way to identify, mount and use existing volumes and arrays! The rest is definitely a nice to have, but can certainly wait :) And, I don't know about you, but my "storage life" has always been a lumpy bumpy upward path. If you're migrating from something like a 4 bay synology to a bigger box with truenas, a common scenario would be start where you're at - import and use your old array, adding new drives into a new ZFS array, and slowly migrating as and when you want/need/afford new larger drives to add to ZFS - without necessarily a single "dump and run" being part of the process. Home users and a lot of small businesses don't like abandoning previous investments, and jiggling things around to rebuild existing drives into new arrays takes a top loading of resources not everyone is ok with, so rushing to close the door isn't going to work for everyone.

And to @morganL , yeah it's a lower priority than a functional reliable truenas scale, but can definitely start small! One way to approach it is a tick box for "unsupported configuration" in general preferences, which dials down the warnings globally and allows more flexible configurations. There's nothing to stop non-supported, non-zfs pools being flagged an ugly colour too, so they stand out and act as a daily reminder :) I'd be interested to know the split between enterprise, sme and homelab/home user usage too. I'd imagine the latter end of that spectrum outweighs the former, though also appreciates the focus on enterprise level reliability and good practise (I know I do!). And, as an IT manager / consultant working with various small businesses and charities, many on the smaller side really just want things to work, quickly, and are surprisingly accepting of risk - at least where the alternative is more spent on equipment or more billable hours! And no, sadly this doesn't seem to change much after it turns around and bites them in the ass :)
 

beagle

Explorer
Joined
Jun 15, 2020
Messages
90
I'd be interested to know the split between enterprise, sme and homelab/home user usage too. I'd imagine the latter end of that spectrum outweighs the former, though also appreciates the focus on enterprise level reliability and good practise (I know I do!).
You need to also appreciate what part of that spectrum pays the development bill and what features rank higher on their priority list. ;-)
 

BeardyDude

Dabbler
Joined
Mar 12, 2021
Messages
10
Haha, true that :D But the cloud of community testers must find all the bugs that are harder to nail down internally and in situ with customers. I know I've submitted a couple over the years :) And appliance customers get a different version of the software anyway, no harm in splitting features the other way for a change!
 

Arwen

MVP
Joined
May 17, 2014
Messages
3,600
@BeardyDude - Back with FreeNAS, their was a some what largish difference between the code bases. However, with TrueNAS Core, it was decided to be the SAME code base as TrueNAS for business / enterprise. Some features are not included with Core, (I think clustering, fibre channel disks and storage chassis administration). But, in general, not ones that affect home and small business uses.

Now TrueNAS Scale does have to be a separate code base for somethings from TrueNAS Core, because it's based on Linux not FreeBSD. However, it is my understanding that TrueNAS Scale is not holding back clustering for enterprise customers only. So their should be minimal, if any, differences between non-paid and paid users of TrueNAS Scale.
 

morganL

Captain Morgan
Administrator
Moderator
iXsystems
Joined
Mar 10, 2018
Messages
2,691
Haha, true that :D But the cloud of community testers must find all the bugs that are harder to nail down internally and in situ with customers. I know I've submitted a couple over the years :) And appliance customers get a different version of the software anyway, no harm in splitting features the other way for a change!
Appliance users get the same software.... with a license key that enables specific additional features. If we add features to CORE, its very difficult to remove them from Enterprise... emotionally and technically.
 

ornias

Wizard
Joined
Mar 6, 2020
Messages
1,458
Data migration from other disks is not as easy as it sounds...
There isn't a magic pill to always port data from ext* to ZFS reliably, so it's understandable that such a feature isn't implemented.

if you really want to do a one-time migration, it's very-well possible using either a windows/mac machine and a share (for the non-cli savy folk) or a few standard debian cli commands.
 

stavros-k

Patron
Joined
Dec 26, 2020
Messages
231
Haven't tried it myself, but if you have a disk controller that you can pci passthrough to a VM (in TN scale) you can then use rsync.
 
Top