Date: Sun, 07 Oct 2007 20:37:48 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Bruce Evans <brde@optusnet.com.au> Cc: freebsd-fs@FreeBSD.org Subject: Re: Very slow writes on flash + msdosfs Message-ID: <20193.1191789468@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 08 Oct 2007 06:07:36 %2B1000." <20071008051733.T29782@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20193.1191789468>