From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anshuman Aggarwal Subject: Re: Split RAID: Proposal for archival RAID using incremental batch checksum Date: Tue, 16 Dec 2014 21:55:15 +0530 Message-ID: References: <20141029200501.1f01269d@notabene.brown> <20141103165217.3bfd3d3e@notabene.brown> <20141125095052.51f8eadc@notabene.brown> <20141202084611.45f56d6a@notabene.brown> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: Sender: linux-raid-owner@vger.kernel.org To: NeilBrown Cc: Mdadm List-Id: linux-raid.ids On 2 December 2014 at 17:26, Anshuman Aggarwal 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?) > - Any performance or other reasons why a terabyte size chunk may > not be feasible? > - Implications of safe_mode_delay > - Would the metadata be updated on the block device be written to > and the parity device as well? > - 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? > - 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) > > 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