I admit hooking TrueNAS and Windows together with iSCSI for just a filer is odd, but in a way I also think that is what makes it interesting.Īs I mention, I much prefer Windows as it is what I support at work, but TrueNAS is the better filer today. ![]() I may build the other system with the 7x 10Gig WD drives using thatĪs to your question on "how/where Server 2019, iSCSI, TrueNAS etc came into the picture" I am not sure what you mean? I need to run some OS on this to serve out files somehow, right? I am not opposed to just sticking to TrueNAS directly on the hardware and calling it a day, especially if this path I am on just turns into a hot mess. The ZFS/kernelbased SMB server is available on Oracle Solaris (a commercial enterprise Unix where ZFS comes from and is native, free for demo and development) and the free Solaris forks like OmniOS that offers newest Open-ZFS features, OmniOS Community Edition To try you can use my free ESXi ZFS server template with OmniOS that I offer now for more than 10 years, It is also more CPU and RAM efficient (less overhead compared to a VM like FreeNAS). Just set smbsharing=on and this is it, no hassle with a SAMBA configuration file. It is also much simpler to configure than SAMBA. ![]() From view of a Windows desktop, it behaves much like a real Windows server even with a perfect and always working integration of ZFS snap=Windows previous versions. Often faster than SAMBA, offers SMB 3.1.1 and ntfs alike ACL permissions with local Windows SMB groups. This gives you the best of all integration of ZFS into the OS and additionally its ZFS/kernelbased multithreaded SMB server. If you care about SAMBA and SMB, you may consider a Solarish based OS instead Free-BSD. With current ZFS you can also use a special vdev (a NVMe mirror) to hold the dedup table so no RAM is needed for realtime dedup. Calculate up to 5 GB RAM per TB dedup-data (not pool size). If you really need dedup, you can think of ZFS realtime dedup. Simply activate LZ4 compress under ZFS and you are mostly done. Unless your dedup rate is > 10 I would not care about. On SAMBA you need to care about setup as SAMBA knows nothing about ZFS. ![]() Sync is not needed so best performance and you have a filebased access to ZFS snaps ex via Windows "previous versions". I would simply use the ZFS filer to share the files to your clients. You add a lot complexity only to make it slow and to loose some ZFS features! Anyway performance ist much lower compared to a simple ZFS filer where you do not need sync for a simple SMB file sharing. You MUST enable sync and if you want a decent performance you need a good Slog. ZFS can guarantee file system consistency for itself due Copy on Write but not for a filesystem ontop like ntfs over iSCSI. if you accidently delete a file or want to go back to a snap, you can only rollback the whole LUN or you must hope for Windows shadow copies (a bad replacement for ZFS snaps) performance is lower than sharing directly from ZFS I do the same with a Windows server and an application that insists on an ntfs filesystem while I want ZFS security over ntfs or snaps over Windows shadow copies. Use ESXi as base, then add a ZFS filer VM for mass storage, create a iSCSI Lun there and give it to a second VM, a Windows server as a local raw disk, format it as ntfs to share files via Windows server. You mainly want a simple SMB fileserver for your files.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |