Posts by Jopa

    What ist your real interest in TRIM? Which actually was a feature used in times, when ssd's controllers were not able to manage erased areas for themselves. But that times are gone, and nearly all ssds, that came out in, say, the past 3 years don't need no external TRIM no more. OSses on the other hand alway must still work with much older hardware, and so will, likely, TRIM all ssds they find for the next 10 years.


    Best regards

    Hi,


    guess it's the same with AMD and intel - the latter I know better: Real nice boards for NAS purposes with an embedded cpu are very expensive. Even on 2nd hand market, if someone 's there sell to them at all.


    So I got used to look for older non-embedded server solutions like the board I use with my actual setups. The intel 1150 socket might not be the latest, of course, but at server level time goes by slower, and so I think, my setups are not so far away from cutting edge. At least not for my own NAS needs.


    And costs are far below those for any of those nice embedded solutions. E.g. mainboard, cpu, ram and SAS controller of my main NAS were still below 250$ all together. Ok, they may not spec the low power of an embedded solution - although the Xeon E3-1220L is near that level - but I do not like to spend more than twice for the mainboard with an embedded cpu but still without ram, running my budget to it's end and leaving no money no more for a similar high end power supply that does not waist the spared powe. Or to say: For a NAS, I want to run 24/365, for me it is a must to choose a psu with at least 80+ gold grade. Just because lower grades by the time would eat up more than any power, my cpu, ram, chipset and extra controllers could spare because of ineffiency. And those psus cost as well. Only not so much more as a server level mainboard with an embedded cpu.


    Btw there is a nice site out there listing all known 80+ certified power supply units, where I find and can compare all psus of interest:
    https://www.plugloadsolutions.com/80PlusPowerSupplies.aspx


    Hope I could help.

    Hi,


    guess it's the same with AMD and intel - the latter I know better: Real nice boards for NAS purposes with an embedded cpu are very expensive. Even on 2nd hand market, if someone 's there sell to them at all.


    So I got used to look for older non-embedded server solutions like the board I use with my actual setups. The intel 1150 socket might not be the latest, of course, but at server level time goes by slower, and so I think, my setups are not so far away from cutting edge. At least not for my own NAS needs.


    And costs are far below those for any of those nice embedded solutions. E.g. mainboard, cpu, ram and SAS controller of my main NAS were still below 250$ all together. Ok, they may not spec the low power of an embedded solution - although the Xeon E3-1220L is near that level - but I do not like to spend more than twice for the mainboard with an embedded cpu but still without ram, running my budget to it's end and leaving no money no more for a similar high end power supply that does not waist the spared powe. Or to say: For a NAS, I want to run 24/365, for me it is a must to choose a psu with at least 80+ gold grade. Just because lower grades by the time would eat up more than any power, my cpu, ram, chipset and extra controllers could spare because of ineffiency. And those psus cost as well. Only not so much more as a server level mainboard with an embedded cpu.


    Btw there is a nice site out there listing all known 80+ certified power supply units, where I find and can compare all psus of interest:
    https://www.plugloadsolutions.com/80PlusPowerSupplies.aspx


    Hope I could help.

    Hi all,
    with both of my omv installations (4 and experimentally 5, see details below) I had the same irritation: The enpXs0 network interfaces (my board has two of them), enp1S0 and enp2S0 by intallation, after some time suddenly changed to enp2s0 and enp3s0. In both cases, omv came up with no accessible network address no more, and I needed to connect monitor and keyboard again to fix it via omv-firstaid.
    I wonder, if someone out there can tell me, why this happens.
    Could it be because of the BMC included in the Aspeed ATS2300 chip on the Asus P9D-I, btw a really nice feature of this board? But if, why does it not come up from the start, but somewhen later after a reboot or a shutdown? And why does it keep omv or debian from defaulting to DHCP and rather leaves system with no active network interface at all?
    I just like to understand.
    Best regards

    Hi Thomas,


    thank you for your replies, helping me to understand write hole issue another bit deeperly.


    Remains just one thing re this forum: How can I mark my thread as solved by my own, or must a moderator do it?


    Best regards

    Hi Thomas,


    sorry, the link I included was bad - the "h" of "hole" was cut out somehow. So please look here and tell me, if you think, the author of this article (and coder of a disaster recovery software) did not understand the write hole issue...


    The articles on jr-s.net are quite informative - not only the one you linked - and I'll give them to my co-admin at company.


    BTW: I actually fear power losses at company, and some four or five years ago urged deciders to buy an UPS at least for our servers. Few month later a sudden outage killed the phone system, but not the server integrity. After power was back, most collegues could continue their work from local backups of open/libre office without any help. I only had to clean up the Windows Server for the ERP, because it had blocked a client, that was writing data, when outage occured. I don't even want to think about, what could have happen, if the Win Server had lost power as well.


    Best regards

    I have the same with my Asus P9D-I after changing network setup via omv-firstaid, even when I change back to DHCP.
    Looks like not only ethernet crashes then, but whole network including local loopback (lo, 127.0.0.1). Else monit would not fail on port 2812...
    There is a power cycle neede to make network running again. Just a reboot is not enough.
    Do you have ethenet device names "enp#s0" rather than "eth#" too?


    Best regards

    Hi all,


    after I tried out actually every omv-supported file systems able to handle more than one HDDs in a single volume, from my humble opinion there remain only two file systems, that are reasonable so far: ZFS, the non-Linux mother and btrfs, her real Linux child.


    I will use btrfs in future, as it supports an implicit RAID5 or RAID6 like ZFS. And even if already hear the cry: "But the write hole...." Sorry, but the write hole is an issue not only of btrfs, but of ZFS as well, and in fact of *every* RAID (http://www.raid-recovery-guide.com/raid5-write-ole.aspx) Think it's not really difficult to understand: *Any* redundant saving needs at least two writes to disk to be fulfilled. Which must occure at exatcly at the same time at the platters involved, if a sudden power outage shoudl do no harm. But which OS existing can guarantee this? And even if the OS would do it - how can we be sure, that our disks write their buffered date at the same time? Or at least in the time, they still have, to do anything, if power suddenly fails?


    So there is a write hole not only by theory, but by hardware. And there is only one solution: a UPS able to let the drives write all data they got before shut down. With today's drives buffering 100MB or more we even cannot rely on BBUs on drive controllers no more. They only can save data not sent to the drives yet. But they cannot recover data, that are sent to the drive's buffers already.


    So what at all - to be safe, for every setup with >1 drives driven parallely we need uninterrupted power, as long as the writes last. And a UPS for the whole system is the only solution against write holes. Regardless, which file system and drive pool organisation we use.


    Btw: Btrfs is used quite normally for RAID5 and 6 setups by Synology and Rockstor. Both recommend to use a UPS. Of course.


    Btw2: I actually don't beleive, that the write hole ever can be closed. Neither in btrfs, nor in any other file system. Just think, this would need multiple disc writes and confirmation at the same time. I don't beleive this possible with a power fail inbetween.



    Thanks for reading my thoughts and


    Best regards,
    Der Jopa

    Hallo zusammen,


    ich habe einige Zeit mit der Installation von omv oder vielmehr der von debian gestritten, bis ich mein Mobo mit ASMB7 iKVM - ein weiteres Asus P9D-I - richtig "zugeritten" hatte.


    Ich hatte, wie meine Signatur besagt, ein solches MoBo schon problemlos für einen OMV in eingesetzt, und war deshalb überrascht, als ein weiteres nicht so einfach mitspielen wollte. Bei näherer Untersuchung stellte sich heraus, das zwar beide Motherboards denselben Stand des BIOS aufwiesen, aber das neue im Boot-Menü zwei "AMI virtual" Drives zeigte, die das schon unter OMV laufende nicht aufwies.
    schon unter einem


    In Bezug auf die Installation von OMV kann das bewirken, dass das OMV-Laufwerk als /dev/sdc - oder bei Installation von einem USB-Stick als /dev/sdd - erkannt wird, und, auch wenn Grub nicht weiter meckert, beim Reboot zunächst ein Debian-Boot (blauer Hintegrund) erscheint, und der OMV-Boot (schwarzer Hintergrund) ins Nirwana geht.


    Daran sind die beiden "AMI virtual" drives Schuld, die das BIOS bereit stellt - zu finden zumindest in der BBS-Auswahl -, und die tatsächlich virtuell, also aktuell nicht zwingend vorhanden sind, was grub und die install-tools unterschiedlich bewerten, aber da letztlich die Meinung von grub zum Zuge kommt, die hier leider die falsche ist, geht der nächste und jeder weitere Reboot gnadenlos baden.


    Es gibt jedoch einen Weg, diese virtuellen Devices loszuwerden. Den BMC selber. Der sich entweder im BIOS irgendwo mit (veränderbarer) fester oder DHCP-Adresse finden lässt, oder im Router/DHCP-Server als unbekannte zugewiesene IP-Adresse. Mit dem Login "admin/admin" kommt man zumindest bei einem ASMB7 ins Web-GUI und kann dort unter Configuration/Services die xx-media-Einstellungen inaktivieren. Mit dem Erfolg, dass beim nächsten Versuch einer OMV-Installation die zugewiesene Festplatte auf /dev/sda bzw., bei Installation von ein USB-Stick, auf /dev/sdb rückt, und damit alle normalen Regeln greifen.


    Offenbar hatte der Vorbesitzer des Motherboards, das ich für meinen Playground OMV verwendetete, die Inaktivierung der AMI Virtual Devices schon selber vorgenommen. Jedenfalls hatte ich mir dem Motherboard keine OMV/Debian-Intallationssprobleme.


    Gruß
    Der Jopa

    Hi,
    if I guess right (from tags), and you are trying out BTRFS RAID5, then the web GUI is not really helpful. Maybe you can still add another drive to the pool by web GUI - which on my playground NAS did not work -, but then you need to go to console and balance the pool by a btrfs CLI command:


    btrfs balance start -v /srv/dev-disk-by-label-<your btrfs pool>/


    and wait for some (more) hours depending on size of disk added and pool usage.


    And then, never-ever change disks order or unplug one for testing a failure. You may get the shares of the RAID working or not, but you will not get the btrfs be shown correctly in omv web GUI again. GUI will show it "unmounted", and so not show the usage. Also you will not get "Unmount" offered, and unmounting by CLI command and mounting newly from web GUI will not change anything.


    BTW: On Omv console, BTRFS RAID5 is declared "experimetal" at detection...

    Hallo Volker,


    Danke erstmal für den Hinweis. Im Gegenzug mein Hinweis, dass ich besagte Textänderung nicht aufgrund irgendeines Plugins fand, sondern, wie ich es mir zusammenreime, aufgrund des Kernel-Moduls für meinen LSI-HBA. Denn vorher hatte ich noch nichts sonst installiert.


    Interessant nichts desto weniger.


    Gruß

    Thanks for reply and sry for delay - I just needed to keep the other drives as they were. Astonishing enough, althoug I set booting to sda in grub, the system sdd was changed to the last of sd found, i.e. sde in this case. Please don't ask me why :)

    So what was the solution?

    Don't know, what was mgjsmith's solution, but for me, who I had the same problem, it was this I found by another search.
    Though I'm still not familiar with linux boot loaders, in this case grub2, I know enough about BIOS to say, that it just boots from the first device it finds bootable and may fall back to efi shell or to boot-from-ethernet, if no bootable device can be found. The"BIOS boot order and everything else" will not change anything, if you already got any grub of BusyBox messages.


    For me the whole seems to be a common problem with grub installer, when installing omv (or debian in general?) from an UUI USB stick rather than from a real CD. Because the USB stick will be taken as an "sd" device by intstaller and grub, typically as "sda", and installation takes the device to install on as "sdb". And then grub, though it uses UUID for finding the real boot device, but not completely, after removing the stick, runs into error.



    Sorry, if it sounds confusing, for me it is as well. But that's, what I found out ;)

    Think, I digged down the issue. After I used a H61 motherboard plus a Marvell 88SE9230 based SATA controller in the past, I moved to a H67 board today, which has enough SATA slots onboard, that I don't need the extra controller no more. And voila - the deep drops on network speed are gone.


    Looks like the Marvell chip was the bottleneck here, and not the SMB handler. Thanks for help anyway.


    Best regards,
    Johannes

    Hi reycoaaron,


    thanks for reply, even if it could not help. But good to read, that you don't use tunning - which is my favorite, too :)


    For the moment, I'll swap back to omv3 and let my backups run as known, but when I have some time to waist again, I'll try out another mobo/CPU, in particular the H87/Haswell or the H110/Skylake combo, that I have laying around.


    Best regards,
    Johannes

    Hi ryecoaaron,


    on yesterday I tried all extra parameters from first thread (except for log level), separately and together. I also tried couple of other parameters, which I thougt useful (e.g. aio..), but no significant change. Omv4's performance still is about 15% behind omv3's.


    At least re the collaps I found out, that it is that cruel only the first time after a (re)boot, lateron speed drops down to 10-20MBps "only"...


    And this all is with a single (windows 8) client on the other side of LAN cable.


    Best regards,
    Johannes