Tmpfs Gains New Features With Linux 6.6

[phoronix]

Phoronix: Tmpfs Gains New Features With Linux 6.6

The tmpfs file-system that keeps all of its data within virtual memory has gained a few new features with Linux 6.6, including the long-awaited quota support to better protect against malicious users that could try to consume all of your system RAM...

https://www.phoronix.com/news/Linux-6.6-Tmpfs

[archkde]

With quota support, Tmpfs can better protect against malicious users or problematic programs from consuming all of the system memory.

Can it really? A malicious program can just directly allocate a huge bunch of memory. Or mount a tmpfs (or even better, ramfs, since that doesn't even swap) inside a user namespace.

[flower]

Can it really? A malicious program can just directly allocate a huge bunch of memory. Or mount a tmpfs (or even better, ramfs, since that doesn't even swap) inside a user namespace.

max ram / swap usage can be controlled by cgroups. not sure about ramfs - but i'd say ramfs isnt use that much and a userspace program shouldnt be able to create and mount it.

[avis]

I'm looking forward to tmpfs supporting transparent block compression. I know I can use a ZRAM block device as a tmpfs base storage but it's all kinda inconvenient.

[archkde]

max ram / swap usage can be controlled by cgroups.

Yes, I know that. But IIRC, tmpfs usage counts towards that.

not sure about ramfs - but i'd say ramfs isnt use that much and a userspace program shouldnt be able to create and mount it.

Maybe it shouldn't be that way, but it is a fact that ramfs can be mounted inside user namespaces.

[discordian]

I'm looking forward to tmpfs supporting transparent block compression. I know I can use a ZRAM block device as a tmpfs base storage but it's all kinda inconvenient.

tmpfs is dynamic and very different to normal block-based devices (it does not depend on the block layer at all), would likely complicate stuff a great deal.
how about configuring a zram-based swap (either alone or higher priority to disk-backed swap), you will get transparent paging out to compressed zram when needed, while keeping tmpfs simple and fast.

[cl333r]

The kernel devs should introduce a "I (the kernel) don't know the file's size" concept instead of just lying (by reporting bogus file sizes).

Because now we (the client side) are dealing with it by ad-hoc guessing heuristics. Like when you want to read a file and need to allocate enough space you can't rely no stat.st_size.

For those who don't know what I'm talking about, look into /proc/ or /sys/ and look at the files sizes reported.

Not sure though if /tmp file sizes are always reported properly.

[avis]

The kernel devs should introduce a "I (the kernel) don't know the file's size" concept instead of just lying (by reporting bogus file sizes).

Because now we (the client side) are dealing with it by ad-hoc guessing heuristics. Like when you want to read a file and need to allocate enough space you can't rely no stat.st_size.

For those who don't know what I'm talking about, look into /proc/ or /sys/ and look at the files sizes reported.

Not sure though if /tmp file sizes are always reported properly.

1. /proc and /sys "files" are not files thus lstat() doesn't always work on them.
2. tmpfs has no problem with that, it actually stores files.

[StarterX4]

Tmpfs with Linux 6.6 also adds support for user xattrs, supporting a limited number of user xattrs.

Maybe finally working on Flatpaks will be possible on tmpfs, and it won't be throwing out "Operation not supported".

[timofonic]

Maybe finally working on Flatpaks will be possible on tmpfs, and it won't be throwing out "Operation not supported".

Flatpacks, AppImage and snaps should be forbidden on any sane Linux distro, anyway.