Very cool =). But i think with latest patches for mdadm with ability to control data offset we can use "vanilla" mdadm =). 2013/4/22 Sebastian Riemer <sebastian.riemer@xxxxxxxxxxxxxxxx>: > On 22.04.2013 08:28, Vasiliy Tolstov wrote: >>> Why are you doing that? >> >> Our storage have two nodes each provides disk via srp to nodes. On >> each node we create separate lvm (we not using clvm) and assemble md. >> Sometimes we resize lvm and need to zero superblock, becouse sometimes >> we can still have old mdadm data on lvm part (from previous user for >> example). And then we add disk to raid we can get sometimes broken >> data (invalid sync). >> >>> >>>> P.S. If i use mdadm 3.2.2 i get data offset 4096 that not breaks data, >>>> but inconsistent with older versions. >>> >>> I suggest you use mdadm 3.2.2 then. >> >> Yes, i'm already do that, but i think that lates mdadm version with >> data-offset patches can solve my problems. Is that possible to correct >> it behaviour and write in docs which data offset used in which version >> of mdadm? >> >>> >>>> P.P.S. I'm try to specify --data-offset when create array but as i see >>>> - its ignored and data offset still have 8192). >>> >>> I'll try to make sure that works correctly for the next release. >>> Thanks for the report. > > So you use MD RAID-1 on the SRP initiator for replication? > > So do we. We've just hacked mdadm to always use one LV extent (4 MiB) > for the "head room" with RAID-1 and don't allow reshape of RAID-1 > anymore. This makes it very easy to calculate. We had to change mdadm > and the MD kernel code anyway to provide advanced replication features. > > We've even got safe VM live migration with it and raw-to-md migration > letting the MD syncer do the job to sync the data from the raw device to > the MD devices. :-) > Replication of virtual storage doesn't really work without custom > hacking with MD. This use case is very hard to merge with mainline > behavior. But the required changes are relatively small. > > Cheers, > Sebastian -- Vasiliy Tolstov, e-mail: v.tolstov@xxxxxxxxx jabber: vase@xxxxxxxxx -- 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
