Samba and spinlocks on Linux (was Re: REPOST: Meaning of tdb_free:left read failed at ...?
On Tue, 04 Feb 2003 11:00:24 +0100, Volker Lendecke wrote: On Tue, Feb 04, 2003 at 10:17:34AM +0100, Ralf G. R. Bergs wrote: Ok, now /var/run/samba is an ext3 filesystem -- and the problem is back again. :-( Thanks nevertheless. As one resort, could you try use mmap = no I guess I should have defined CONFIG_RWSEM_GENERIC_SPINLOCK when compiling my kernel since I also configured Samba with --with-spinlocks: [2003/02/05 09:06:01, 0] tdb/tdbutil.c:tdb_log(531) tdb(/var/run/samba/messages.tdb): tdb_open_ex: failed to clear spinlock [2003/02/05 09:06:01, 0] lib/messages.c:message_init(112) ERROR: Failed to initialise messages database Would you recommend that I recompile the kernel to enable spinlock support (since this is a two-way SMP machine), or would you rather recommend that I don't use spinlocks (i.e. recompile Samba NOT to try to use spinlocks)? Thanks! -- L I N U X .~. The Choice /V\ of a GNU /( )\ Generation ^^-^^
Re: REPOST: Meaning of tdb_free: left read failed at ...?
On Tue, 04 Feb 2003 19:34:16 -0600 (CST), Gerald (Jerry) Carter wrote: On Tue, 4 Feb 2003, Ralf G. R. Bergs wrote: What exactly does that mean? I compiled Samba with large file support. Was this an error? I absolutely NEED large-file support. (To recap, this is under Debian/GNU Linux/i386 3.0, running kernel 2.4.20.) tdb's can only be 4Gb. It's not a 64-bit database. This has nothing to do with Samba's support for transfering 64-bit files. Why is the unexpected.tdb growing that fast? I'm not sure whether I understand you correctly. The above file, unexpected.tdb, is NOT larger than 4G in size, it's just a few K! Could you elaborate, please? Thanks. -- L I N U X .~. The Choice /V\ of a GNU /( )\ Generation ^^-^^
Re: Samba and spinlocks on Linux (was Re: REPOST: Meaning oftdb_free: left read failed at ...?
On Wed, 05 Feb 2003 11:50:50 +0100, Volker Lendecke wrote: [...] you do not have a *very* good reason to enable them, could you please retry without spinlocks? Ok, I'm just recompiling Samba without spinlock support. Obviously I have to wait until this night so that the fileserver becomes less loaded to replace Samba. I will get back to you until I can report whether the (original) problem went away. Thanks, Ralf -- L I N U X .~. The Choice /V\ of a GNU /( )\ Generation ^^-^^
Re: REPOST: Meaning of tdb_free: left read failed at ...?
On Mon, 03 Feb 2003 17:20:26 -0600 (CST), Gerald (Jerry) Carter wrote: [...] Looks like the tdb went over the 4Gb line. As a quick work around, Stop nmbd; rm /var/run/samba/unexpected.tdb; and start nmbd back up. No, this has never been a work-around. The problem comes up again VERY quickly. It looks like an overflow in the tdb read offset. I don't think tdb's support 64-bit file size (of the actual tdb itself) IIRC. This is by design I believe. What exactly does that mean? I compiled Samba with large file support. Was this an error? I absolutely NEED large-file support. (To recap, this is under Debian/GNU Linux/i386 3.0, running kernel 2.4.20.) Thanks, Ralf -- L I N U X .~. The Choice /V\ of a GNU /( )\ Generation ^^-^^
Re: REPOST: Meaning of tdb_free: left read failed at ...?
On Sun, 02 Feb 2003 15:44:18 +0100, Simo Sorce wrote: The system in question is a Debian i386 stable (3.0) system, kernel is 2.4.20 release (with some patches such as EVMS and XFS, but EVMS is NOT in use for shares exported via Samba!!), Samba is 2.2.7a (a Debian package that I created myself.) I would try again with a standard ext2/3 file system. Ok, now /var/run/samba is an ext3 filesystem -- and the problem is back again. :-( So you could argue, Ok, it's EVMS then which is the culprit, because filesystem is on an EVMS logical volume. But I simply cannot believe this. Why should Samba be the ONLY (apparent) application that doesn't feel happy with XFS over EVMS? Any thoughts? -- L I N U X .~. The Choice /V\ of a GNU /( )\ Generation ^^-^^
Re: REPOST: Meaning of tdb_free: left read failed at ...?
On Tue, 04 Feb 2003 09:37:17 -0600, Steve Langasek wrote: [...] Why should Samba be the ONLY (apparent) application that doesn't feel hap= py with=20 XFS over EVMS? I'm running Samba on XFS+EVMS (on Debian ;) with no problems. Even on buggy versions of XFS, I've never seen this error; I don't think the filesystem is the cause. OTOH, I haven't used 2.4.20 yet for this environment. As I wrote earlier I also can't believe it's a filesystem issue. When you say you compiled with large file support, does that mean you made changes to the build scripts? Samba should already build with LFS support on Linux 2.4. Yup, I had to change the build scripts. If I remember correctly the Debian package comes with shrink-wrapped configure.cache files so that they would always overwrite certain changes I made to the configure statement inside debian/rules. I think that there was a already a bug filed against the non-support of large files. The poster of this bug report also mentioned that you had to recompile it in order to get LFS. OTOH everything I just wrote could be wrong. I'm currently working on a multitude of building areas so I could confuse something with something totally different. :-) -- L I N U X .~. The Choice /V\ of a GNU /( )\ Generation ^^-^^
Re: REPOST: Meaning of tdb_free: left read failed at ...?
On Sun, 02 Feb 2003 15:44:18 +0100, Simo Sorce wrote: On Sun, 2003-02-02 at 15:58, Ralf G. R. Bergs wrote: On Sun, 02 Feb 2003 14:47:11 +0100, Simo Sorce wrote: you can try to delete unexpected.tdb it does not hold any vital information. The problem has reappeared even after I removed the above file: Feb 2 11:18:29 Fileserver nmbd[22451]: [2003/02/02 11:18:29, 0] tdb/tdbutil.c:tdb_log(531) Feb 2 11:18:29 Fileserver nmbd[22451]: tdb (/var/run/samba/unexpected.tdb): tdb_oob len -2320 beyond eof at 24576 Feb 2 11:18:29 Fileserver nmbd[22451]: [2003/02/02 11:18:29, 0] tdb/tdbutil.c:tdb_log(531) Feb 2 11:18:29 Fileserver nmbd[22451]: tdb (/var/run/samba/unexpected.tdb): tdb_free: left read failed at 4294964952 (4096) [...] do they reside on an nfs mount? or any other alternative filesystem? They? Does what reside on an NFS mount? sorry I mean the tdb files. Weell, the TDB files (/var/run/samba) DO reside on an alternative filesystem in your words: They're on an XFS filesystem that itself resides on an EVMS logical volume that itself resides on a RAID-5 region. :-) But the thing is that the system otherwise seems to run extremely well -- I don't see ANY other suspicious log entries. [...] The system in question is a Debian i386 stable (3.0) system, kernel is 2.4.20 release (with some patches such as EVMS and XFS, but EVMS is NOT in use for shares exported via Samba!!), Samba is 2.2.7a (a Debian package that I created myself.) I would try again with a standard ext2/3 file system. Just compile and install all samba related file under a well tested file system like ext2/3, I have had no problem with XFS, but 2.4.20 may have broke something subtle, who knows? This is just not possible. The system we're talking about is a production fileserver for some hundred or so users. I can't change the partitioning scheme, nor can I change the filesystem used. Shouldn't we rather try to isolate and fix the problem, rather than working around it? Thanks, Ralf -- L I N U X .~. The Choice /V\ of a GNU /( )\ Generation ^^-^^
Meaning of tdb_free: left read failed at ...?
Hi there, since I upgraded our fileserver running Debian 3.0/i386 with Samba 2.2.7a (a package I created myself) I'm seeing the following messages in syslog: Jan 28 14:55:50 Fileserver nmbd[22451]: [2003/01/28 14:55:50, 0] tdb/tdbutil.c:tdb_log(531) Jan 28 14:55:50 Fileserver nmbd[22451]: tdb(/var/run/samba/unexpected.tdb): tdb_oob len -2320 beyond eof at 16384 Jan 28 14:55:50 Fileserver nmbd[22451]: [2003/01/28 14:55:50, 0] tdb/tdbutil.c:tdb_log(531) Jan 28 14:55:50 Fileserver nmbd[22451]: tdb(/var/run/samba/unexpected.tdb): tdb_free: left read failed at 4294964952 (4096) I've already searched Google, but to no avail. Is this something to worry about? Can I stop these messages (or rather the cause of those messages)? Or should I just filter them away? Thanks, Ralf -- L I N U X .~. The Choice /V\ of a GNU /( )\ Generation ^^-^^
