ZFS with SATA and SSD

[Alessandro 123]

Maybe few SSDs for slog. The controller cache is not SATA/SAS bound, it is PCIex, so many many times faster.
To be honest, I don't think you will feel a difference in real life.

For sync writes ok, but with the controller cache is possible to enable the writeback. If ZFS uses the RAM as 'cache' when enabling writeback, this would be risky

 

[sigxcpu]

True. That is why we use slog devices.

 

[Alessandro 123]

Ok, but fabian wrote that async writes are buffered in memory and this is no good.
With hardware controller, all writes are async (due to the writeback), but stored on a battery backed cache, not directly on ram.

This is why i've asked if would be possible to force ZFS to use the SLOG

 

[sigxcpu]

Nope. They are not. Async writes are buffered in memory and that is an OS thing, not controller. Maybe the controller driver signals to the kernel that can send all writes in sync or you mount your filesystems in sync, then you will get all your writes directly in controller cache.

 

[waltercarroll]

• Any filesystem that you place on an SSD is going to be faster due to the physical nature of SSDs versus rotating rust.
• Databases often allow you to place their database log onto a separate file system. SSDs are a great choice for database log files. Actually, a database log and the ZFS ZIL are very similar mechanisms.
• The Oracle database in particular has a Smart Flash Cache Feature that works similarly to the L2ARC described above: It's basically an extension of the SGA so that frequently needed data remains accessible from fast flash memory even if the SGA (which is in memory) is not big enough.
• I'm sure you can come up with other great uses, but that almost always involves some sort of intelligent distinction between data that is accelerated with flash and data that is stored on regular disks. The beauty of ZFS is that it does this job automatically for you.