2016-04-05 11:56 GMT-07:00 Austin S. Hemmelgarn <ahferro...@gmail.com>: > On 2016-04-05 14:36, Yauhen Kharuzhy wrote: >> >> 2016-04-05 11:15 GMT-07:00 Austin S. Hemmelgarn <ahferro...@gmail.com>: >>> >>> On 2016-04-05 13:53, Yauhen Kharuzhy wrote:
>>> In general, it isn't allowed, but we don't explicitly disallow it either. >>> The worst case here is that the devices both get written two separately, >>> and >>> you end up with data not matching for correlated generation ID's. The >>> second scrub in this case shows no errors because the first one corrects >>> them (even though they are reported as uncorrectable, which is a bug as >>> far >>> as I can tell), and from what I can tell from reading the code, it does >>> this >>> by just picking the highest generation ID and dropping the data from the >>> lower generation. >> >> >> Hmm... Sounds reasonable but how to detect if filesystem should be >> checked by scrub after mounting? There is one way as I understand — to >> check kernel logs after mount for any btrfs errors and this is not a >> good way for case of some kind of automatic management. > > There really isn't any way that I know of. Personally, I just scrub all my > filesystems shortly after mount, but I also have pretty small filesystems > (the biggest are 64G) on relatively fast storage. In theory, it might be > possible to parse the filesystems before mounting to check the device > generation numbers, but that may be just as expensive as just scrubbing the > filesystem (and you really should be scrubbing somewhat regularly anyway). Yes, size matters — we have 96TB massive and scrubbing, rebalancing, replacing etc. can be expensive operations :) In fact, I implemented some kind of filesystem status reporting in kernel & btrfs progs already but still have no time to prepare this to sending as patches for commenting. But it will be done soon, I hope. -- 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
