On Sat, Jun 15, 2019 at 1:27 AM Mathias G <newsnet-mg-2016@xxxxxxxxxxxxx> wrote: > > Hi Song > > Thanks for your reply. > > On 15.06.19 02:39, Song Liu wrote: > > To be clear, this does not happen every time, right? > This is correct. There are alot of shutdown/reboot sequences without any > issues. > > > And the bitmap is stored in a file? And the file is on a different disk, right? > No, the bitmap is stored internal. > > An printout of the mdadm details: > > # mdadm --detail /dev/md0 > > /dev/md0: > > Version : 1.2 > > Creation Time : Wed May 16 00:35:33 2018 > > Raid Level : raid1 > > Array Size : 1953382464 (1862.89 GiB 2000.26 GB) > > Used Dev Size : 1953382464 (1862.89 GiB 2000.26 GB) > > Raid Devices : 2 > > Total Devices : 2 > > Persistence : Superblock is persistent > > > > Intent Bitmap : Internal > > > > Update Time : Sat Jun 15 10:20:19 2019 > > State : clean, resyncing > > Active Devices : 2 > > Working Devices : 2 > > Failed Devices : 0 > > Spare Devices : 0 > > > > Consistency Policy : bitmap > > > > Resync Status : 32% complete > > > > Name : $hostname:0 (local to host $hostname) > > UUID : 4635f0fe:f2676778:6e9451dc:92a18ede > > Events : 233032 > > > > Number Major Minor RaidDevice State > > 0 8 17 0 active sync /dev/sdb1 > > 3 8 33 1 active sync /dev/sdc1 > > Let me know if you need more details. The events count is just off by 1, so it looks like the bitmap's super block didn't got update properly. From the code in latest upstream, we write the superblock with REQ_SYNC, but not REQ_OP_FLUSH or REQ_FUA, so this _might_ be the problem. Question: are you running the two drives with write cache on? If yes, and if your application is not heavy on writes, could you try turn off HDD write cache and see if the issue repros? Thanks, Song > -- > thanks alot! > > regards, > mathias
