Am 23.12.2015 um 20:45 schrieb Noah Massey: > On Wed, Dec 23, 2015 at 6:38 AM, Neuer User <auslands...@gmx.de> wrote: > I believe Martin's concern is two-fold: > > The first, major issue, concerns the default writeback cache mode, > which makes the SSD a single point of failure. > (in writeback mode, a write to a block that is cached will go only to > the cache and the block > will be marked dirty in the metadata.) If the SSD fails with dirty > data in the cache which has not been flushed to the backing devices, > the filesystem may be in a unrecoverable state, because writes which > BTRFS was told had succeeded are not present on disk. Ok, I see. Would it help, if the cache were set to writethrough then? In this case the data on the hdds should be always ok, right? (At least as long as the hdds are fine.) > > The second potential issue is that if the SSD performs internal > deduplication, the two copies of cached data (contents on drive 1, > content on drive 2) may actually be a reference to the same bits of > internal storage, meaning a single corruption will affect both cached > copies. If in writeback, then corrupted data could flush down to both > disks. I'm not sure what would happen in writethrough. > Understood. However, do SSDs really do automatic deduplication? I might be completely wrong here, but that sounds to be a rather complex mechanism, requiring lots of RAM to deduplicate 100 GB. I wouldn't have thought that typical SSDs include that?
> ~ Noah > -- > 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
