On Thu, 19 Apr 2012 16:20:43 +0200 Lars Täuber <taeuber@xxxxxxx> wrote: > Hi Neil, > > Am Wed, 29 Feb 2012 12:29:06 +1100 > NeilBrown <neilb@xxxxxxx> schrieb: > > On Fri, 24 Feb 2012 11:38:21 +0100 Lars TÀuber <taeuber@xxxxxxx> wrote: > > > > > Hi there. > > > > > > I have a RAID6 using disks in an external SATA enclosure. > > > Now I started to exchange the disks with others twice as big as the ones > > > the RAID was originally created with. > > > The RAID uses metadata version 0.9. > > > > > > Now I'm thinking about switching to format 1.0 this way: > > > > > > * exchange all disks with the bigger ones piece by piece > > > (-f old -r old -a new) > > > * wait for rebuild of last disk > > > * recreate RAID with --assume-clean and --metadata 1.0 and the same disks > > > in the correct order > > > > > > The --grow shouldn't be necessary this way. > > > Then I grow the filesystem. > > > > > > Is this precedure possible without data loss? > > > Or is there a way a metadata version migration could be done more easily? > > > > Yes, this should work. There is no better way. > > is it possible to change the chunk size while recreating the array to the new > default or do I have to stay with the 64kiB chunk size? You can only change the chunk size by rearranging all the data on the devices. So you canno simply change if when re-creating. > > Because changing the chunk size afterwards might not be possible due to the > new chunk size not fitting in the used device size. > You might have to reduce the size of the array (and the filesystem on the array) first, but you should then be able to change the chunksize. NeilBrown
Attachment:
signature.asc
Description: PGP signature
