Can non-ZFS support be added manually?

[indivision]

I have a server with 12 drives. 6 of them are in a bigger pool where I want the qualities that ZFS provides. But, the rest are just utility drives that I use with non-critical data that gets moved around and changed frequently.

Those utility drives I'm typically setting up as single-drive ZFS pools. And I'm finding that they don't perform very well compared to how they had before as NTFS or EXT drives.

I found a few old threads touching on the subject:

ZFS pool and non-ZFS single disks in same box

I'm setting a new FreeNAS box after many years of using a WD Sharespace but the controller has died twice, the first time under warranty (which saw a brand new box and hard drives being supplied as a replacement) and the second box just recently some 5 years after it being provided by WD. I did...

www.truenas.com

Single Drive ZFS

Hi, I know pretty well that FreeNAS/ ZFS is supposed to be used with multiple drives. But, I'm just curious and I've searched the web already for this one. What, if any, are the benefits that ZFS can provide to the user if the user is using only one drive? Can the user take advantage of...

www.truenas.com

But, what I'm wondering is if it possible, perhaps via some console work in the shell to mount and share access to those utility drives as NTFS or EXT? I would presume that they would no longer show up in the TrueNAS GUI and monitoring. But, that may be ok for my case.

Can anyone say if this is possible or even better point to a guide on how to do it?

Thank you.

 

[Arwen]

There several other options and still use ZFS:

• Use several of the disks in a stripe, (but no redundancy). This improves performance somewhat because you have more than 1 vDev, (aka single disk).
• Turn down, or off some ZFS dataset features;
  • atime=off
  • redundant_metadata=most
  • sync=disabled

Plus, the compression option maters. If you have pre-compressed data, then you may want to disable compression.
You can also look at the block size. ZFS defaults to 128KByte blocks, which if all your misc. files are smaller or larger may suggest some tuning here as well.

All that said, you reduce reliability. A single disk failure would take out the pool. But, if it is a scratch set of data, then it might work out for you.

 

[indivision]

Thank you. I tried turning some of those features off (no atime or compression). But, I haven't tried changing block size.

This is actually on shared single disks. So, no pooling needed at all. The problems seem to come up when making many modifications to very large files. It doesn't seem to like that.

I've been able to get barely passable results using iSCSI. But, it still freezes up at times.

It's a tough situation because I'm pretty sure something simple would handle the large file / many writes a little better. But, on the other hand, my research so far shows a lot of people on other systems drooling over the regular transfer speeds via ZFS. So, I'm not really wanting to lose that...

 

[indivision]

I thought it would be worth following up on this subject in case someone else has the same question(s).

I ended up doing a long-planned hardware upgrade before I settled on a solution to this issue. And it turned out that the better hardware completely solved it anyway!

ZFS already performed well with my old hardware (Supermicro A1SAI-2750F with maxed out ram). But, it had trouble keeping up with maintaining edits to very large files. Now, I have a step up Supermicro board and Xeon processor. Same quantity of ram but faster. Now, the same ZFS shares and files are managed without any issue at all.

So, moral of the story: when things get fussy, more compute power may be the better solution over going with off-grid software changes.