On Thu, Aug 5, 2021 at 4:50 AM José María Terry Jiménez <jtj(a)tssystems.net&gt; wrote: Just as a point of translation/familiarization/comparison of the same task with btrfs... btrfs replace start 1 /dev/sdc /mnt btrfs replace start 2 /dev/sdd /mnt btrfs filesystem resize 1:max /mnt btrfs filesystem resize 2:max /mnt * btrfs uses a concept of "devid" to keep track of devices; devices also each have a device item uuid that's totally unambiguous among all other btrfs file systems, but the devid is unambiguous within a specific btrfs, unlike /dev/ node which isn't always the same between reboots. * use 'btrfs filesystem show' to see devid's * replace requires the replacement drive is equal to or bigger than the size of the device being replaced; replace is so much better than "btrfs device add" followed by "btrfs device remove" (which does file system resizes automatically) that you're best off shrinking the source a bit in order to be allowed to use "btrfs replace". * file system resize is per device, specified by devid; if you don't specify devid, then devid 1 is assumed * btrfs replace is derived from the btrfs scrub kernel code, in effect it makes a virtual and temporary "mirror" between the to-be-replaced device and replacement device, and does a scrub to quickly replicate in-use blocks from source to destination. * btrfs replace works with non-raid profiles, including live migration from a single drive to a new drive * you can use 'btrfs replace' even if the drive is missing, even if you're mounted degraded * writes go to both the replacee and replacement devices * following crash/power fail the replace will resume * reminder that there's a built-in shortcut for all btrfs commands, you don't need to configure it or set it up; as long as you enter an unambiguous command, it'll be accepted, if you enter something ambiguous, it'll make suggestions: $ sudo btrfs rep sta btrfs replace: ambiguous token 'sta' Did you mean one of these ? start status 'btrfs rep star' is unambiguous for 'btrfs replace start' - just make up your own short hand... -- Chris Murphy

El 12/8/21 a las 14:18, François Patte escribió: You're welcome, hope it helps you

On 8/7/21 4:19 PM, lejeczek via users wrote: The original poster wants to replace a 2 disk RAID-1 with a bigger 2 disk RAID-1, that is something very different than your suggestion to have a 4 disk RAID-0. The first link mentioned by José María Terry Jiménez is a good procedure for what we want to achieve. I would only point out that everybody tends to remove one of the drive and then add a new one, while you can instead grow the RAID-1 to 3 disks, add your new drive, then remove the old one, then add the second new one and remove the second old one, then (un)grow back to 2 drives and finally resize md and pv. In this way your array never works in degrade 1-disk mode. Of course nobody stops you from going to 4 disk RAID-1 (add, add, remove, remove). I usually do not create RAID-1 on the entire disk space, I prefer to partition into fixed size fragments (e.g. 4 470GB on a 2TB disk) and create many RAID-1 out of partition couples to use as pv. In this way the new shiny 4TB disks are just giving me 8 additional 470GB pieces, I can create the new RAID-1s and pvs, add them to the vg and then use pvmove to decide where the data should be, eventually pvremoving the RAID-1 pieces on the old disks if I'm planning to physically remove them. Everything can be done online, and not even a powerloss is able to do any damage. Done this many many times on big storage servers. Regards. -- Roberto Ragusa mail at robertoragusa.it

On Sat, Aug 7, 2021 at 2:52 PM Roberto Ragusa <mail(a)robertoragusa.it&gt; wrote: While I agree with the "add the pvs to the vgs, pvmove data, remove old pvs" approach, I would like to ask more about why you do not use the entire disk for a raid, instead partition both drives in many volumes and then create raid1 volumes using the respective partitions in the two drives. Does that limit the damage due to HD failure somehow better than a single partition? > Regards. > -- > Roberto Ragusa mail at robertoragusa.it > _______________________________________________ > users mailing list -- users(a)lists.fedoraproject.org > To unsubscribe send an email to users-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

On 8/12/21 2:35 PM, Mauricio Tavares wrote: There are a few reasons. Suppose you make a RAID-1 of two 1TB disks, then one of them fails, you try to replace it with a newer one, but you discover that the number of available sectors is different by a small amount: the new one is smaller, let's say 1.0003TB instead of 1.0005TB of the previous two drives. You now have to do dangerous resizing at RAID level (while in degraded mode), I would definitely avoid it. Or, I should try to pvmove everything out of the degraded RAID-1 to recreate it again a bit smaller. Annoying. Similar issue if I have md14 and md18 of different size: I would like to pvmove from md14 to md18 but one extent will not fit and must be parked in another place. Standardized md?? solve this. Another reason is that if I have a lot of 2TB disks, each divided in 4x470GB partitions and joined in couples to have many RAID-1, I may decide one day I also want to use some space in a 4 disk RAID-5 mode. In this case I just have to free (pvmove) two RAID-1 couples, remove them from the vg and turn them into 4 disk RAID-5. Using different parts of the same disk as RAID-1 and RAID-5 would be impossible by using md on entire disks (the same loss of flexibility often comes from "hardware RAID"). Going back to "different size of different disks", I sometimes explicitly decide to use slightly different sizes when disks are provided by a cloud provider (in a datacenter) that gives you no way to map what you see in the administration panel (disk1, disk2, disk3) with what you get in the machine (vda, vdb, vdc). To make disks recognizable I have the habit to size them slightly different (1900GB, 1910GB, 1920GB), so I'm able to identify them in /proc/partitions even if letter order is messed up. Regards. -- Roberto Ragusa mail at robertoragusa.it