Search results

"Backward compatibility" means data created with older version of some software can be used by newer version of the same software.This is quite common. But what you expect is "forward compatibility": data created by newer version of software (in this case zfs 0.7) to be usable by older version...

What you expect is "forward compatibility", but in software industry it is rarely guaranteed without back-porting new features to previous version...

I hope updated LXC 2.1 will be included...

That does not seem to me to be blocker, but rather quite natural behaviour...

But if I set those properties after installation, those changed xattr-types are used only for new writes, aren't they? That's too late...

How can I set xattr=sa at PVE-installation? As I see, xattr has "sa" value only for /data/subvols, but for /ROOT, /ROOT/pve-s and /data it has value "on"...

Just remove swap and you are done. I have been running all my servers without swap for a few years with no issue...

ZFS on top of HW-raid1 might have serious impact on results. But what I see as bigger problem are those hybrid SHDDs: It might be difficult to achieve comparable results, as one can never be sure what part of drive (ssd or hdd) is just being used. Moreover, I'm not sure if common utilities...

Not sure if your 1st point is valid. ZFS on raid1 should give about the same write/rewrite performance, as ZFS on single drive (while read performance on raid1 is much higher on single drive)... https://calomel.org/zfs_raid_speed_capacity.html

Try (i.e. fire Prime95 in your VM) and see yourself! It can even hit higher than standard maximum frequency, depending on how many cores your VM is using. E5-2640 v3 has standard max 2.6GHz, but it also supports "Intel turbo boost" (2/2/3/4/5/6/8/8). So if only 1 or 2 cores are needed, it can go...

Maybe time to remove from disk something of low value, that can be restored later, i.e. some os-images or vm-templates. Reboot and then you can add disks...

I do not have PVE 3.x so I can only guess it either did not support frequency scalling yet, or used "performance" as default cpu governor (cpu running all the time at 100% frequency). I suppose new PVE5/Debian9 is using "on-demand" governor, which makes much more sense. It has no drawbacks, but...

Yes, you are exactly right. Every modern cpu does this, for good reason. You may play with cpu-governor, but why would you do that? Why do you want your cpu to run with the highest clock, if it does not do anything???

I doubt Win7/64b VM could run with just 1GB RAM used. Balooning driver could reclaim that memory, but Win7-VM would start using it immediatelly after that again... BTW, I really do not understand this obsession of having as much free memory as possible. WHY??? Any meaninful using of memory is...

BTW have you noticed the naming-scheme for your iso-images is a bit misleading? Not sure how it is on Windows, but on Linux the standard "ls" (without additional switches or locales-tweaks) produces output: ... proxmox-ve_5.0-5ab26bc-5.iso proxmox-ve_5.0-af4267bf-4.iso ... I mean...

Just to make things clear: it does not boot into the current (running) kernel, but into the kernel defined as primary in boot-loader. So if kernel was updated, it boots into the new one...

It is sure not recomended for production, but some time ago I tested PVE & Docker on the same server. It co-existed very well, I do not remember having any problem with it. The only drawback was two separate GUIs: one for PVE, the other for Docker (Portainer). If this could be integrated...

For SSD-controller it does not matter what filesystem you have. Even if your OS wants to write to some particular sector, SSD decides on its own where data actually will be written, for the benefit of wear-leveling. Moreover, SSD can not change content on sector-base, because "erase" on SSD...

Be it anyway, it does not correspond to FHS nor LSB. Status is kind of log-message, so it should be written somewhere ot /var/log. So that db-based fuse should be mounted somewhere ins /var/log...

Problem is PVE, not linux generally. PVE writes to disk all the time, even with no VM running. True, it is just a few bytes every 3-4 seconds, but any write-op means at least 8kB is written. Moreover, TRIM on ZFS (on linux) is not supported, so quickly every block is marked as "used" and then...