Help with ZFS datasets for NFS

[cwesterfield]

If I understand datasets, each one acts like its own filesystem.

In my usual workflow, large files will be pulled down into an NFS share, and when complete, moved to another folder. I imagine this is pretty common.

I think this means that putting my download folder and final location folder in the same dataset would be a good idea.



If this is a bad idea, please explain. This is my first dive into Freenas or ZFS, so all info is welcome.

One question I have is for the NFS mounts. For the computer controlling the downloads to be able to just reassign file index locatios instead of actually moving the data to different sectors, should I have a single NFS export to the entire dataset (Media_DL)?

On my QNAP I have a mount for each folder, but I think that requires it to actually move the files which would be much slower.

Thoughts?

 

[pro lamer]

large files will be pulled down

What way? Is the space being preallocated? (Bad idea with cow - copy on write FS) Are the files' blocks transferred like a continuous stream (I can't remember the proper word) or in a random order (like Torrent) ?

Leaving other questions with no answer, maybe someone else or later, my apologies.

Sent from my phone

 

[cwesterfield]

Currently I'm using a SSD I had laying around in it's own dataset for a temp directory, then the whole file goes to my pre-freenas storage on a QNAP.

Once the file is fully downloaded then the files get organized and placed in their final resting place on the Freenas MEDIA_DL Dataset.

The middle step will likely be removed, but I'm not sure the best way without causing a ton of fragmentation.

 

[sretalla]

Torrent clients usually have an option to pre-allocate the file (some even dropped the option and exclusively do that) in order to avoid massive file fragmentation.

If you're sharing the temp and completed locations from the same dataset (and the same NFS share), then you will avoid an additional write of the file as the torrent client can just do a mv operation, which will only touch the metadata, not the bits on the disk.

If your media folder is in another dataset, this will be a copy only once finished, so no fragmentation in addition from that.

 

[HoneyBadger]

Torrent clients usually have an option to pre-allocate the file (some even dropped the option and exclusively do that) in order to avoid massive file fragmentation.

That works on a traditional filesystem, but not here. The pre-allocated zeroes will be squashed down to nothing by ZFS compression and then you'll still be facing the fragmentation later.

The suggestion from the official OpenZFS page is to use a separate dataset with recordsize=16K for the temporary download folder, and then copy it to the final resting place with the larger recordsize (if it's exclusively large media, you could even do larger than default such a recordsize=1M)

http://open-zfs.org/wiki/Performance_tuning#Bit_Torrent

 

[sretalla]

Or just turn off compression on that dataset.

EDIT: OK, so that was not a good idea...

 

[HoneyBadger]

Or just turn off compression on that dataset.

That makes it even worse because then you're going to write the literal zeroes during the pre-alloc, then copy-on-write will fragment and invalidate it later.

 

[pro lamer]

a separate dataset with recordsize=16K for the temporary download folder

I've got an idea to even use a separate pool. The thought behind the idea: fragmentation refers to the whole pool and temporary fragmented files may cause fragmenting to the whole pool anyway. The only problem with this idea is that it is just a guess :)

Sent from my phone

 

[anmnz]

If I understand datasets, each one acts like its own filesystem.

Strictly speaking each one literally is its own filesystem!

One question I have is for the NFS mounts. For the computer controlling the downloads to be able to just reassign file index locatios instead of actually moving the data to different sectors, should I have a single NFS export to the entire dataset (Media_DL)?

Yes. A dataset is a filesystem, an NFS export is an export of a filesystem, it's all the same thing.

Currently I'm using a SSD I had laying around in it's own dataset for a temp directory, then the whole file goes to my pre-freenas storage on a QNAP.

I've got an idea to even use a separate pool.

I think this is a very good approach. It's simple and reliable because it makes sure that the writes to the pool where you will store the data long-term are big long ZFS-friendly sequential writes, no matter how the data was downloaded, so you just don't have to worry. If the "scratch" pool (single disk) to which you are directly downloading the data has a problem like fragmentation, you can happily just wipe it, no problem. It's a simple and clean approach that means you just don't have to be concerned with all the other things discussed in this thread!