On Fri, Mar 25, 2016 at 2:16 PM, Patrik Lundquist <patrik.lundqu...@gmail.com> wrote: > On 23 March 2016 at 20:33, Chris Murphy <li...@colorremedies.com> wrote: >> >> On Wed, Mar 23, 2016 at 1:10 PM, Brad Templeton <brad...@gmail.com> wrote: >> > >> > I am surprised to hear it said that having the mixed sizes is an odd >> > case. >> >> Not odd as in wrong, just uncommon compared to other arrangements being >> tested. > > I think mixed drive sizes in raid1 is a killer feature for a home NAS, > where you replace an old smaller drive with the latest and largest > when you need more storage. > > My raid1 currently consists of 6TB+3TB+3*2TB.
For the original OP situation, with chunks all filled op with extents and devices all filled up with chunks, 'integrating' a new 6TB drive in an 4TB+3TG+2TB raid1 array could probably be done in a bit unusual way in order to avoid immediate balancing needs: - 'plug-in' the 6TB - btrfs-replace 4TB by 6TB - btrfs fi resize max 6TB_devID - btrfs-replace 2TB by 4TB - btrfs fi resize max 4TB_devID - 'unplug' the 2TB So then there would be 2 devices with roughly 2TB space available, so good for continued btrfs raid1 writes. An offline variant with dd instead of btrfs-replace could also be done (I used to do that sometimes when btrfs-replace was not implemented). My experience is that btrfs-replace speed is roughly at max speed (so harddisk magnetic media transferspeed) during the whole replace process and it does in a more direct way what you actually want. So in total mostly way faster device replace/upgrade than with the add+delete method. And raid1 redundancy is active all the time. Of course it means first make sure the system runs up-to-date/latest kernel+tools. -- 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
