On Tue, Sep 20, 2016 at 2:18 PM, Alexandre Poux <pums...@gmail.com> wrote: > > > Le 20/09/2016 à 21:46, Chris Murphy a écrit : >> On Tue, Sep 20, 2016 at 1:31 PM, Alexandre Poux <pums...@gmail.com> wrote: >>> >>> Le 20/09/2016 à 21:11, Chris Murphy a écrit : >>>> And no backup? Umm, I'd resolve that sooner than anything else. >>> Yeah you are absolutely right, this was a temporary solution which came >>> to be not that temporary. >>> And I regret it already... >> Well on the bright side, if this were LVM or mdadm linear/concat >> array, the whole thing would be toast because any other file system >> would have lost too much fs metadata on the missing device. >> >>>> It >>>> should be true that it'll tolerate a read only mount indefinitely, but >>>> read write? Not sure. This sort of edge case isn't well tested at all >>>> seeing as it required changing the kernel to reduce safe guards. So >>>> all bets are off the whole thing could become unmountable, not even >>>> read only, and then it's a scraping job. >>> I'm not that crazy, I tried the patch inside a virtual machine on >>> virtual drives... >>> And since it's only virtual, it may not work on the real partition... >> Are you sure the virtual setup lacked a CHUNK_ITEM on the missing >> device? That might be what pinned it in that case. > In fact in my virtual setup there was more chunk missing (1 metadata 1 > System and 1 Data). > I will try to do a setup closer to my real one.
Probably the reason why that missing device has no used chunks is because it's so small. Btrfs allocates block groups to devices with the most unallocated space first. Only once the unallocated space is even (approximately) on all devices would it allocate a block group to the small device. -- 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
