Write performance (with slog), data scrubing (wiping) and nested access

I am going to do a deep dive into truenas and while I have watched many videos and read a lot of articles and blog posts, there are few questions which somehow I could not find proper answer (and for some I am in doubt if I understood correctly).

Just for the purpose of understading workload think of data analytics workshop (business intelligence on large datasets, many reads, ocassional write/dump to the server), machine in question is 45drives HL15 with upgraded processor (24cores) and a lot of RAM (512gb, I likely overdid that :blush: ), some light VMs will be there as well. Truenas will be connected as iscsi block device through 2x10gbit ethernet connections using MPIO in order to bond them together, some data shares will be SMB:

a) my current thinking is that I will configure my pool on spining disks (likely 8x in radiz2 config) + slog nvme mirrored devices - my question is this; if I make a dump/write of a large dataset (in gigabytes, sometimes tenths or more) I will drown my server in data. My conclusion while reading docs it tells me that it will try to receive everything in memory and then 5sec after it will start to write that down to SLOG device. I can not find proper answer on what happens after fifth second, if the influx of data is so large, is it going to continue writing to slog and at the same time unwind (slowly) slog/memory to radiz2 or is it going to slow down to the write at the speed of spining array?

b) is there a way to actually delete data from the pool after it was deleted from file system? This is basically a legal question, some of the data is classified or otherwise confidential and I have strict rules on keeping and/or destroying data. So I want to be sure that when I delete something from the file system it will actually be deleted/zeroed/scrubbed after some point in time - how do I achieve that in ZFS? (let us say that there are no snapshots and that data we are discussing here is saved in smb/nfs share and not as block device)

c) as for access, if I understood correctly, it is not possible to have (for example) SMB share and within it a folder which is FTP share (point being, there are some MFP devices on the network which need to have ability to save to the server but I want to use FTP instead of SMB because MFP do not support “newer” version of SMB)

I know questions are all over the place, sorry about that.

Data is only written to the slog in sync standard mode when a sync write is requested, or in sync always mode.

The answer is more complicated these days than it used to be. It used to spend io when the next txg needed to be written.

Now there is back pressure.

In essence the incoming rate should slow down to approximately the max streaming write rate of your pool.

b) is there a way to actually delete data from the pool after it was deleted from file system? This is basically a legal question, some of the data is classified or otherwise confidential and I have strict rules on keeping and/or destroying data. So I want to be sure that when I delete something from the file system it will actually be deleted/zeroed/scrubbed after some point in time - how do I achieve that in ZFS? (let us say that there are no snapshots and that data we are discussing here is saved in smb/nfs share and not as block device)

It’s cow. So it’s harder.

Deleting a dataset is the quickest way to “delete” a set of data and all its snapshots, but that won’t zero it.

And as far as I know, there’s no way to zero free space.

Perhaps it would be enough to use an encrypted dataset. That would then leave encrypted data in the “free space”.

That is my conclusion as well, but again, if we have slog device (which is much faster) why shouldn’t we write it down to the slog and let it unwind slowly to my data vdev

Well, I can not simply delete dataset because there is other data there as well. But it is an interesting (legal) problem which occurrs regulary and other people should have it as well.

p.s. of course that my data will be encrypted, but still, I really need to know that once I delete a file after some time (monthly regular zeroing or something) file is unrecoverable by anyone including me who owns encryption keys

In essence the slog converts a sync write to an async write.

The async writes still have to flush every 5 seconds.

Slog devices are generally only ever written too (unless you reboot)