On Dec 29, 2013, at 2:11 PM, Kai Krakow <hurikhan77+bt...@gmail.com> wrote:
> > * How stable is it? I've read about some csum errors lately… Seems like bcache devs are still looking into the recent btrfs csum issues. > > * I want to migrate my current storage to bcache without replaying a backup. > Is it possible? > > * Did others already use it? What is the perceived performance for desktop > workloads in comparision to not using bcache? > > * How well does bcache handle power outages? Btrfs does handle them very > well since many months. > > * How well does it play with dracut as initrd? Is it as simple as telling it > the new device nodes or is there something complicate to configure? > > * How does bcache handle a failing SSD when it starts to wear out in a few > years? I think most of these questions are better suited for the bcache list. I think there are still many uncertainties about the behavior of SSDs during power failures when they aren't explicitly designed with power failure protection in mind. At best I'd hope for a rollback involving data loss, but hopefully not a corrupt file system. I'd rather lose the last minute of data supposedly written to the drive, than have to do a fuil restore from backup. > > * Is it worth waiting for hot-relocation support in btrfs to natively use > a SSD as cache? I haven't read anything about it. Don't see it listed in project ideas. > > * Would you recommend going with a bigger/smaller SSD? I'm planning to use > only 75% of it for bcache so wear-leveling can work better, maybe use > another part of it for hibernation (suspend to disk). I think that depends greatly on workload. If you're writing or reading a lot of disparate files, or a lot of small file random writes (mail server), I'd go bigger. By default sequential IO isn't cached. So I think you can get a big boost in responsiveness with a relatively small bcache size. Chris Murphy-- 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
