OverlayFS Adds A "Volatile" Option - Faster Performance But All Syncs Are Omitted

[phoronix]

Phoronix: OverlayFS Adds A "Volatile" Option - Faster Performance But All Syncs Are Omitted

OverlayFS as the Linux union mount file-system that allows combining multiple underlying mount points into one is seeing a new feature with Linux 5.10...

http://www.phoronix.com/scan.php?page=news_item&px=OverlayFS-Linux-5.10

[Etherman]

Overlayfs is also used, optionally, by the excellent profile-sync-daemon software.

[andreano]

Nice! No more need to abuse /dev/shm to defeat fsync, and with that, the biggest tmpfs performance myth will evaporate.

This should have come 10 years ago, when spinning iron was common. But it should still matter as long as write latency is a thing, and still be great for simpler flash controllers in embedded devices and your RPi.

[skeevy420]

It'd be nice to tie this into a way to bind-mount some directory onto /tmp for the times I know I'm going to compile something that'll exceed my tmpfs ramdisk size. For me, that's the best use-case I can think of for this.

[dxin]

So they are allowing the user to forgo all data durability guarantees and achieve maximum performance? After steering FS development for dacades the database people finally gave some grounds to container people?

[polarathene]

For Docker containers, this would only affect the image file system right, not any bind mounts? (no clue about volume mounts that are usually used for persistence?)

Wanted to add this too, profile-sync-daemon is great. This particular feature of overlayfs is probably a bit of a bad idea in this usecase.

You definitely want the syncing unless it's like Kiosk mode. That project was really helpful running an old Core2Duo laptop well off a USB 2.0 stick, the poor I/O performance was what really slowed down the system like a snail whenever a browser was open, just a single tab with youtube was syncing to disk frequently in both Chrome and Firefox I think and I was surprised to find that was the culprit. profile-sync-daemon smoothed that right out

So they are allowing the user to forgo all data durability guarantees and achieve maximum performance? After steering FS development for dacades the database people finally gave some grounds to container people?

I think this is effectively like a ramdisk, but instead with the benefit of overlayfs providing a RO mount(s) over an existing filesystem?

With Docker (or at least docker-compose), I've noticed containers can be stopped but aren't killed unless you run say `docker-compose down`, which was surprising to me that modified files in the internal data I thought of as immutable remained modified with a following `docker-compose up` (if there was no `down` prior). Caused some bugs with an init script that modified config files on the assumption the container started with a clean slate state. I suppose this volatile feature would fix that misunderstanding/mishap so the expected/desired behaviour would occur.