wear-levelling for files which are constantly being written to?

[Jörn Engel]

On Thu, 27 March 2008 13:13:31 +0100, Tomasz Chmielewski wrote:
> 
> I have a server with its ext3-formatted rootfs on a flash disk.
> 
> The server has a RAID-5 array. That RAID-5 array had an internal bitmap 
> (which is not relevant for this list), but as it was harming the 
> performance a lot, I decided to move the bitmap to the flash disk.
> 
> Unfortunately, after a month or so the flash disk was showing I/O 
> errors: badblocks found about 200 badblocks, the bitmap file was 
> unreadable (I/O error).
> 
> So I removed the bitmap from flash, filled the flash disk with /dev/zero 
> contents - there are not badblocks anymore (remapped, perhaps).
> 
> 
> Now, why these badblocks happened?

[...]

> 2. The bitmap file was constantly written to the same area of flash disk 
> all the time (ext3 on a flash disk), which died in that place eventually.

Close.  One of the problems that haunt flash memory is "write disturb".
Writes to block N have a low chance of flipping bits in other blocks
nearby.  My guess is that you have hit this problem.  When part of the
flash is written quite frequently, the low chance adds up to certain
bitflips, initially correctable ones, later uncorrectable.

> If answer 2 is correct, would logfs spread file updates over the whole 
> area of the disk?

Yes.  That removes the hot spots.  It will also move data from block
that haven't been written for a while, removing any accumulated
bitflips.

If the flash disk was any good, it should do something similar itself.
But many (most?) aren't and there is no easy way to tell the good ones
from the bad ones.  Ext3 is known to cause problems on a flash disk and
it is a fair assumption that most journaling filesystems will.

Jörn

-- 
Linux is more the core point of a concept that surrounds "open source"
which, in turn, is based on a false concept. This concept is that
people actually want to look at source code.
-- Rob Enderle