Re: LOR #193
Kostik Belousov wrote: In a previous (quite old) thread it was in fact suggested I might be seeing some LOR, but only recently I activated all the debugging stuff. The (usual) consequence of the LOR is lock up. Mhh, yes, that's right. But I stopped having locks during file system snapshooting after I upgraded from 5.x to 6.x. What's the risk of running the suggested patch on a (quite critical) production server? It shall be safe unless you run filesystems compiled as modules, that where not built against patched kernel (patch changes the kernel binary interface). Ok, that's not my case. I'll try the patch, but probabily not so soon. bye Thanks av. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
LOR #193
Hello. I'm experiencing the above mentioned LOR on a 6.2p1/amd64 box (running gmirror and SMP if that matters). With reference to your question on http://lists.freebsd.org/pipermail/freebsd-stable/2006-November/031048.html: What application you run that triggers the LOR ? Bacula, I guess. I'm taking filesystem snapshots, running the backup job and deleting the snapshots. In fact I've always seen some problems with some files in the snapshots not being accessible to bacula-fd. In a previous (quite old) thread it was in fact suggested I might be seeing some LOR, but only recently I activated all the debugging stuff. What's the risk of running the suggested patch on a (quite critical) production server? BTW: Sometimes, upon reboot, delayed fscks start and say that the filesystem cannot be fixed with -p and I should run a full fsck. If I reboot in single user mode and run a full fsck, it will find no errors. Also, I have a couple of other boxes on which I run bacula this way and I never experienced this problem: they are respectively i386/gmirror/UP and amd64/hardware RAID/SMP; so, might the combination of amd64/gmirror or gmirror/SMP be in the way? bye Thanks av. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR #193
On Tue, Mar 06, 2007 at 10:44:37PM +0100, Andrea Venturoli wrote: Hello. I'm experiencing the above mentioned LOR on a 6.2p1/amd64 box (running gmirror and SMP if that matters). With reference to your question on http://lists.freebsd.org/pipermail/freebsd-stable/2006-November/031048.html: What application you run that triggers the LOR ? Bacula, I guess. I'm taking filesystem snapshots, running the backup job and deleting the snapshots. In fact I've always seen some problems with some files in the snapshots not being accessible to bacula-fd. In a previous (quite old) thread it was in fact suggested I might be seeing some LOR, but only recently I activated all the debugging stuff. The (usual) consequence of the LOR is lock up. What's the risk of running the suggested patch on a (quite critical) production server? It shall be safe unless you run filesystems compiled as modules, that where not built against patched kernel (patch changes the kernel binary interface). BTW: Sometimes, upon reboot, delayed fscks start and say that the filesystem cannot be fixed with -p and I should run a full fsck. If I reboot in single user mode and run a full fsck, it will find no errors. Also, I have a couple of other boxes on which I run bacula this way and I never experienced this problem: they are respectively i386/gmirror/UP and amd64/hardware RAID/SMP; so, might the combination of amd64/gmirror or gmirror/SMP be in the way? I doubt that gmirror could affect this. pgpZjnA9NT0tl.pgp Description: PGP signature
