Posts by prtigger1

  • Lower Btrfs scrub and file system write performance with backport kernel 6.17.13, compared to stable trixie kernel 6.12.57

    ryecoaaron


    Hi Aaron

    Thank you, i just realized, that these settings

    exists for longer time and aren't new with

    OMV 8.

    Never noticed that before, because i was focused

    on /etc/sysctl.conf... ;)


    But it's not to late to keep an eye on the

    default changes...


    I guess that will not fix the performance

    problem with my Btrfs storage...


    I decide to stay with the very good performing

    6.12.xx stable kernel, until a newer backport

    kernel is coming up. 6.17.13 is EOL right now.


    Best regards

    Prtigger

  • Lower Btrfs scrub and file system write performance with backport kernel 6.17.13, compared to stable trixie kernel 6.12.57

    The scrub is only a little bit slower than with 6.17.13 bpo:



    Best regards

    prtigger

  • Lower Btrfs scrub and file system write performance with backport kernel 6.17.13, compared to stable trixie kernel 6.12.57

    ryecoaaron


    Exact this was my idea today!


    I disabled backports, cleaned up the kernel stuff and repos. Installed the lastest 6.12.63 kernel meta package...

    After that, i installed the 6.17.4-2-pve kernel... I've both kernel to start.


    First test (Writing 1.8GB file to Samba share): PVE Kernel is slower than Debian bpo 6.17.13 kernel, yesterday.

    Compared to actual 6.12.63, the write performace is more than 20% slower... Worse!!


    Btrfs scrub is just running for 41 minutes...


    By the way, if the settings in:

    /etc/sysctl.d/99-openmediavault-nonrot.conf

    are useful for my hardware, i had not fully checked at this time... (-nonrot stands for ???)

    I`ve got an extra conf file, optimized for my network stack.

    At this time i override laptop.mode = 0 (Changed yesterday, after i post the information here)


    But both kernels run with this settings...


    Best regards

    prtigger




    Best regards

    prtigger

  • Lower Btrfs scrub and file system write performance with backport kernel 6.17.13, compared to stable trixie kernel 6.12.57

    Hi Aaron

    That's a possible explanation...

    The load is higher and the cache usage is

    lower during scrub. That's what i can see.

    The scrub time difference is massive...


    Normally my system is performing pretty

    well with the older kernel...


    If there is any way to optimize this bad behavior, i don't know at this time.

    Switching to other file system may be the

    last step...


    That's the actual status...


    Thank's and best regards

    prtigger

  • Lower Btrfs scrub and file system write performance with backport kernel 6.17.13, compared to stable trixie kernel 6.12.57

    Hi folks


    I find a fundamental degraded Btrfs performance (srub+filesystem write) with the bpo kernel 6.17.13. Compared with the stable 6.12.57 kernel

    on my Supermicro server. No change on system, just change the boot kernel in Grub. Filesystem is a Btrfs raid 1 over 3 Samsung SSDs


    Scrub with 6.17.13:



    Scrub with 6.12.57



    That´s double time for exact the same Btrfs data filesystem!

    Copying a large file from Windows 11 client to the Samba share is slower,too. But not that much.


    At this time, no idea what changed in Btrfs kernel driver, but on my old dual core Intel Atom D510 server, this is bad stuff with 6.17.13.


    If anybody noticed identical performance issues, please keep me informed.

    Ideas welcome!


    Best regards

    prtigger

  • Feature or fault on server console?

    Quote from votdev

    You may execute systemctl list-units | grep getty and post the output here.

    Hi

    here it is:


    Code
    root@pr-srv-01:~# systemctl list-units | grep getty
  getty@tty1.service                                                                        loaded active running   Getty on tty1
  system-getty.slice                                                                        loaded active active    Slice /system/getty
  getty.target                                                                              loaded active active    Login Prompts
root@pr-srv-01:~#


    Another question:

    Where is the place of generating the 'beep' signal (systemd?).


    Best regards

    prtigger

  • Feature or fault on server console?

    votdev


    Here is the photo right after update to latest version and reboot (Login coming up on cosole):



    Here is the photo 10 seconds later, when 'beep' signal is coming up:




    with the older OMV versions the new output always overwrites the exiting bootup output...


    That´s what i mean...


    Best regards

    prtigger

  • Feature or fault on server console?

    votdev

    Should i execute the command


    omv-salt deploy run issue


    right after a had done an update with

    omv-upgrade?


    For me it looks like, that only a clear

    command is missing, before the updated

    login information is displayed (after boot on beep signal).

    The result is that the old information is not

    overwritten like before...


    With the next update, i'll take a picture of this...


    Best regards

    prtigger

  • Feature or fault on server console?

    Hi folks

    After updating from 7.7.24-4 to 8.x i figured out, that on the server console screen, the login screen is not cleared again, when it´s

    updated (after OMV version update) with new omv-version number, at beep signal.


    Now with OMV 8 all new login information are added right after the bootup login information, on same page.

    With 7.x, 6.x this never happened.


    Is this a feature?


    Best regards

    prtigger