From owner-freebsd-fs@FreeBSD.ORG Sun Oct 7 21:02:05 2007 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA81916A417 for ; Sun, 7 Oct 2007 21:02:05 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 951EF13C448 for ; Sun, 7 Oct 2007 21:02:05 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id E9B0917105; Sun, 7 Oct 2007 20:37:50 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l97KbmHb020194; Sun, 7 Oct 2007 20:37:49 GMT (envelope-from phk@critter.freebsd.dk) To: Bruce Evans From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 08 Oct 2007 06:07:36 +1000." <20071008051733.T29782@delplex.bde.org> Date: Sun, 07 Oct 2007 20:37:48 +0000 Message-ID: <20193.1191789468@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-fs@FreeBSD.org Subject: Re: Very slow writes on flash + msdosfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2007 21:02:05 -0000 One of the reasons that writes to flash can be extremely slow is that the built in wear-leveling gets overwhelmed. There is a specification somewhere, that explains to camera manufacturers how exactly they should perform the writes to flash media to get maximum writing speed. Unfortunately many flash producers think that is the only thing you can use flash devices for, and their wear-leveling support only this write mode. M-Systems had a patent on monitoring the free cluster map of the fat filesystem from the wear-leveling code, but I don't know how wide-spread that has become yet. Sandisk bought M-Systems some years ago, so I bet they have it. There exists ATA/whatever commands to tell a flash device that a given range of sectors can be reclaimed by the wear-leveling code, but we do not issue these when we delete files. As a result, the wearleveling ready-pool is rapidly depleted, forcing all sector writes to perform a block evacuation, erase and rewrite. The BIO_DELETE request was intended to give us support for this, unfortunately, flash vendors are not at all willing to officially support the interface and thus it never truly got implemented. The slow write speed also indicates that you are wearing your flash devices out up in 1% of the time they should last. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.