Root-on-zfs may be a good choice for the Steam Deck
I know it's an out of tree module but a full root-on-zfs system would offer some neat benefits, from foolproof instant/light (and working) system-wide snapshots (recovery points) to filesystem level compression and encryption with no noticeable overhead on the CPU.

ZFS does require sone ram to work efficiently, but the impact shouldn't be too heavy.

I won't be getting a deck anytime soon as I have no real use for one right now as my rig works quite well, but I can't help to wonder if such a setup has been considered or if anyone has tried it yet.
< >
Visualizzazione di 1-9 commenti su 9
Note on a handlheld battery life is way more important. The power needed to do a compressed and encrypted root doesn’t really make much sense when the benefits are minimal
While I didn't consider battery life (which is indeed a huge error on my part, thanks for pointing it out!), I think a compressed filesystem wouldn't be a minimal benefit if we consider the limited storage space the deck has and that many games have some not-compressed game assets (excluding video and audio resources), plus the manu configuration files all over. I've run some tests some years ago, and the disk usage on zfs was roughly 75% compared to ext4 (I don't remember which games I tried that with tbh).

Given the low cpu overhead of zfs' encryption (if tuned well) I'd really love to see some benchmarks on its power consumption. I might give it a try
What exactely would be the point or benefit of using ZFS in this scenario when the deck doesn't even have ECC memory?

As far as I can tell storage is pretty trivial to upgrade, and the cons of shortening battery life on a device when the whole selling point is mobile gaming is a non-starter to begin with. I also see no actual benefit of using encryption on a mobile gaming device, especially not if it doesn't work flawlessly out-of-the-box. ZFS might have it's uses (though even that is debatable, given the alternatives), but it's not a mobile gaming handheld.
Effortless (and light) system-wide backups would have its uses though. No system upgrade could go ever wrong without a 100% working rollback option. That alone would be a great feature.

Encryption would also work flawlessly our of the box, and wouls make sure no one would be able to access any data stored on the deck, linked or not to Steam. It'd be a top-notch security feature for what may be a great portable computer.

If you want another pro, Valve could easily put up a tool to format external drives with zfs and perform backup/restore of game data way easily, usually with faster speed than usual tools (rsync for instance), simply using the send/recv feature. This'd also apply to user data backup, which may even be incremental. Imagine sending your console to tech support, ending up with a new one and effortlessly syncing back all of your data. That's something not yet seen in any portable gaming device, and it would even work buying a newer Deck model.

The features zfs offers are many imho, and I believe they should be carefully considered while drafting plans for the Deck v2
Ok assuming we aren't going to encrypt the OS drive (because that woudl be dumb) and are just compressing it, I sort of just feel like the space savings for the OS side arent really justified via the increased processing required to constantly decompress the files to read them. The OS on the SteamDeck is only 10GB meaning the space savings aren't going to be that dramatic. I also don't think snapshots are a huge benefit either. The OS can be recovered via the BIOS and an USB stick, and I'd think a dual BIOS setup would be a better thing to have than a snapshotted SteamOS3

Remember snapshots still incur a cpu and disk IO performance hit. Which on a hand held console is not a great trade off for a mega theoretical corruption of the OS or Steam UI front end.

You don't want to compress the game files because that's definitely going to impact FPS and performance in a lot of ways

The battery life hit for a compressed OS doesnt feel like its a great trade off for minimal disk space savings and these sort of edge case benefits
Ultima modifica da Satoru; 13 mar 2022, ore 15:49
Everything about this suggestion is awful.

The point of handhelds is to try getting the most out if the battery, not shortening its usage by making things inherently more demanding than they should be.
Messaggio originale di Satoru:
You don't want to compress the game files because that's definitely going to impact FPS and performance in a lot of ways
This is something I'd love to test on the Deck tbh. So far I can tell you an encrypted+lz4 compressed won't cause any significant fps drop for the test I've conducted on some laptops.

And until I ser some data (or find the time to run some tests myself) about the hit on battery consumption I don't see why this suggestion should be discarded. If you're confident about battery life being shortened so drastically I welcome everyone who can to run the tests.
Most people on here are just contrarians and have never used ZFS. +1 to this idea and i hope a custom Steam OS build would consider this.
where the h e c k did my rant post go????

anyway, personally, i'm too lazy to test it myself - every game I want on deck already fits with space to spare. your average game nets anywhere from a 30-60% space savings with lz4 (just because developers are too lazy to pre-compress their assets, usually. see hitman 3 as an example of the opposite. 300+GB of assets for 1/2/3 combined turned into 80 on disk after they applied intelligent lz4 compression and deduplication) and lz4 can decompress at multiple gigabytes per second on a single thread. an operation that happens occasionally, not the entire time you're playing the game. raspberry pis can run zfs with compression, bro.

so the point is, there are some - few, but some - game developers already delivering games with assets compressed through the same algorithms that zfs can use by default. nobody's complaining about performance issues related to compressed assets in those games. applying it to the whole system is a no-brainer if you have space constraints... or possible performance concerns due to low performing external media...? CPU faster than storage? no reason not to compress.
< >
Visualizzazione di 1-9 commenti su 9
Per pagina: 1530 50

Data di pubblicazione: 13 mar 2022, ore 6:51
Messaggi: 9