On Mon, Oct 16 2017, Zhilong Liu wrote: > On 10/14/2017 03:05 AM, Shaohua Li wrote: >> On Fri, Oct 13, 2017 at 10:47:29AM +0800, Zhilong Liu wrote: >>> >>> On 10/13/2017 01:37 AM, Shaohua Li wrote: >>>> On Thu, Oct 12, 2017 at 04:30:51PM +0800, Zhilong Liu wrote: >>>>> Against the raids which chunk_size is meaningful, the component_size >>>>> must be >= chunk_size when require resize. If "new_size < chunk_size" >>>>> has required, the "mddev->pers->resize" will set sectors as '0', and >>>>> then the raids isn't meaningful any more due to mddev->dev_sectors is >>>>> '0'. >>>>> >>>>> Cc: Neil Brown <neilb@xxxxxxxx> >>>>> Signed-off-by: Zhilong Liu <zlliu@xxxxxxxx> >>>> Not sure about this, does size 0 disk really harm? >>>> >>> From my site, I think changing the component size as '0' should be avoided. >>> When resize changing required and new_size < current_chunk_size, such as >>> raid5: >>> >>> raid5.c: raid5_resize() >>> ... >>> 7727 sectors &= ~((sector_t)conf->chunk_sectors - 1); >>> ... >>> >>> 'sectors' got '0'. >>> >>> then: >>> ... >>> 7743 mddev->dev_sectors = sectors; >>> ... >>> >>> the dev_sectors(the component size) got '0'. >>> same scenario happens in raid10. >>> >>> So, it's really not meaningful if changing the raid component_size to '0', >>> md >>> should give this scenario a test, otherwise, it's a trouble thing to restore >>> after >>> doing such invalid re-size. >> Yes, I understand how it could be 0. My question is what's wrong with a size-0 >> disk? For example, if you don't setup file for a loop block device, its size is >> 0. > I'm sorry I'm not very clear with your question, I try to describe more > on this scenario. > the 0-component_size isn't a 0-size disk. resize doesn't change > raid_member_disk size > to 0. > > For example: mdadm -CR /dev/md0 -b internal -l5 -n2 -x1 /dev/sd[b-d] > if set the component_size to 0, how would the 'internal bitmap' be? And > if I want to make > a file-system on this raid, how would it be? it's out of my control. > > I would continue to provide infos for you if any questions needs further > discussion. > > Hope this information is useful for you. > Here is piece of dmesg for the following steps: > 1. mdadm -CR /dev/md0 -b internal -l5 -n2 -x1 /dev/sd[b-d] > 2. mdadm -G /dev/md0 --size 511 > 3. mkfs.ext3 /dev/md0 > the mkfs would be stuck all time, cannot kill the mkfs process and have to > force to reboot, then lots of same call trace prints in dmesg. I think the cause of this problem is that raid5_size() treats zero values for 'sectors' and 'raid_disks' as "don't change". So setting the size to zero will change mddev->dev_sectors but not mddev->array_size. This causes internal confusion. Maybe we should use a different number of "don't change" ?? This could affect any of the ->size() functions. NeilBrown
Attachment:
signature.asc
Description: PGP signature
