On Tue, 07 May 2013 23:58:08 +0200, Kai Krakow wrote: > Gabriel de Perthuis <g2p.c...@gmail.com> schrieb: >>> On the side note: dm-cache, which is already in-kernel, do not need to >>> reformat backing storage. >> >> On the other hand dm-cache is somewhat complex to assemble, and letting >> the system automount the unsynchronised backing device is a recipe for >> data loss. > > Yes, that was my first impression, too, after reading of how it works. How > safe is bcache on that matter?
The bcache superblock is there just to prevent the naked backing device from becoming available. So it's safe in that respect. LVM has something similar with hidden volumes. >> Anyway, here's a shameless plug for a tool that converts to bcache >> in-place: https://github.com/g2p/blocks#bcache-conversion > > Did I say: I love your shameless plugs? ;-) > > I've read the docs for this tool with interest. Still I do not feel very > comfortable with converting my storage for some unknown outcome. Sure, I can > take backups (and by any means: I will). But it takes time: backup, try, > restore, try again, maybe restore... I don't want to find out that it was > all useless because it's just not ready to boot a multi-device btrfs through > dracut. So you see, the point is: Will that work? I didn't see any docs > answering my questions. Try it with a throwaway filesystem inside a VM. The bcache list will appreciate the feedback on Dracut, even if you don't make the switch for real. > Of course, if it would work I'd happily contribute documentation to your > project. That would be very welcome. -- 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
