<p dir="ltr">Il 30 set 2016 11:35, "mabi" <<a href="mailto:mabi@protonmail.ch">mabi@protonmail.ch</a>> ha scritto:<br>
><br>
> That's not correct. There is no risk of corruption using "sync=disabled". In the worst case you just end up with old data but no corruption. See the following comment from a master of ZFS (Aaron Toponce):<br>
><br>
> <a href="https://pthree.org/2013/01/25/glusterfs-linked-list-topology/#comment-227906">https://pthree.org/2013/01/25/glusterfs-linked-list-topology/#comment-227906</a><br>
><br>
> Btw: I have enterprise SSD for my ZFS SLOG but in the case of GlusterFS I see not much improvement. The real performance improvement comes by disabling ZFS synchronous writes. I do that for all my ZFS pools/partitions which have GlutserFS on top.</p>
<p dir="ltr">This seems logical.<br>
did you mesure the performance gain with sync disabled?</p>
<p dir="ltr">Which configuration do you use in gluster? Zfs with raidz2 and slog to ssd? Any l2arc?</p>
<p dir="ltr">I was thinking about creating one or more raidz2 to use as bricks, with 2 ssd. One small partition on these ssd would be used as a mirrored SLOG and the other 2 would be used as standalone arc cache. will this worth the use of SSD or would be totally useless with gluster? </p>
<p dir="ltr">I don't know if use gluster hot tiering or let zfs manage everything<br></p>
<p dir="ltr">As suggestion for gluster developers: if ZFS is considered stable it could be used as default (replacing xfs) and many features that zfs already has could be removed from gluster (like bitrot) keeping gluster smaller and faster </p>