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.
Weeeeeell, 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 ^^-^^