On Tue, 16 Dec 2014 21:55:15 +0530 Anshuman Aggarwal <anshuman.aggarwal@xxxxxxxxx> wrote: > On 2 December 2014 at 17:26, Anshuman Aggarwal > <anshuman.aggarwal@xxxxxxxxx> wrote: > > It works! (Atleast on a sample 5 MB device with 5 x 1MB partitions :-) > > will find more space on my drives and do a larger test but don't see > > why it shouldn't work) > > Here are the following caveats (and questions): > > - Neil, like you pointed out, the power of 2 chunk size will probably > > need a code change (in the kernel or only in the userspace tool?) In the kernel too. > > - Any performance or other reasons why a terabyte size chunk may > > not be feasible? Not that I can think of. > > - Implications of safe_mode_delay > > - Would the metadata be updated on the block device be written to > > and the parity device as well? Probably. Hard to give a specific answer to vague question. > > - If the drive fails which is the same as the drive being written > > to, would that lack of metadata updates to the other devices affect > > reconstruction? Again, to give a precise answer, a detailed question is needed. Obviously any change would have to made in such a way to ensure that things which needed to work, did work. > > - Adding new devices (is it possible to move the parity to the disk > > being added? How does device addition work for RAID4 ...is it added as > > a zero-ed out device with parity disk remaining the same) RAID5 or RAID6 with ALGORITHM_PARITY_0 puts the parity on the early devices. Currently if you add a device to such an array ...... I'm not sure what it will do. It should be possible to make it just write zeros out. NeilBrown > > > > > > Neil, sorry to try to bump this thread. Could you please look over the > questions and address the points on the remaining items that can make > it a working solution? Thanks
Attachment:
pgpLP584nszNw.pgp
Description: OpenPGP digital signature
