Here's How to Save $45,000

[Sauron]

8 hours ago, Arika S said:

i certainly agree with this, but i can only hope lumaforge isn't charging 400% per unit purely for support

That wouldn't be unheard of...  

[tutacat]

didnt they already make this jellyfish fryer video last year

[Velcade]

3 minutes ago, tutacat said:

didnt they already make this jellyfish fryer video last year

They made a balls-to-the-wall NAS that cost as much as a Jellyfish last year.  This year was a 'how much can we save by making a 1:1 copy of a jellyfish' ourselves

[looney]

21 hours ago, Windows7ge said:

Wanted to comment with something similar but I was 6 hours too late.

 

I don't have evidence of this but I have been told in synchronous write operations tasks like database (MySQL perhaps?) or VM's can still see a write performance gain. Presumably writing to cache instead of directly to disk.

 

For what 99% of people at home or even work would use this for (SMB/NFS/SSH/iSCSI) yeah, ZIL does basically nothing for you performance wise.

Synchronous writes is indeed something you would get with databases, the database wants to know that the file has been saved to non volatile storage before it sends its next bit of data. 

 

You can force zfs to treat all writes as synchronous, but synchronous is always slower as the sender has to know that the file is stored on non volatile medium. 

 

With zfs + slog, all synchronous data goes to both the vdevs (through ram and cache) and the slog at the same time in parallel. 

As the slog should be non volatile zfs can tell for example the database that it's data is stored securely and that it can send the next bit of data. 

 

At the same time the data might also still exist in a volatile state in ram or hdd cache. 

 

When zfs knows this data is no longer in ram or cache but actually on the disk itself it will remove the mirrored data from the slog. 

 

So the slog, in normal operation, is only written to and purged. 

 

It is only in case of a failure that it gets read from.

So say zfs saved the file to slog but the copy that is meant to go to the drive is still in ram or cache and the power cuts then after boot zfs can still ask the slog for those files. 

 

This is why you don't use consumer SSD's for slog

 

For synchronous loads there can be an improvement where in case of small bursts the slog can function kind of like a buffer, but the moment you are writing more then one drive can handle (in a 1vdev system) for more than say 5 seconds you will stil hit that drive as a bottleneck, even if the slog is just chilling, zfs does not want to use it as a cache, if the vdev cache is full then it will stop new data coming in until it can write to both slog and vdev again.

 

So a small burst can fill the cache and slog at the same time and the get written "slowly" to the drives. This would be slower without slog as it has to commit to drive straight away but this only applies to, I think, one drive worth of cache or something. 

[Windows7ge]

2 minutes ago, looney said:

You can force zfs to treat all writes as synchronous, but synchronous is always slower as the sender has to know that the file is stored on non volatile medium. 

This is something I tested myself a few years back.

sync=always

The performance wasn't any better for SMB. Afterwards I learned about sync vs async operations and everything started making sense.

 

6 minutes ago, looney said:

This is why you don't use consumer SSD's for slog

I should probably replace the Intel 750 series SSD I'm using as a dual partitioned SLOG/L2ARC for something a little more appropriate then huh? :3

 

I'd like to move to dual M.2 and mirror it but most M.2 SSD's seem to be consumer grade. That or I just haven't looked hard enough.

 

13 minutes ago, looney said:

For synchronous loads there can be an improvement where in case of small bursts the slog can function kind of like a buffer, but the moment you are writing more then one drive can handle (in a 1vdev system) for more than say 5 seconds you will stil hit that drive as a bottleneck, even if the slog is just chilling, zfs does not want to use it as a cache, if the vdev cache is full then it will stop new data coming in until it can write to both slog and vdev again.

 

So a small burst can fill the cache and slog at the same time and the get written "slowly" to the drives. This would be slower without slog as it has to commit to drive straight away but this only applies to, I think, one drive worth of cache or something. 

Kind of like SLC cache on a SSD. One you fill it you're bumped down to the TLC performance. If the rate at which is flushes it tunable though in theory you could create a larger SLOG partition to suit your workload.

 

Though like my example. If you exceed the high-speed flash on the SSD then that probably won't do you any good. May as well write directly to disk.

[LivingEdge_Studios]

Well, I got my parts list together and am having a tough go on finding all the parts.

 

It seems like everything... computer parts just get outdated really fast...

 

 

Like "All dressed up and nowhere to go!"...  $5k in me pocket and nowhere to spend it!

 

It would sure be nice to see an up-to-date video on a "new" Jellyfish Fryer! 

[williamcll]

Linus did make a point, or else Lumaforge wouldn't have made minimal profits to be bought out by another company.