I get frequent (for servers) lockups and crashes when using 2.6.39. I saw the same problems using 3.0.0rc5, 5 and 6, and I think also 2.6.38. I don't see this lockups on 2.6.30 or 2.6.26 (all the res
Tainted kernel. Please reproduce without the NVidia binary drivers. and when you do, please record an event trace of the xfs_swap_extent* trace points while xfs_fsr is running and triggers a crash. T
On Sun, Aug 07, 2011 at 12:20:05AM +1000, Dave Chinner <david@xxxxxxxxxxxxx> wrote: This is just because it is form my desktop system. None of my other machines have a tainted kernel, but getting bac
Use trace-cmd or do it manually via: Defensive? Sure - to protect -your systems- from further corruption problems until we know what the problem is. To use a car analogy: I know the brakes on your ca
On Sun, Aug 07, 2011 at 08:26:25PM +1000, Dave Chinner <david@xxxxxxxxxxxxx> wrote: Thanks, I'll have a look at enabling this with a regular xfs_fsr on a few machines. To take your car analogy - if I
This just in, this was on screen, xfs_fsr was active at the time, kernel is tainted: [248359.646330] CPU 1 [248359.646326] last sysfs file: /sys/devices/virtual/net/lo/operstate [248359.646323] Oops:
Author: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>
Date: Tue, 9 Aug 2011 12:10:48 +0200
First of all, please calm down. Getting personal is not bringing us anywhere. [snip] No, it's not a kernel bug because as long as you don't use xfs_fsr, nothing will ever happen. And the rest of the
Well, it's not me who's getting personal, so...? "As long as you don't boot, it will not crash". xfs_fsr uses syscalls, just like other applications. According to your (wrong) logic, if an applicatio
And the event trace to go along with the xfs-fsr run? I don't need to know the dmesg output - I need the information in the event trace from the xfs-fsr run when the problem occurs.... Cheers, Dave.
It wasn't enabled yet, I didn't expect it to lock up so soon, but even if, we would have to wait for those rare occurances where the kernel oopses without the box locking up (can take months). And I
They tell me where the crash occurred - they don't tell me the root cause of the problem. Understanding the root cause and fixing that is more important that putting a bandaid over the resultant pani
Author: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>
Date: Wed, 10 Aug 2011 08:59:26 +0200
A single rant from a dev shouldn't hurt one too much. He might have been sitting in front of some code during 72 hours, his eyes already being in 16:9 format staring at a weird bug... It's OK to stri
Seeing you keep stating this is a problem, I'll ask again whether commit 778e24b ("xfs: reset inode per-lifetime state when recycling it") fixed this problem for you? Cheers, Dave. -- Dave Chinner da
The NFS server apparently opens and closes files very often (probably on every read/write or so, I don't know the details), so XFS was benchmark-improved by keeping the preallocation as long as the i
On Thu, Aug 11, 2011 at 12:16:19AM +1000, Dave Chinner <david@xxxxxxxxxxxxx> wrote: I can only go by what _you_ told me earlier, namely that this works as designed and no change is needed. If you cha
It only does that if the pattern of writes are such that keeping the preallocation around for longer periods of time will reduce potential fragmentation. Indeed, it's not a NFS specific optimisation,
On Fri, Aug 12, 2011 at 02:05:30PM +1000, Dave Chinner <david@xxxxxxxxxxxxx> wrote: That can only be false. Here is a an example that I saw *just now*: I have a process that takes a directory with jp
That's the case of the unlinked inode being reused immediately and no having all it's state cleared correctly when recycled. That's the problem that was diagnosed and fixed when you reported the firs