Hi,
While this sounds nice in practice, in reality since eraseblocks are
generally very large, and with hardware based block remapping (FTL), you can
never be sure which data blocks are at risk when re-writing just one block.
There is a good chance that rewriting one block of data somewhere will wipe
out a block of data at a totally different location of the disk.
Since the filesystem has no understanding of the hardware FTL, there isn't
much that can be done about this at the filesystem level.
The only thing that could be done is metadata mirroring on the same disk,
but I suspect even that would only marginally improve reliability, since
both copies of the metadata are likely to be written to storage at nearly
the same time, they are quite likely to be re-mapped into the same block,
and then if you loose one, you loose both.
The solution to this is twofold:
1 :- filesystems should be able to detect when a non-atomic write has
corrupted the filesystem and tell the user - eg. "Filesystem corruption
found, Likley hardware malfunction detected" (since with a fs like btrfs,
when all big software bugs are resolved, the only thing that can cause disk
corruption are hardware issues)
2 :- Someone who feels this is close to their heart needs to test every big
brand of SSD and name and shame those where writes are non-atomic - as soon
as you get this publicised that certain brands of SSD put data at risk, the
manufacturer will be very fast at resolving it.
----- Original Message -----
From: "Seth Huang" <seth...@gmail.com>
To: <linux-btrfs@vger.kernel.org>
Sent: Monday, February 23, 2009 3:17 AM
Subject: Re: ssd optimised mode
On Mon, Feb 23, 2009 at 12:22 PM, Dongjun Shin <djshi...@gmail.com> wrote:
A well-designed SSD should survive power cycling and should provide
atomicity
of flush operation regardless of the underlying flash operations. I don't
expect
that users of SSD have different requirements about atomicity.
A reliable system should be based on the assumption that the underlying
parts are unreliable. Therefore, we should do as much as possible to make
sure the reliability in our filesystem instead of leaning on the SSDs.
--
Seth Huang
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
