Is 10Gb actually realistic?

[shadowbert]

This video shows Linus and his somewhat ridiculous file server.

 

Although the capacity is something I don't need (at least at the moment), the read/write speeds have me very interested.

 

In contrast to, say, RAID5 (which I currently use and am contemplating migrating away from) where a file is striped across multiple disks (meaning they can work together to boost their performance), unraid stores a given file on one drive (plus parity), and so any read or write speed is going to be limited by the performance of that drive, right? So how is it possible to reach those sorts of speeds on one file (he had a single ~80gb test file) on spindle disks?

 

I tend to use cheaper disks (the "I" in RAID), so one of my major concerns with switching to something like unraid is performance...

[trurl]

I just sort of skipped through that video without any audio just to find what I suspected at 5:24.

 

All of the storage is in cache pool, which is btrfs raid, not the Unraid parity array. So he isn't doing

15 minutes ago, shadowbert said:

unraid stores a given file on one drive (plus parity)

[shadowbert]

Sneaky sneaky...

 

In that case, what kind of performance should one expect from an actual array? I assume it's just going to be the speed of the drive minus a bit for overhead?

In other words, it's going to pretty much always be slower than RAID?

[trurl]

Due to parity updates, it will always be slower than single disk speed for writing to the array. Same as single disk speed for reading from the array.

 

But, since each disk is an independent filesystem, each disk can be read independently on any linux. If you lose more disks than parity can recover, you haven't lost everything as in RAID.

 

Also, since each disk is an independent filesystem, you can mix different sized disks in the array, and easily add disks without rebuilding the array, and easily replace disks with larger disks.

 

Unraid is not RAID for good reasons. You trade speed for these other benefits.

 

Also, as seen in that video, faster storage is available in cache pool. And recent betas support multiple fast pools.

[shadowbert]

Oh of course. The comment I made was not disregarding unraid as an option - I'm just trying to understand its limitations. It's easy to find information about the benefits - but getting a list of up-to-date limitations is not as easy.

 

Though it would be nice if there was a way to set specific shares to hold multiple copies of a file on different disks, to boost read performance (and boost resiliency)...

[trurl]

Various btrfs raid configurations are available in the pool(s).

 

 

[trurl]

1 minute ago, trurl said:

Various btrfs raid configurations are available in the pool(s).

And no doubt was used in that video.

[shadowbert]

I see - and that's the trick they used in the video above? Very interesting.

 

When the cache pool gets flushed to disk - does the file also stay in the cache pool?

[itimpi]

2 minutes ago, shadowbert said:

When the cache pool gets flushed to disk - does the file also stay in the cache pool?

No - the standard ‘Unraid behavior is to only ever have one copy of any file so 0nce a file is flushed to the main array it is removed from a cache pool.

[trurl]

Parity is realtime, cache is not.

 

In fact, there is no requirement for cache to get flushed to the array. Cache is just additional (and differently managed) storage. One of the features of Unraid is the Mover, which will move files from cache to array for those shares set to cache-yes, and it can even move files from array to cache for those shares set to cache-prefer. Or Mover will ignore files for cache-no or cache-only shares. Mover runs on schedule, default is daily in the middle of the night.

 

It is typical to set things up so some things stay on faster cache, such as dockers and VMs.

 

Files for a user share on cache are part of the user share just as files on the array are. Files typically will not exist on cache and array at the same time, though you could force this by working directly with the disks, in which case, files on cache have priority when accessing the user share.

 

Here are some more details about the various cache settings for each user share: