On Mar 19, 2014, at 12:09 AM, Marc MERLIN <m...@merlins.org> wrote: > > 7) you can remove a drive from an array, add files, and then if you plug > the drive in, it apparently gets auto sucked in back in the array. > There is no rebuild that happens, you now have an inconsistent array where > one drive is not at the same level than the other ones (I lost all files I > added > after the drive was removed when I added the drive back).
Seems worthy of a dedicated bug report and keeping an eye on in the future, not good. >> >> polgara:/mnt/btrfs_backupcopy# df -h . >> Filesystem Size Used Avail Use% Mounted on >> /dev/mapper/crypt_sdb1 4.1T 3.0M 4.1T 1% /mnt/btrfs_backupcopy > > Let's add one drive >> polgara:/mnt/btrfs_backupcopy# btrfs device add -f /dev/mapper/crypt_sdm1 >> /mnt/btrfs_backupcopy/ >> polgara:/mnt/btrfs_backupcopy# df -h . >> Filesystem Size Used Avail Use% Mounted on >> /dev/mapper/crypt_sdb1 4.6T 3.0M 4.6T 1% /mnt/btrfs_backupcopy > > Oh look it's bigger now. We need to manual rebalance to use the new drive: You don't have to. As soon as you add the additional drive, newly allocated chunks will stripe across all available drives. e.g. 1 GB allocations striped across 3x drives, if I add a 4th drive, initially any additional writes are only to the first three drives but once a new data chunk is allocated it gets striped across 4 drives. > > In other words, btrfs happily added my device that was way behind and gave me > an incomplete fileystem instead of noticing > that sdj1 was behind and giving me a degraded filesystem. > Moral of the story: do not ever re-add a device that got kicked out if you > wrote new data after that, or you will end up with an older version of your > filesystem (on the plus side, it's consistent and apparently without data > corruption. That said, btrfs scrub complained loudly of many errors it didn't > know how to fix. Sure the whole thing isn't corrupt. But if anything written while degraded vanishes once the missing device is reattached, and you remount normally (non-degraded), that's data loss. Yikes! > There you go, hope this helps. Yes. Thanks! 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
