covici posted on Sat, 26 Dec 2015 02:29:11 -0500 as excerpted: > Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > >> If you can post the entire dmesg somewhere that'd be useful. MUAs tend >> to wrap that text and make it unreadable on list. I think the problems >> with your volume happened before the messages, but it's hard to say. >> Also, a generation of nearly 5000 is not that new? > > The file system was only a few days old. It was on an lvm volume group > which consisted of two ssd drives, so I am not sure what you are saying > about lvm cache -- how could I do anything different? > >> On another thread someone said you probably need to specify the device >> to mount when using Btrfs and lvmcache? And the device to specify is >> the combined HDD+SSD logical device, for lvmcache that's the "cache >> LV", which is the OriginLV + CachePoolLV. If Btrfs decides to mount the >> origin, it can result in corruption. > > See above. I think he mixed up two threads and thought you were running lvm-cache, not just regular lvm, which should be good unless you're exposing lvm snapshots and thus letting btrfs see multiple supposed UUIDs that aren't actually universal. Since btrfs is multi-device and uses the UUID to track which devices belong to it (because they're _supposed_ to be universally unique, it's even in the _name_!), if it sees the same UUID it'll consider it part of the same filesystem, thus potentially causing corruption if it's a snapshot or something that's not actually supposed to be part of the (current) filesystem. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
