-
Posts
10,192 -
Joined
-
Last visited
-
Days Won
196
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Report Comments posted by limetech
-
-
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".
-
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?
-
The 'tss' user and group does not exist. Must be something recently added to libvirt/qemu. We'll keep an eye on it.
- 1
- 1
-
Changed Priority to Minor
-
Changed Status to Open
Changed Priority to Annoyance
-
Changed Status to Retest
-
Kernel updated but nothing obviously patched that would explain this. We did add more instrumentation into FUSE, would appreciate a retest and repost of diagnostics.zip upon failure.
-
Kernel updated but nothing obviously patched that would explain this. We did add more instrumentation into FUSE, would appreciate a retest and repost of diagnostics.zip upon failure.
-
Changed Status to Retest
-
Changed Status to Retest
-
Changed Status to Open
Changed Priority to Annoyance
-
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.
-
I know we say this all the time, and most of the time it doesn't make a difference, but sometimes it does: please try a Safe-mode boot and see if issue persists.
-
7 hours ago, 11rcombs said:
Ping on this.
It's not slipping through cracks but will not be included in any 6.6.x release.
-
Changed Status to Closed
Changed Priority to Other
-
Changed Status to Retest
Changed Priority to Other
-
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
- 1
- 1
-
Changed Status to Closed
Changed Priority to Other
-
Changed Status to Closed
Changed Priority to Other
-
26 minutes ago, johnnie.black said:
I'm guessing it's based on the metadata, metadata keeps record of the current generation, so it knows which one is the newer, mailing disk discussion is this one:
https://www.mail-archive.com/[email protected]/msg78254.html
The idiocy being displayed in that thread is mind boggling.
-
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?
-
58 minutes ago, johnnie.black said:
it was recently discussed in the mailing list
Sure I'm aware of limitation that NODATACOW also disables checksums, but more interested in how a pool member can go "offline" and then magically go back "online" - wasn't aware btrfs does this.
-
9 hours ago, johnnie.black said:
when a devices drops offline and then re-joins the pool
How is this possible?
-
Changed Status to Closed
Changed Priority to Other
6.6.1 Crashes
in Stable Releases
Posted
Install the latest release and see if the kernel crash occurs again.