On Tue, Sep 20, 2016 at 1:43 PM, Austin S. Hemmelgarn <ahferro...@gmail.com> wrote:
>> First off, as Chris said, if you can read the data and don't already have a > backup, that should be your first priority. This really is an edge case > that's not well tested, and the kernel technically doesn't officially > support it. > > Now, beyond that and his suggestions, there's another option, but it's > risky, so I wouldn't even think about trying it without a backup (unless of > course you can trivially regenerate the data). Multiple devices support and > online resizing allows for a rather neat trick to regenerate a filesystem in > place. The process is pretty simple: > 1. Shrink the existing filesystem down to the minimum size possible. > 2. Create a new partition in the free space, and format it as a temporary > BTRFS filesystem. Ideally, this FS should be mixed mode, and ideally single > profile. If you don't have much free space, you can use a flash drive to > start this temporary filesystem instead. > 3. Start copying files from the old filesystem to the temporary one. > 4. Once the new filesystem is about 95% full, stop copying, shrink the old > filesystem again, create a new partition, and add that partition to the > temporary filesystem. > 5. Repeat steps 3-4 until you have everything off of the old filesystem. > 6. Re-format the remaining portion of the old filesystem using the > parameters you want for the replacement filesystem. > 7. Start copying files from the temporary filesystem to the new filesystem. > 8. As you empty out each temporary partition, remove it from the temporary > filesystem, delete the partition, and expand the new filesystem. > > This takes a while, and is only safe if you have reliable hardware, but I've > done it before and it works reliably as long as you don't have many big > files on the old filesystem (things can get complicated if you do). The > other negative aspect is that if you aren't careful, it's possible to get > stuck half-way, but in such a case, adding a flash drive to the temporary > filesystem can usually give you enough extra space to get things unstuck. Yes I thought of this also. Gotcha is that he'll need to apply the patch that allows degraded rw mounts with a device missing on the actual computer with these drives. He tested that patch in a VM with virtual devices. What might be easier is just 'btrfs dev rm /dev/sda6' because that one has the least amount of data on it: devid 12 size 728.32GiB used 312.03GiB path /dev/sda6 which should fit on all remaining devices. But, does Btrfs get pissed at some point that there's this missing device it might want to write to? I have no idea to what degree this patched kernel permits a lot of degraded writing. The other quandary is the file system will do online shrink, but the kernel can sometimes get pissy about partition map changes on devices with active volumes, even when using partprobe to update the kernel's idea of the partition map. -- 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
