[OpenAFS] Re: File corruption, 1.4.1 & 1.4.4 on linux clients

[Derrick J Brashear]

On Thu, 26 Apr 2007 cball@bu.edu wrote:

> On Wed, 25 Apr 2007, Derrick J Brashear wrote:
>
>> On Tue, 24 Apr 2007 cball@bu.edu wrote:
>>
>>> We are serving up a virus .dat file to mail relays via AFS readonly.
>>> The file is periodically updated, the volume where it lives is re-released
>>> hourly whether update occured or not.  Read activity is constant.
>>>
>>> When vos release occurs, the fileserver logs a message like this:
>>>
>>> Mon Apr 23 17:04:28 2007 fssync: volume 536959020 restored; breaking all
>>> call backs
>>>
>>> [ normal behavior ]
>>>
>>> At erratic intervals, the virus scanner on one of our mail relay systems
>>> will choke on the database file reporting that it's invalid.  When this
>>> happens, the file remains invalid until a re-release occurs or a manual fs
>>> flush is invoked.
>>
>> Let me guess, it's mmap()ed by whatever is using it, directly in /afs?
>
> The file is not being mmap()ed.  If I wasn't clear, the affected client
> system is consistant about serving up the corrupted file with null bytes
> to new and old processes until the cached version of the file is flushed.

If it were mmap()ed there is a way the file can basically get pinned due 
to the dentry cache in 1.4.1, at least if i recall the specifics.