On Wed, Apr 14, 2010 at 4:27 PM, James Braid <jamesb@xxxxxxxxxxxx> wrote: > Michael Evans wrote: >> >> Yes, that /extremely/ slow growth progress is normal for this >> conversion. Every critical section must be backed up synced, and only >> then will it proceed. You may notice an incorrect number of disks >> relative to the expected number. That will go away the next time the >> array is assembled. > > Thanks. I'm not concerned about the speed; the fact that I had to stop and > restart the array before the reshape would begin is what concerns me, as > well as the odd sysfs errors. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > Probably some minor bug relating to sysfs entry creation; it looks like it saw a duplicate entry, so probably just one flow control statement and test off of valid. It looks like that would have been ancillary to the actual critical work anyway. Presuming your data doesn't read as garbage at the moment it should be intact when the reshape completes as well. As for what caused the error, you'd have to ask someone that currently writes/tests the git version. The system I use software raid on is more or less 'production' in that it's the main file-server for the house, so I tend to only use stable kernel versions. -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
