kern/38095: Regression with MSDOSFS in 4.0

[rhialto%falu.nl@localhost]

>Number:         38095
>Category:       kern
>Synopsis:       Regression with MSDOSFS in 4.0
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Feb 23 23:10:00 +0000 2008
>Originator:     Rhialto
>Release:        NetBSD 4.0
>Organization:
        
>Environment:
System: NetBSD loelappie.falu.nl 4.0 NetBSD 4.0 (LOELAPPIE4.0) #1: Sun Jan 13 
17:56:39 CET 2008  
root%loelappie.falu.nl@localhost:/usr/src/sys/arch/i386/compile/LOELAPPIE4.0 
i386
Architecture: i386
Machine: i386
>Description:

For the first time since I installed 4.0 on my laptop I have the
occasion to use msdosfs and copy some large files to it.

I notice a regression: sequential write to a file gets slower as the
file gets longer. This was previously fixed with a patch in my
pr kern/34583
http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=34583 .

The code from the patch is actually present in the kernel, I checked
that. The problem is likely a change in the write-order of the write
cache. An earlier change like that had rendered the then-existing
caching of FAT entries ineffective, and I strongly suspect the same
thing has happened again.

I can actually hear the disk seeking longer and longer distances
as the file grows, indicating it needs to look up the FAT again and
again as it writes the file data.

Can someone who actually knows something about the write-back order
shine some light on this?

>How-To-Repeat:

See above.

>Fix:
        None known. This should be fixed once and for all, i.e. with
        something better than a cache covering the last N clusters of
        the file with N increasing in each next "fix".

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert      -- You author it, and I'll reader it.
\X/ rhialto/at/xs4all.nl        -- Cetero censeo "authored" delendum esse.