Replies: 1 comment 2 replies
-
|
First I would start calculations from estimating the amount of metadata that will go onto the special vdev in any case. You may run Second, I would look on your expected pool topology, and particular RAIDZ2 vdev width minus parity. I'd consider more or less space-efficient storage starting from ~16KB of data per data disk in vdev, which for 8 disks give ~128KB blocks. That is where I would target The last point is somewhat related to the required special vdevs throughput. If there will be only metadata and very small data, SATA may be fine, but the higher you'll get on |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the quick feedback.
I understand the expected growth, but can you explain why I need at least double of that capacity (from ASIZE)? The PSIZE and ASIZE on So just to hold metadata of that pool/config I do not need really big SSDs: You recommend at least Thanks for the notice regarding throughput (NVMe > SATA), we will rethink switching to NVMe if we use If throughput of special vdev will be not a concern (thanks to NVMe), do you recommend going higher than Details of zdb -Lbbbs {pool_name}``` root@debian:/# cat /root/zdb_data.txt Traversing all blocks ... Blocks LSIZE PSIZE ASIZE avg comp %Total Type Block Size Histogram block psize lsize asize |
Beta Was this translation helpful? Give feedback.
-
|
Double size I meant to not use more than 50-75% of special vdev at any time to reduce its fragmentation and possible use of gang blocks. But I am not saying it is double of ASIZE. As I have told above, ASIZE you see right now is based on RAIDZ overheads, and it will be smaller on mirrored special. So with PSIZE of 3.27G and ASIZE of 15.8G I would guess something about 7-8G for mirrors actually (due to most of metadata having 2 copies), and about double of that for vdev capacity. 16KB per disk (128KB) is where you get decent space efficiency and processing overhead from RAIDZ. Space efficiency in your case should not be critical, since you don't have so many metadata and small blocks. Optimum performance point for HDDs may be higher due to large seek times, that is why (in addition to better compression, etc) you have recordsize increased to 4MB, as I understand, which is reasonable (may be a bit on higher side) for sequential I/O and gives each disk ~512KB of sequential data even in case of pool fragmentation, which should be more than enough. You may set |
Beta Was this translation helpful? Give feedback.
-
Hi guys,
we currently running raidz2 with 8x 18TB Seagate Exos X18 (ST18000NM000J) - most using for large video files and accessing it with samba with different clients. We will shorty migrate the data to a new server and planning raidz2 but with special vdev (ZFS metadata special device). We want to use 2x SATA Samsung SM883 SSDs in mirror and the open questions currently are (A) what size to choose for the SSDs (B) what is the best value for
special_small_blocksin our setup (C) optionally/generally: would you advice against 2x SATA SSDs (SM883) and better using 2x NVMe? Will this be a noticeably difference?Regarding (A) and (B) I followed level1techs article and this are the results:
Reading this histogram - I am right that (A) 2x 1,92TB SDDs are more than enough (no 3,84TB needed) if I choose (B)
special_small_blocks=512K ? As far as I understand if setting the parameter to 512K the space taking up will be around aprox. 167GB for special vdev right? And going higher (to 1M) will be a big jump to 2.6 TB, which is too much for the selected SSDs.Just asking here to get sure before buying/migrating. Much thanks in advance.
Beta Was this translation helpful? Give feedback.
All reactions