[pve-devel] Synology NAS container O_TMPFILE fallback support

[Thomas Lamprecht]

Hello,

Am 24/11/2023 um 19:15 schrieb Arunas:
> as somebody noticed or not, but PBS starting 2.1x stopped working on
> Synology NAS machines earlier that 2020 or even newer models which use
> 3.1.1 kernel.

That kernel went EOL quite exactly 10 years ago, oof...
https://en.wikipedia.org/wiki/Linux_kernel_version_history#Releases_3.x.y

> I would like to ask community and/or development to include this or
> similar patch to support very reliable NAS machines….

Yeah the argument to reduce electronic waste is the only thing that
makes me not reject this immediately..

> Please see:
> https://github.com/ayufan/pve-backup-server-dockerfiles/compare/master...jclab-joseph:pve-backup-server-dockerfiles:feat/fallback-for-o_tmpfile
> 
> the file: versions/v2.1.5/server/proxmox~fallback-o_tmpfile.patch
> 
> I am long runner of Synology NAS machines, and even DS1819+ which is
> very capable NAS, still use the 3.1.1 kernel.

Well, with a boatload of security holes I guess, or do you get frequent
kernel updates with latest known security holes fixed?
As we'd like to avoid making life for ransomware attackers even easier..
I mean the DS1819+ got released in 2018, still shipping with a kernel
released 7 years before that (2011) is IMO rather irresponsible..
Even the 4.14 kernel, back then a year old, would have had enough time
to ripe and ensure that it works perfectly, after all they only have to
support a very selected set of hardware.

Did you ask Synology for providing a newer kernel version?
After all those are the ones you gave money for this machine, and
there's no real excuse to not provide newer kernels (at least for a few
years). As I'm not exactly jumping for joy at the thought of having
to do work just because some proprietary company doesn't wants to do
their basic homework.

We'll evaluate this, but cannot promise anything, from only a quick
check the patch would need some cleaning up, and a in-depth check to
ensure it doesn't introduce some subtle bug we are then responsible for.

Regards,
 Thomas