kern/110431: Access time corruption on UFS2 with a 3ware 7506-4LP running FreeBSD 6.1 with samba and nfsd.

Jacob Mahoney root at
Sat Mar 17 09:19:46 UTC 2007

Mr. Grundy,
It is possible a few more specific details might shed some light onto 
the subject.
Are the files being stored on an array hosted by this card?
How old are the drives connected to this card?
Samba and nfsd are mentioned.  Are both running on the same server or is 
there a translation server somewhere in the mix?
Try creating a few test files.  Then modify them locally.  If not, try 
modifying the files from a Samba client and an NFS client.  Perhaps run 
the client tests from two scenarios - same machine for both protocols 
(if possible, generally, it is), and different machines for each 
protocol.  Be creative and experiment with the issue until you get it to 
come up consistently.

It appears to be random, and users tend to access and modify their files 
in a somewhat (or obvious) random order, which might explain why the 
issue comes up randomly.  If you have already tried all the tests and 
the issue has still not come up consistently, then try using only one 
type of client (NFS, Samba, or local) until the issue does come up.  
This will help in pinpointing where the fault lies.


Harrison Grundy wrote:
>> Number:         110431
>> Category:       kern
>> Synopsis:       Access time corruption on UFS2 with a 3ware 7506-4LP running FreeBSD 6.1 with samba and nfsd.
>> Confidential:   no
>> Severity:       serious
>> Priority:       medium
>> Responsible:    freebsd-bugs
>> State:          open
>> Quarter:        
>> Keywords:       
>> Date-Required:
>> Class:          sw-bug
>> Submitter-Id:   current-users
>> Arrival-Date:   Sat Mar 17 08:30:02 GMT 2007
>> Closed-Date:
>> Last-Modified:
>> Originator:     Harrison Grundy
>> Release:        6.1-RELEASE
>> Organization:
>> Environment:
> FreeBSD  6.1-RELEASE FreeBSD 6.1-RELEASE #1: Tue Jan  9 21:58:29 UTC 2007     root at  amd64
>> Description:
> ls -l shows the following for files, which cannot be backed up by tar, unless they are `touch`ed first.
> -rwxr--r--  1 nobody  wheel   918M May 28  60056 seismic0001000.1
> Most files have the correct output of:
> -rwxr--r--  1 nobody  wheel   918M Mar 17 07:12 seismic0001100.1
> -rwxr--r--  1 nobody  wheel   2.3K Jun 21  2006 seismic0001100.sdd
> -rwxr--r--  1 nobody  wheel   1.5M Dec 14 08:25 seismic0001300.knx
>> How-To-Repeat:
> I have been unable to recreate this problem with any regularity, but it appears to occur somewhat at random, to very few files over time. I will post a followup, when and if I am able to recreate the problem on demand.
>> Fix:
>> Release-Note:
>> Audit-Trail:
>> Unformatted:
> _______________________________________________
> freebsd-bugs at mailing list
> To unsubscribe, send any mail to "freebsd-bugs-unsubscribe at"

More information about the freebsd-bugs mailing list