NetBSD Problem Report #38095

From rhialto@falu.nl  Sat Feb 23 23:06:56 2008
Return-Path: <rhialto@falu.nl>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id 8858563B8A2
	for <gnats-bugs@gnats.NetBSD.org>; Sat, 23 Feb 2008 23:06:56 +0000 (UTC)
Message-Id: <200802232306.m1NN6qem007464@radl.falu.nl>
Date: Sun, 24 Feb 2008 00:06:52 +0100 (CET)
From: rhialto@falu.nl
Reply-To: rhialto@falu.nl
To: gnats-bugs@gnats.NetBSD.org
Cc: rhialto@falu.nl
Subject: Regression with MSDOSFS in 4.0
X-Send-Pr-Version: 3.95

>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:/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.

Home	PR Database Search