Will FatDog64 ever come with Overlayfs?

[Duprate]

FatDog64 Overlayfs! When will this wonderful day come? Who qualifies? When can we choose a FatDog64 aufs or overlayfs? For me, it can only come with overlayfs! Unfortunately, I can't help much. Just encourage. I'm using DebianDog Bullseye with Overlay and I'm really enjoying it! However, I confess that I have a great appreciation for FatDog64 and only wish the best for our community! Cheers to all!

[step]

I'm curious, what is your reason for wanting a Fatdog64 version with overlayfs instead of aufs?

[Duprate]

Because it is the future, and the future can be now. Aufs will always be a patch, it was not accepted by Linus Torvalds. Overlayfs is built into the kernel, I can download the source directly from Kernel.org to do my compilation, keep my system up to date without relying on third parties. I can make a custom kernel for my system, very small in size. If Linus Torvalds himself found the aufs obscure, what could a simple user like me say? In addition, everything I do with the aufs system, I also do with the overlay system. I'm just giving you an idea ... It's a matter of more independence ... I don't want to hurt anyone's feelings ...

[dimkr]

overlayfs doesn't allow layers to be "appended" at runtime. All layers (aka all SFS files) needed to be mounted at boot time, and that's it. No sfs_load.

I've tried to boot Puppy on my Chromebook with an overlayfs at / (https://github.com/puppylinux-woof-CE/woof-CE/pull/1948) and it works just fine, but sfs_load doesn't work because it relies on the Aufs ability to add an extra layer at runtime.

I believe this is a big loss for most Puppy users.

[Duprate]

Hi! Looking at the work of "fredx181", it is possible to expand our horizons. This forum is big enough, where different and very promising ideas fit! Overlayfs are not "plastered", as many people believe. I launched the idea about a future FatDog with overlayfs to see the reaction of the forum members interested in the subject. It is obvious that FatDog64 is a distro with its own identity, well developed and that belongs to its developers. It is up to them to decide their future. They won't change the system just because I'm asking ... But you can think about it ... Even if you don't want to, you're already thinking ...

"If there's a misunderstanding, it's Google Translate's fault!"

[taersh]

I believe this is a big loss for most Puppy users.

Yes, this would be a big loss.

But FatDog as well as the other *Dogs is NOT Puppy. For example, FatDog uses its own script to load .sfs files.

[rockedge]

WeeDog uses Overlayfs to be able to have a broader range of kernel choices and that it is incorporated into the present Linux kernels by default.

I have a puppy upupBB-18.05+8-OL that is a Puppy Bionic32 but set to use Overlayfs instead of AUFS. It comes from an upupBB-18.05+7-OL that I added the delta file to make it +8. These are made by gyro.

http://murga-linux.com/puppy/viewtopic. ... 777#989777
https://www.mediafire.com/folder/inbkdjmie89hm/overlay

[user1111]

Fatdog tends to further mature with each release, increased stability, but with many things being updated to newer versions.

Migration over to overlayfs only would involve many changes, and less functionality, a regressive rather than progressive step, that would also potentially introduce less stability.

If you're at a level where you have the ability to compile your own kernel, you'll equally be able to modify Fatdog (as I have done) to match. The Bulldog (cli core) of Fatdog can still be used as-is with a bulk standard (overlayfs) kernel.

[Duprate]

Or continue using the DebianDog Overlay, which I am using now and I am getting used to it. At the beginning, I was a bit behind on Debian ... But Fred's project is making me change my mind. Evolution often requires a change in thinking.
I am grateful to everyone who, dedicated a little time to think about the matter and express their opinion.

"The waters always find the easiest way"

Google Translate sometimes doesn't translate correctly what I write ...

[wiak]

Hi! Looking at the work of "fredx181", it is possible to expand our horizons.

Personally, for long time now, I have felt that the future is inevitably overlayfs for such frugal install types of distro and aufs use will eventually cease. Hence my deciding to use overlayfs for WeeDogLinux when I started developing it almost two years ago (despite being much more familiar with aufs at the time). I would never change back. I like being able to use most any upstream produced kernels too much (aufs requires kernel patching; overlayfs does not since officially in kernel), but can use Puppy huge kernels too since overlayfs included as a module with these nowadays too...

No need to use overlays to load sfs file, as has been oft-discussed on Puppy forum - for almost as long as Puppy has existed, tinycorelinux has been loading sfs files on the fly via symlink methodologies (and not used aufs or overlayfs at all...).

As for stability, an unofficial patch can never be as stable as an official kernel supported methodology. It is also great to be able to use stock well-tested kernels provided by the likes of Debian and so on.

Anyway, time will tell, but I expect to see most small distros moving away from aufs over time, so no accident that a significant amount of effort has also, in relatively recent times, been put into experiments to boot Puppy with overlayfs initrd support. But whatever... each to their own...

I have read that overlayfs offers better performance. I cannot confirm one one way or the other:
https://gregoryszorc.com/blog/2017/12/0 ... e-to-aufs/
https://docs.docker.com/storage/storage ... fs-driver/

[Duprate]

In my heart, there is also room for WeeDogLinux. I just need to find some time ...

[dimkr]

WeeDog uses Overlayfs to be able to have a broader range of kernel choices and that it is incorporated into the present Linux kernels by default.

Yep, the choice of overlayfs or aufs basically boils down to being closer to mainline kernel/using whatever everybody including Docker uses/performance considerations (assuming there is a non-negligible difference), vs. having a working sfs_load.

[rcrsn51]

... vs. having a working sfs_load.

Or modifying sfs_load to work with overlayfs

[dimkr]

... vs. having a working sfs_load.

Or modifying sfs_load to work with overlayfs

That's exactly my point - as far as I know, overlayfs layers must be chosen at mount-time and can't be added later. Please correct me if I'm wrong.

[rcrsn51]

That's exactly my point - as far as I know, overlayfs layers must be chosen at mount-time and can't be added later. Please correct me if I'm wrong.

If Fatdog wanted to switch to overlayfs (and I don't think that they do), it would be possible to replace their load-on-the-fly tool with a different technique (see wiak's post above).

But I doubt that projects with a strong commitment to aufs would be willing to do that.