On Sat, Dec 26, 2015 at 12:22 PM, <covici@xxxxxxxxxxxxxx> wrote: > Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > >> On Sat, Dec 26, 2015 at 4:38 AM, <covici@xxxxxxxxxxxxxx> wrote: >> > Duncan <1i5t5.duncan@xxxxxxx> wrote: >> > >> >> 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. >> > >> > I found a few more log entries, perhaps these may be helpful to track >> > this down, or maybe prevent the filesystem from going read-only. >> >> No, you need to post the entire dmesg. The "cut here" part is maybe >> useful for a developer diagnosing Btrfs's response to the problem, but >> the problem, or the pre-problem, happened before this. > > It would be a 20meg file, if I were to post the whole file. but I can > tell you, no hardware errors at any time. The kernel is tainted, looks like a proprietary kernel module, so you have to have very good familiarity with the workings of that module to know whether it might affect what's going on, or you'd have to retest without that kernel module. Anyway, asking for the whole dmesg isn't arbitrary, it saves times having to ask for more later. The two things you've provided so far aren't enough, any number of problems could result in those messages. So my suggestion is when people ask for something, provide it or don't provide it, but don't complain about what they're asking for. The output from btrfs-debug-tree might be several hundred MB. The output from btrfs-image might be several GB. So if you're not willing to provide 100kB, let alone 20MB, of kernel messages that might give some hint what's going on, the resistance itself is off putting. It's like having to pull your own loose tooth for you, no one really wants to do that. -- Chris Murphy -- 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
