https://bugzilla.kernel.org/show_bug.cgi?id=75881 Bug ID: 75881 Summary: lazyinit failure on new mdadm raid5 & encrypted array Product: File System Version: 2.5 Kernel Version: 3.13.10 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: ext4 Assignee: fs_ext4@xxxxxxxxxxxxxxxxxxxx Reporter: thomas_reardon@xxxxxxxxxxx Regression: No Created attachment 135751 --> https://bugzilla.kernel.org/attachment.cgi?id=135751&action=edit kernel log, ext4 fs params ext4 lazyinit fails with corruption when competing with mdadm raid5 reconstruction. In the _default_ scenario, mdadm doesn't initialize a new raid5 array but rather leaves the last drives as a rebuilding spare, rather than a full initialization. Adding to the load, the volume was an encrypted LUKS volume (at /dev/mapper/private) So the order of events: 1) create new 4x4TB RAID5 array via mdadm. volume is started degraded and starts rebuilding while allowing access. 2) layer new encrypted LUKS volume: /dev/md1 -> /dev/mapper/private 3) create EXT4 volume with 64bit,sparse_super2, 4) mount volume with journal_async_commit 5) a slow rsync is started in background, averaging 5MB/s Please see attached -- You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
