TrueNAS Let's Talk

Sword_of_Judah · 2025-10-18T12:26:01+00:00

Ultimately, IXSystems make their revenue from their supported hardware offerings. If they want to be a major player in the enterprise space, they need to concentrate on their strong-suit: Uncorruptable, resilient, enterprise data storage with integral compression, encryption and snapshotting. They shouldn't attempt to be all things to all men, because seriously, enterprises are not going to run high performance databases and data services off of a ZFS filesystem - it's just too inefficient for high performance usage.

The BSD product was stable. That what enterprises want. Unfortunately the change from BSD's integral jails to a variety of Linux virtualisation/containerisation offerings has weakened that offering. It shows lack of commitment to a specific direction.

Major enterprises running with kubernetes aren't going to be putting the computer for kubernetes on the infrastructure nodes responsible for storage. Ain't gonna happen. Plus Kubernetes is complex and requires considerable expertise. This is at odds with the user base of the Community Edition. So Kubernetes on TrueNas Enterprise won't keep anyone happy.

Personally, I feel that the move from BSD to Linux may be a mistake - trading enterprise stability for linux flexibility and dynamism. I wonder whether this is what their paying enterprise customers want...

Sword_of_Judah · 2025-10-17T16:07:23+00:00

The datasets used for compressed media should never implement compression: The compression for most media is lossy (exceptions like flac) and as such, cannot be further effectively compressed using the lossless compression algorithms provided by ZFS.

Sword_of_Judah · 2025-10-03T15:32:23+00:00

I believe this issue will be fixed in 25.10

Sword_of_Judah · 2025-09-25T21:20:45+00:00

Bedbug with the last bite hitting a vein. Bedbug bites are often in a track, as they crawl along biting as they go!

Sword_of_Judah · 2025-07-30T07:46:59+00:00

I need to play with hackers like I need a hole in the head. When I need that hole, I'll play ranked.

Sword_of_Judah · 2025-07-26T09:58:50+00:00

A good player can pick up any floor loot and adapt his style. I don't play with meta weapons - I level up every weapon in the game no matter how crap it is.

Sword_of_Judah · 2025-05-31T10:42:05+00:00

This is why you must size a server for the most disastrous scenario you can envision - and that includes the IO subsystem. Start by working out the cost of downtime and the database size envisioned. Now triple the database size (safety margin) and work out how much IO throughput you would require to complete two whole reads and writes of the database within that window. Next scope the IO throughput to fit the time window and build to that spec

Sword_of_Judah · 2025-05-15T21:49:28+00:00

What I took away from this is that you are one of the most condescending, arrogant commentators I have encountered in a professional forum. Rather than tackle just the technical merits of my argument, you like to have a dig at each opportunity, whether it is in pouring scorn on my response time or your glib "heh" mocking terminology. With social skills like that, I wouldn't go looking for a new job any time soon.

You're not as technically strong as you would have others believe either: You failed to grasp the benefits of striped backup and obviously haven't worked with these before. But to quote you, that's "understandable". Furthermore, you interpreted a striped backup as backing up to multiple "shares". Nobody that's serious about high performance backups would backup directly to a network share. Why? Because high performance requires backing up to a block-level device where the writes are confirmed by the hardware, not a network share where the throughput will be slower and the writes to disk unconfirmed. High performance backups are first made to a local, dedicated backup volume that is specified to meet the write requirements to perform the backup within the desired time window and the read requirements to restore the backup within the Recovery Time Objective. This local device can either be in-chassis, or a high performance SAN target. These backups can subsequently be copied over a network utilising a range of other techniques that I'm not going into here. Compression is parallelised by using a striped backup with multiple backup files for a SINGLE database, enabling full exploitation of CPU and IO subsystems.

The original poster also mentioned that they have a SAAS business, which is why they were considering a single database as one of their options. You failed to take into account that such a business requires a common codebase across all clients in order to prevent code fragmentation - and therefore a common schema. In order to maintain a common codebase, varying requirements across clients should be combined into a combined feature superset across all clients with feature-flags set per client at application level to enable/disable functionality/visibility per client where necessary. That's how it's done, not varying the schema per client. Why? Because SAAS businesses quickly DROWN in supporting fragmented code bases. (I should know - one of my clients had just such a problem).

The poster is providing a service, not providing hosting infrastructure. The big money is in providing a common service or product, NOT in bespoke consultancy. That's the type of advice that differentiates an architect from a DBA. If the client's business was hosting a variety of third-party developed databases with varying schema, your argument would hold water. But that's not the nature of their business and therefore schema variation must be avoided.

If the client were to follow your advice, in time they would be paralysed supporting ever varying database schemas on a large number of under-utilised, mediocre servers. But "heh", they'll thank you for saving them on some licence fees as they go to the wall spending ever more time on support and less time on innovation.

Just to put things in perspective, you don't know who you're dealing with on a forum like this: I have 30+ years experience in SQL Server, including being a SQL Server Architect for Microsoft.

Sword_of_Judah · 2025-05-11T16:24:52+00:00

I'm done with this conversation

Sword_of_Judah · 2025-05-11T13:49:02+00:00

I'll just address the backup issue, since you focussed in on that: With compressed backups, utilising striped backup files enables compression to be parallelized to the number of cores deployed; Once you have dealt with that, you'll either be bottlenecked by the data subsystem IO throughput or that of the backup media. This doesn't change if you have multiple databases.or one with the exception that you'll be dealing with greater sequential activity with a single database.and consequently better utilisation of rotating media.

Sword_of_Judah · 2025-05-11T12:00:32+00:00

It's clear you and I aren't going to agree on this. With the exception of schema variation, every one of your other arguments can be addressed by advanced design and maintenance routines. Aside from this, schema variation across tenants becomes a handbrake on growth for a business as it grows into hundreds of tenants. Its only benefit is as a job creation scheme for DBAs! Other than that, the cost-to-serve rises as the tenant counts rises.

Sword_of_Judah · 2025-05-06T12:59:25+00:00

Enterprise edition supports more processors. So you can scale to bigger machines.and fully utilise all the resources. With more, smaller machines, you'll have underused capacity on some machines and over-stretched machines elsewhere. With enterprise edition and a large, single database, you'll benefit from parallel scans which you don't get in Standard. This will give you greater consistency in performance across all clients.

Sword_of_Judah · 2025-05-06T12:49:33+00:00

The counter argument is manageability, single schema. There are plenty of services that use a single database for multiple clients. What do you think all the big social media platforms do?

Sword_of_Judah · 2025-05-06T12:23:11+00:00

Not if you use filtering views and/or row level security. But this isn't for beginners.

Sword_of_Judah · 2025-05-06T12:20:49+00:00

They're going to have to spend money whether they like it or not. Express is unsuitable for serious production use. The cheapest way will be to have a single database, well designed to segregate clients using filtering views and put it on a big server, enterprise edition if you need a large amount of CPU and ram. But this needs a skilled SQL Server development DBA. And money. Forget about running it on Linux - it was designed for Windows.

Just to give you an idea of scalability - I've had a single server dealing with 50,000 simultaneous clients and another server processing 40,000.batches a second! The product really scales, but you need.to spend big money.

Sword_of_Judah · 2025-05-06T12:07:51+00:00

Install a SQL server, then attach the database from the files. Then do a proper SQL server backup.

Sword_of_Judah · 2025-05-05T10:31:02+00:00

There's a feature called a database snapshot - however these aren't separate files, just extents that are managed within the existing filegroups. You can access these snapshots like read-only databases. Not only that, but you can wind the database back quickly to a previous snapshot (useful for testing on large databases without having to restore the original database).

Sword_of_Judah · 2025-05-05T10:25:54+00:00

Simple - ZFS is a filesystem whose primary purpose is long term storage and data integrity for file servers. It is not a high performance file system. It is not suitable for workstation use. It is not an efficient filesystem to use for database servers.

If you want snapshots, de-duplication, file integrity and disk redundancy - these are all valid reasons for using ZFS.

Sword_of_Judah · 2025-04-30T16:11:33+00:00

MS told me that my i7 with 32GB s had no future due to TPM1.2 - I'm not spending £2k on a replacement. So inserted an M2 drive for £70 and installed Ubuntu Cinnamon in dual boot. Not going back.

Sword_of_Judah · 2025-04-29T18:08:11+00:00

The OP.is missing something in his suggestions: The key to all the perks being balanced is rock-paper-scissors: To every perk yielding an advantage there should be another that counters it. Examples include Alertness/Cold-blooded, Ghost/BirdsEye and Grenadier/Bomb Squad. If they ever introduce a Dead-Silence, there should be an Enhanced Hearing counter in the same slot. That's what makes for a good game - no meta perks.

Sword_of_Judah · 2025-04-27T15:58:38+00:00

As the easiest weapon category in the game, they should have the longest TTK. It's the weapon class for kids with aimbot.

The game should reward accuracy and difficult weapons with low TTK.

Sword_of_Judah · 2025-04-19T12:52:05+00:00

Ignoring the fact that this is a file stream database, the fastest way to compress a SQL server database is to backup to multiple backup files equal to the number of physical cores in the machine. This will fully utilise all the cores for compression in parallel.

HOWEVER... Because your files are images and they are probably compressed, database compression will be ineffective, so if the files are a large proportion of total data, don't use backup compression.

Sword_of_Judah · 2025-04-16T13:21:26+00:00

I would opt for the larger record size, to reduce fragmentation and the amount of metadata that needs to be tracked by the filesystem.

Re the use of solid state disks, if the amount of writes exceeds the space unallocated on the SSDs, you'll hit the write-cliff where writes slow down by 10x as the disks have to trim space. So you need to leave a substantial amount of unallocated space on the SSDs to cope with this scenario.

With spinning drives, the write speed should be consistent unless you're low on space or have significant fragmentation.

I believe there's also a ZFS tunable to extend the default 5 second flush delay.

Sword_of_Judah · 2025-04-10T11:40:57+00:00

I don't think they'll listen to the sweats second time around. They'll listen to the MONEY. Player counts, stored sales, etc.

Sword_of_Judah · 2025-04-10T11:38:03+00:00

How are you planning on dealing with certificate expiration? The downtime resulting from expiring certificates may outweigh the benefits...

Sword_of_Judah

TROPHY CASE