Hey guys,
shortly want to ask if my node can get problems, when i execute find . -type f -exec touch -ca {} + On the whole node.
I added a special vdev for metadata to my zfs pool and this command would fill the vdev faster.
I guess it shouldn’t be a problem, but would be nice if someone from the team shortly confirms this 
Access time is not used by node software, so no impact expected.
Could you share (in case you’ll do this touch) if it really moved metadata into special vdev?
Sorry I cannot answer your question, just very strong feeling that this should not harm at all, especially when done on stopped node
Yes, du -sh took 40 sec and special vdev has high usage 
time du -sh .
1.7T .
du -sh . 1.11s user 38.43s system 61% cpu 1:03.90 total
but while executing the find command, i enabled atime, but i can’t say if it’s necessary.
8 HDDs raidz1 and special vdev contains nvme ssds.
Remember that only the metadata you change will move to specialdev.
There is no real shortcut to populating a late added special dev, only zfs send | zfs recv, rsync or similar of all data will do that for you.
This command you suggest only updates access time + change time, not dnode etc.
Also, your dataset should have option atime and xattr off, it is not needed and only adds overhead for in your metadata and io.
However, if you are impressed by the du -sh time after this command, it probably because the relevant metadata was already loaded in your ARC memory, not because of that command populating your special dev with relevant data
PS: I know this topic was already closed with a solution, but I wanted to add some context to your general question for others finding this thread. There is already great threads in this forum that describes very well functioning ZFS configurations for nodes - please go read those 
doesn’t sounds quiet friendly, when you don’t know my evaluations.
Its not correct that only changing the data populates the vdev, changing metadata also does this.
My research suggest, that access time/Change time is part of the dnode, therefore this should be sufficient.
Executing the command resulted in very high write speed on the vdev.
After executing the command, the vdev gained 40GB.
I can see very strong read speeds on vdev while executing du -sh.
Populating the ARC is not as fast as you might think, when handling 4.325.817 files. These files have to be red multiple times, when you want to have all of them in ARC, but only one run takes hours. Therefore prefetching (if even possible on my setup) takes days.
As i said before, i enabled atime just temporarily to ensure that the touch command has any effect, but i don’t know if it’s needed.
I hope my context to your context helped
I’m sorry you took any offence or disrespect for your research or time spend understanding zfs and it’s mysterious ways of working - none intended
I think we are in sync on the way it populates data to special device, and I also think we agree.
I stated that:
…only zfs send | zfs recv, rsync or similar of all data will do that for you…
You say:
My research suggest, that access time/Change time is part of the dnode, therefore this should be sufficient.
A dnode can contain many different metadata structures, it could be time of access or modify, it could be a directory reference or lots of other things.
However, the core if it is, only metadata (or we could call it dnode data) that is modified gets moved to special dev. So if you update a timestamp with ie. a touch command, it will move that data to special dev, but not the files corresponding metadata for file size + type, block pointers acl etc.
So, in general updating metadata will move it to special dev, but only that metadata you update. And in case you would like all your metadata for all your files populated to special device, you do need to re-write all data through either zfs send, rsync or something else that actually reads/writes it all.
–
Now in regards to the “please go read those” comment, it was certainly not meant in a way to undermine your invested time or existing knowledge of the innnerworkings of ZFS. Just a quick way referencing to something already in here. There’s hours and hours or reading with great details of good knowledge, but I can’t quickly compile it into this post - so I just wanted to raise the attention for those.
I knew zfs before, i took 2 minutes for dnode, thank you…
I still don’t agree on that. Informations for file size is currently on the vdev (as you saw from du -sh command) and it doesn’t come from ARC.
Mmh.. you’re probably right if dnode grows by that command 
Then I guess it would reallocate it, instead of rewriting it back to original vdev.