Jump to content

limetech

Administrators
  • Posts

    10,192
  • Joined

  • Last visited

  • Days Won

    196

Report Comments posted by limetech

  1. 1 hour ago, rjstott said:

    So I see that a new relaease has *hit the fan and there are *NO* warnings about known problems.

    Have you seen the bug list?  There are plenty of "known issues" for which underlying cause and possible fix are "unknown".

  2. 1 hour ago, rjstott said:

    So I see that a new relaease has *hit the fan and there are *NO* warnings about known problems. Sorry guys I just don't get this mentality of leading users onto broken systems. It just looks like a 'Microsoft' trick? Am I the only one that has been burned? If there are other people that agree with my view could I get some support and only then things might get better!

    There were several Realtek patches in the linux kernel for 6.6.2 vs 6.6.1, does your Realtek NIC still not work?

  3. Thank you for your testing and bringing this to my attention.  To elaborate: what I'm doing is adding code in 'shfs' that keeps track of files opened via shfs for both normal i/o and 'mover'.  If a file being moved gets opened, the move will get cancelled, the partial target file deleted, and the original source file opened (thus being skipped in this move cycle).  There are some caveats which will apply, for example, if a file is opened outside 'shfs' (like via disk share), the mover will not be able to detect this.

     

    Collectively these changes need to undergo a beta process and then prerelease, hence will not get into current bug fixing with 6.6.x.

  4. FWIW we run latest software on all our servers.  I'm writing this from a Windows 10 VM running on Unraid OS host running upcoming 6.6.2.  Using Supermicro X10SRM-F with Xeon E5-1650 v4.  I have a triple monitor setup and routinely back up to an Atom-based Unraid server.  Never a single crash like are being described in these bug reports.  Can't even get NFS to fail.  I will admit we avoid Realtek.  Eric has a Threadripper, again, no crashes.

     

    Of course we try and put out a quality product that also keeps up-to-date with bleeding edge of almost all components such as the kernel.  This is necessary to continue to support the latest h/w.

     

    Sorry your server is crashing for some unknown reason, but there are many many servers out there that are not crashing.

     

    In these situations where you think it might crash and you can't get meaningful diags, you can have a log window open which might capture the last bits of messages before crash.  You can also open a telnet/ssh session and be tailing the syslog:

     

    tail -f /var/log/syslog

    • Like 1
    • Upvote 1
  5. 23 minutes ago, johnnie.black said:

    It happens frequently, like in the case above, I see it almost every week on various diagnostics, one device drops offline, usually from a bad cable, on the next reboot it comes back online, and the pool continues to work without apparent problems since any checksum errors are corrected by the good mirror, but for NODATACOW shares btrfs won't notice and will alternately read from both mirrors since it considers both to have the same data, when in fact they might not, and even running a scrub can't fix anything, since without checksums it will skip those files.

     

    Please post the mailing list link.  If a device comes back "online" and is automatically rejoined to the pool, how does btrfs know which device has the proper checksum?

×
×
  • Create New...