Well I am not claiming to be a ZFS expert, I have been using it since 2008ish both personally and professionally. So I am fairly certain what I have said here is correct semantics aside.

Both lz4 and zstd have almost no performance impact on modern hardware.

So “almost” is zero in your mind? Why waste the CPU cycles on compressing data that is already compressed? I recognize that you might not care, but I sure do. And I wouldn’t say it would be wrong to think that way.

compression acts on blocks in ZFS, therefore it is enabled at the pool level

This is incorrect. You can zfs set compression=lz4 dataset (or off) on a per dataset basis. You can see your compression efficiency per dataset by running zfs get compressratio dataset, if your blocks were written to a dataset with compress=off you will see no compression for that dataset. You can absolutely mix compressed and uncompressed datasets in the same pool.

OP added a -O option to set compression when he created the pool but that is not a pool level setting. If you look at the documentation for zpool-create you will see that -O are just properties passed to the root dataset verses -o options which are actual pool level parameters.

You might be confusing compression and deduplication. Deduplication is more pool wide.

ZFS does indeed need to allocate some space at the front and end of a pool for slop, metaslab, and metadata. I think you are confusing filesystem and datasets.

Well yes and no here. You are right I should have been calling them datasets. Datasets are a generic term, and there are different dataset types, like file systems, volumes and snapshots.

So yeah I maybe should have been more generic and called them datasets but unless OP is using block volumes we are probably talking about ZFS file systems here. Go to say the zfsprops man page and you will see file system mentioned about 60 times when discussing properties that can be set for file type datasets.

I’m not sure what you’re trying to say about NFS and ZFS, here but this is completely false, even if you mean datasets.

It sounds like you are unaware of the native NFS/SMB integrations that ZFS has.

It is totally optional but instead of using your normal /etc/exports to set NFS settings ZFS can dynamically load export settings when your dataset is mounted.

This is done with the sharenfs parameter zfs set sharenfs=<export options> dataset. Doing this means you keep your export settings with your pool instead of the system it is mounted on, that way if you say replicate your pool to another system those export settings automatically come with it.

There are also sharesmb options for samba.

My point was then that you should lay out your dataset hierarchy based on your expected permissions for NFS/SMB. You could certainly skip all of this and handle these exports manually yourself in which case you wouldn’t have to worry about separate filesystems and this point is moot.

My post was less about compression and more about saying that you should consider splitting your datasets based on what is in them because the more separate they are the more control you have. You gain a lot of control, and lose very little since it all comes from the same pool.

Some of the reasons I have these options are less important than they were a decade ago. i.e. doing a 20tb ZFS send before resuming a send was possible sucked. Any little problem and you have to start over. Having more smaller filesystems meant smaller sends. And yeah I was using ZFS before lz4 was even an option and CPU was more precious back then, but I don’t see any reason to waste CPU cycles when you can create a separate file system for your media and set compression to off on it.

And most importantly I would want different snapshot policies for different data types. I don’t need years worth of retention for a movie collection, but I would like to have years worth of retention on my documents filesystem because it is relatively small so the storage consumed is minimal to protect against accidental deletion.

Yeah it won’t make much difference these days.

I suppose my point was more so that because ZFS is a pool that can be split up with filesystems new users should be thinking a little differently than they would have been used to with traditional raid volumes/partitions.

With a normal filesystem partitions are extremely limiting, requiring you to know how much space you need for each partition. ZFS filesystems just being part of the pool means that you can get logical separation between data types without needing that kind of pre-planning.

So many settings with ZFS that you may want to set differently between data types. Compression, export settings, snapshot schedules, replicating particular data sets to other systems, quotas, etc.

So I was mostly just saying “you should consider splitting those up so that you can adjust settings per filesystem that make sense”.

There is also a bit of danger with a single ZFS filesystems if you have no snapshots. ZFS being a copy on write filesystem means that even deleting something actually needs space. A bit counter intuitive but deleting something means writing a new block first then updating the FS to point at the new block. If you fill the pool to 100% you can’t delete anything to free up space. Your only option is to delete a snapshot or delete entire filesystems to free up a single block so that you can cleanup. If you don’t have a snapshot to delete you have to delete the entire filesystem and if you only have one filesystem you need to backup+delete everything… ask me how I know this ;)

If you have several filesystems you only need to backup and destroy the smallest one to get things moving again. Or better yet have some snapshots you can roll off to free up space or have quotas in place so that you don’t fill the pool entirely.

Yep you can certainly do it that way.

If your concern is just that you already created it you can shut it off after the fact. All new blocks written will have compression disabled.

You probably shouldn’t enable compression on the root filesystem of the pool. Since you mention movies/TV shows/music those are just going to waste cpu cycles compressing uncompressable data.

Instead you should consider separate ZFS filesystems for each data type. Since ZFS is a pool you don’t have to pre-allocate space like partitions so there is no harm in having separate filesystems for each data type rather than single large filesystem for everything. You can then turn on compression only for those filesystems that benefit from it.

Also remember that many permissions like nfs export settings are done on a per filesystem basis so you should lay out your filesystems according to your data type and according to what permissions you want to give out for that filesystem.

i.e. if you are going to have a Navidrome server to stream your music you don’t want to give that server access to your entire pool, just your music.

Separate filesystems also means you can have different snapshot schedules/retentions. Documents might need to snapshot more often, and be kept around longer than media snapshots.

Same here. I have three models of Zebra printers and they were all pretty much plug and play with Linux.

Blockchain isn’t really a great storage mechanism for large files, it is good for small transactions/records. This is why most NFTs are just links to content instead of storing the content in the blockchain itself. It is possible to store that data in the chain but you usually pay transaction fees based on the size of that data. To store the data in the chain everyone participating in the chain would need a full copy of every video posted which isn’t really feasible long term.

It is also nearly impossible to moderate. i.e. how do you remove illegal CSAM content from something that is designed to be immutable.

So storing data like this is just not the right use case for blockchain.

Someone could create a site based on a blockchain where you distribute links to videos, but those links would still need to be stored somewhere else. You really aren’t gaining much beyond just hosting the content yourself.

The only valid use case would be if you are attempting to avoid government influence that might try to modify your content later, or able to prove that you are the one posting the content. You could use the blockchain to post a link to a video and the hash of the file to verify it is the correct file, then anyone with access to the chain would have a record of who posted it and a way to validate that the content hasn’t been modified.

There are federated options like PeerTube that are close to what you want but without the blockchain issues.

I think the better solution is if the company is so important that it needs to be bailed out, then should just get nationalized when it fails.

Our money goes towards bailing them out, but the public owns it after that. The shareholders that ran it into the ground shouldn’t get to keep it.

If you want the search to be flexible like handling things like root stemming (i.e. for matching words that are pluralized etc) you might want to put the text into an Elasticsearch database.

You might run into problems with the field length if these are long documents. A possible solution to that would be an putting each page into its own field inside of the document.

If this is for a non tech user to search, the Kibana interface should be relatively easy for anyone to use.

The biggest question is going to be will the AI be able to run locally or will they use it as an excuse to turn the game into a subscription.

I can see it now… “The game needs to make calls to OpenAI that we have to pay for to generate dialog so we need to charge by the month for the game”

They will finally have an excuse to turn single player games into subscriptions as well.

Using AI in games isn’t about AI coding. Using AI to code games is likely already in almost every studio.

When they say AI in games that means AI artwork, voice lines, environments, etc.

i.e. imagine NPCs that change their voice lines based on recent events like recently completed missions, or your player looks/equipment/etc. With AI you don’t have to pre-record a near infinite amount of voice lines they can be generated on the fly.

It’s not like they want to punish you for paying off your car.

The reality is that a high percentage of the population loads up on more debt after paying off current debts, so the algorithm reflects that. Usually those points come back after a couple of months.

Actually I believe host networking would be the one case where this isn’t an issue. Docker isn’t adding iptables rules to do NAT masquerading because there is no IP forwarding being done.

When you tell docker to expose a port you can tell it to bind to loopback and this isn’t an issue.

I always see this argument but I really don’t want anything plugged into anything as important as the USB-C port while the phone is in my pocket.

3.5 plugs are rather short outside of the phone (at least for headphones with 90deg plugs) to minimize leverage that you put on the port. Being able to rotate also means less stress on the port as well.

The USB-C adapters are pretty short, but lack the rotation. I have replaced USB-C ports in dozens of Nintendo Switches and other devices, it is pretty clear they aren’t designed to take much stress.

Long story short if anything happens I would much rather have the 3.5mm pin stuck in a headphone jack than breaking the USB-C port and making it so my phone is a brick.

I don’t use the WebOS app but generally default subtitles/audio languages are set on your profile and the apps pick up those settings.

Try logging in to the web interface and going to your user profile. There is a “Playback” section where you can set your preferred languages. If this isn’t set it likely is taking the default language from your media files instead.

+1 to this.

First check that you can get to Jellyfin on your Jellyfin server itself (start with the IP address). This makes sure that the service is running, and that you are trying to access the right port/protocol.

If that works, try the web browser on your phone or any other device on your network next. If that fails it tells you there are firewall or DNS issues.

Laws can easily have exceptions for these things. In China for instance “non approved” VPNs are illegal, but there are plenty of legal VPNs as well.

For instance businesses can get approval for their own VPNs, and regular people can use some free/paid VPNs within the country, but presumably the government can see all of the traffic within those.

My prediction is that this is more about banning VPNs than about age verification. Start with this, then when everyone is “using VPNs to break the law” they have an excuse to ban VPNs.

Governments world wide likely see VPNs as incredibly dangerous. Plenty of examples of countries like Iran cutting off the internet entirely to prevent protests from organizing.

I think they want their own great firewall.

Presumably the cert would be a smart card (similar to credit card chips) protected with a pin. And they can use revocation lists to remove cards that are reported stolen.

There would have to be a serial number at the least but that would change every time your card expired, and the government would certainly know who is issued what serial.

Another downside is users would need smart card or NFS readers to use them. Smart cards have been around for digital identification for decades now, it’s really surprising that more government haven’t pushed their use. From a user perspective though it would be pretty quick that every online service would start requiring them and any online anonymity would erode pretty quickly.

Even with https if you aren’t on TLS 1.3 the SNI (server name indicator) is not encrypted so the hostname you are trying to access would be visible to your ISP.

Forcing your browser to only use TLS1.3 would fix that but who knows how many sites it would break.

Unauthorized VPNs (non government approved) are illegal in China. If a business needs their own they can get approval but they have to apply for those exceptions.

It isn’t really enforced, probably especially so for non citizens, but if you do something they don’t like it is something they could use against you.

You would probably be less breaking the law to just directly open up SSH and access that instead of tunneling through a VPN. Even though SSH can do tunneling of its own.