On Mar 19, 2014, at 12:09 AM, Marc MERLIN <marc@xxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
