howto bulid ramdisk for slog on turenas scale?

morganL

Captain Morgan
Administrator
Moderator
iXsystems
Joined
Mar 10, 2018
Messages
2,694
SLOG also solves a system crash issue....

If you don't want a SLOG just set sync = never.
 

SweetAndLow

Sweet'NASty
Joined
Nov 6, 2013
Messages
6,421
i have ups,so not warry lost data.
Slog only matters if you lost power and need to replay write events. You can't do that with a ram disk. Just set sync=never at that point.
 

linbing

Dabbler
Joined
Oct 9, 2020
Messages
22
Those are unimportant data, I only pursue speed of r/w,For example:chia polts
 

danb35

Hall of Famer
Joined
Aug 16, 2011
Messages
15,504
Then why would you have sync enabled at all? Sync writes will always be slower than async, no matter how fast your SLOG device is.
 

HoneyBadger

actually does care
Administrator
Moderator
iXsystems
Joined
Feb 6, 2014
Messages
5,112
Those are unimportant data, I only pursue speed of r/w,For example:chia polts

As mentioned by others, you just want to set sync=disabled for this.

But you will still end up bottlenecked by the speed of your underlying pool, as the process of plotting for CHIA will cause long periods of sustained writes. Plotting a single k32 causes about 1.8TB of total writes (bitfield off) so unless you have that much RAM, you'll eventually throttle back to pool speed.

You could potentially use a local RAMdisk in your plotting machine as the SSD substitute directly, but that would cost roughly 256GB of RAM per k32 and I assume you want to plot more than one in parallel, so you're rapidly into the "terabytes of RAM" category.

Use a local SSD for the temp plotting, move your final plots to HDD.
 

danb35

Hall of Famer
Joined
Aug 16, 2011
Messages
15,504
It may be that OP is misunderstanding the purpose of SLOG, which does seem to be a common problem. @linbing, SLOG isn't a write cache. It's used only to log synchronous writes to something (fast and) permanent, so that the OS can report back to the application that the data has been written--it has no effect at all on async writes. The data still needs to be written to disk, which will happen in a matter of seconds. So instead of the write being cached in RAM, and then flushed to disk within five seconds (as happens with async writes), your data would be written to the RAMdisk (which, though fast, still wouldn't be as fast as the caching operation), flushed to disk within five seconds, and then removed from the RAMdisk. Therefore, sync writes will always be slower than async writes (two write operations and an erase rather than just one write)--that's why they're only used when data integrity is important, which you say it isn't in your application.
 
Top