has anybody else faced complete freezes of a machine due raid-check? today the same as last thursday while the freeze seems not to happen by the raid-check itself according to running smokepings from outside which are green until i try to use the machine
* last thursday morining around 8:30 while login in KDE * today around 9:45 AM while power on the screen and continue to re-use a existing KDE session
however, after hard power off, the fsck, login in KDE and start the raid-check manually on TTY3 it continues ____________________________________________________
since the raid-check starts at 5:30 and all heavy IO from remote-backups and rsnapshot ends at 4:30 to not collide it's hardly IO-dependent
[root@srv-rhsoft:~]$ cat /etc/cron.d/raid-check 30 5 * * Thu root /usr/sbin/raid-check
On Thu, May 01, 2014 at 11:18:25 +0200, Reindl Harald h.reindl@thelounge.net wrote:
has anybody else faced complete freezes of a machine due raid-check? today the same as last thursday while the freeze seems not to happen by the raid-check itself according to running smokepings from outside which are green until i try to use the machine
I had something similar happen in pre-release kernels a few versions ago, but it got fixed and I am not seeing it now.
Am 01.05.2014 14:12, schrieb Bruno Wolff III:
On Thu, May 01, 2014 at 11:18:25 +0200, Reindl Harald h.reindl@thelounge.net wrote:
has anybody else faced complete freezes of a machine due raid-check? today the same as last thursday while the freeze seems not to happen by the raid-check itself according to running smokepings from outside which are green until i try to use the machine
I had something similar happen in pre-release kernels a few versions ago, but it got fixed and I am not seeing it now
interesting - thanks for feedback
i have faced this only on F20 with the recent 3.14 kernel which is except the weekly raid-check hyperstable under any heavy networking and/or IO load, what makes it hard to debug is that it's not triggerable by starting raid-check manually
the only information i sadly can provide is partitioning / raid setup
[root@srv-rhsoft:~]$ df Filesystem Type Size Used Avail Use% Mounted on /dev/md1 ext4 29G 6.4G 23G 23% / /dev/md0 ext4 485M 37M 444M 8% /boot /dev/md2 ext4 3.6T 2.0T 1.6T 57% /mnt/data
[root@srv-rhsoft:~]$ cat /usr/local/bin/raid_status #!/usr/bin/bash echo "---------------------------------------------------------------------------------" /sbin/mdadm --detail /dev/md0 echo "---------------------------------------------------------------------------------" /sbin/mdadm --detail /dev/md1 echo "---------------------------------------------------------------------------------" /sbin/mdadm --detail /dev/md2 echo "---------------------------------------------------------------------------------" cat /proc/mdstat echo "---------------------------------------------------------------------------------"
[root@srv-rhsoft:~]$ raid_status --------------------------------------------------------------------------------- /dev/md0: Version : 1.0 Creation Time : Wed Jun 8 13:10:48 2011 Raid Level : raid1 Array Size : 511988 (500.07 MiB 524.28 MB) Used Dev Size : 511988 (500.07 MiB 524.28 MB) Raid Devices : 4 Total Devices : 4 Persistence : Superblock is persistent
Update Time : Thu May 1 09:42:22 2014 State : clean, resyncing (DELAYED) Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0
Name : localhost.localdomain:0 UUID : 1d691642:baed26df:1d197496:4fb00ff8 Events : 651
Number Major Minor RaidDevice State 0 8 49 0 active sync /dev/sdd1 5 8 33 1 active sync /dev/sdc1 4 8 1 2 active sync /dev/sda1 3 8 17 3 active sync /dev/sdb1 --------------------------------------------------------------------------------- /dev/md1: Version : 1.1 Creation Time : Wed Jun 8 13:10:52 2011 Raid Level : raid10 Array Size : 30716928 (29.29 GiB 31.45 GB) Used Dev Size : 15358464 (14.65 GiB 15.73 GB) Raid Devices : 4 Total Devices : 4 Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Thu May 1 14:43:16 2014 State : active, resyncing (DELAYED) Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0
Layout : near=2 Chunk Size : 512K
Name : localhost.localdomain:1 UUID : b7475879:c95d9a47:c5043c02:0c5ae720 Events : 12359
Number Major Minor RaidDevice State 0 8 50 0 active sync set-A /dev/sdd2 5 8 34 1 active sync set-B /dev/sdc2 4 8 2 2 active sync set-A /dev/sda2 3 8 18 3 active sync set-B /dev/sdb2 --------------------------------------------------------------------------------- /dev/md2: Version : 1.1 Creation Time : Wed Jun 8 13:10:56 2011 Raid Level : raid10 Array Size : 3875222528 (3695.70 GiB 3968.23 GB) Used Dev Size : 1937611264 (1847.85 GiB 1984.11 GB) Raid Devices : 4 Total Devices : 4 Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Thu May 1 14:43:23 2014 State : active, checking Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0
Layout : near=2 Chunk Size : 512K
Check Status : 42% complete
Name : localhost.localdomain:2 UUID : ea253255:cb915401:f32794ad:ce0fe396 Events : 496336
Number Major Minor RaidDevice State 0 8 51 0 active sync set-A /dev/sdd3 5 8 35 1 active sync set-B /dev/sdc3 4 8 3 2 active sync set-A /dev/sda3 3 8 19 3 active sync set-B /dev/sdb3 --------------------------------------------------------------------------------- Personalities : [raid1] [raid10] md2 : active raid10 sdd3[0] sda3[4] sdb3[3] sdc3[5] 3875222528 blocks super 1.1 512K chunks 2 near-copies [4/4] [UUUU] [========>............] check = 42.9% (1665190848/3875222528) finish=278.2min speed=132374K/sec bitmap: 3/29 pages [12KB], 65536KB chunk
md1 : active raid10 sda2[4] sdb2[3] sdd2[0] sdc2[5] 30716928 blocks super 1.1 512K chunks 2 near-copies [4/4] [UUUU] resync=DELAYED bitmap: 1/1 pages [4KB], 65536KB chunk
md0 : active raid1 sdb1[3] sda1[4] sdd1[0] sdc1[5] 511988 blocks super 1.0 [4/4] [UUUU] resync=DELAYED
unused devices: <none> ---------------------------------------------------------------------------------
The bug I reported to upstream is: https://bugzilla.kernel.org/show_bug.cgi?id=68061
That was for 3.13, so if you were running into a varient of the problem I was seeing, you should have seen it in 3.13. I did not see the problem with 3.14 or 3.15 pre-release kernels. I'm using raid 1 instead of raid 10.
Am 01.05.2014 14:55, schrieb Bruno Wolff III:
The bug I reported to upstream is: https://bugzilla.kernel.org/show_bug.cgi?id=68061
That was for 3.13, so if you were running into a varient of the problem I was seeing, you should have seen it in 3.13. I did not see the problem with 3.14 or 3.15 pre-release kernels. I'm using raid 1 instead of raid 10
different problem class you where able to look at cat/proc/mdstat
in my case the machine is just dead and don't react on any input including ACPI powerbutton, this morning i saw a frozen KDE desktop with high CPU load from the past in monitoring widgets, last week it froze while login (after enter username and password in KDM the first black screen before build the desktop appeared and any operatins stopped)
i will wait some hours for possible feedback here and than file a bugreport, sadly there is not much constrcutive i can report caused by the complete system freeze and no logs or anything after hard power off and boot again
Am 01.05.2014 15:06, schrieb Reindl Harald:
Am 01.05.2014 14:55, schrieb Bruno Wolff III:
The bug I reported to upstream is: https://bugzilla.kernel.org/show_bug.cgi?id=68061
That was for 3.13, so if you were running into a varient of the problem I was seeing, you should have seen it in 3.13. I did not see the problem with 3.14 or 3.15 pre-release kernels. I'm using raid 1 instead of raid 10
different problem class you where able to look at cat/proc/mdstat
in my case the machine is just dead and don't react on any input including ACPI powerbutton, this morning i saw a frozen KDE desktop with high CPU load from the past in monitoring widgets, last week it froze while login (after enter username and password in KDM the first black screen before build the desktop appeared and any operatins stopped)
i will wait some hours for possible feedback here and than file a bugreport, sadly there is not much constrcutive i can report caused by the complete system freeze and no logs or anything after hard power off and boot again
ok, it's not only raid-check, 15 minutes ago it happened again freeze number 3 - i fear a bugreport makes not much sense because "system freezes once or two per week before lunch" is not that much helpful, most likely that will not hit only me and get away with a following 3.14.x update
Apr 21 23:34:54 Installed: kernel-3.14.1-200.fc20.x86_64 Apr 28 20:50:54 Installed: kernel-3.14.2-200.fc20.x86_64
Am 02.05.2014 11:09, schrieb Reindl Harald:
Am 01.05.2014 15:06, schrieb Reindl Harald:
Am 01.05.2014 14:55, schrieb Bruno Wolff III:
The bug I reported to upstream is: https://bugzilla.kernel.org/show_bug.cgi?id=68061
That was for 3.13, so if you were running into a varient of the problem I was seeing, you should have seen it in 3.13. I did not see the problem with 3.14 or 3.15 pre-release kernels. I'm using raid 1 instead of raid 10
different problem class you where able to look at cat/proc/mdstat
in my case the machine is just dead and don't react on any input including ACPI powerbutton, this morning i saw a frozen KDE desktop with high CPU load from the past in monitoring widgets, last week it froze while login (after enter username and password in KDM the first black screen before build the desktop appeared and any operatins stopped)
i will wait some hours for possible feedback here and than file a bugreport, sadly there is not much constrcutive i can report caused by the complete system freeze and no logs or anything after hard power off and boot again
ok, it's not only raid-check, 15 minutes ago it happened again freeze number 3 - i fear a bugreport makes not much sense because "system freezes once or two per week before lunch" is not that much helpful, most likely that will not hit only me and get away with a following 3.14.x update
Apr 21 23:34:54 Installed: kernel-3.14.1-200.fc20.x86_64 Apr 28 20:50:54 Installed: kernel-3.14.2-200.fc20.x86_64
3.14.3-200.fc20.x86_64 and sadly today the same on two machines - the only thing i can say for sure that after whatever happens in the background *any* write to disks hangs forever
* woke up -> no music * turn on screen, move the mouse, KDM login screen * try to enter password * see the first asterisk and followed input ignored * move the mousepointer still works * STRG+ALT+F3 -> thank god there is a active root session * type "sync" -> no disk activity, no response * well, power off hard _____________________________________________
second machine in the office:
* KDM hangs * login on TTY3 by luck possible * dmesg -> only the usual lines about starting raid-check and delay the two other raid devices * nothing else in dmesg or syslog * also here: any write to disk stalls
https://bugzilla.redhat.com/show_bug.cgi?id=1096414 https://bugzilla.redhat.com/show_bug.cgi?id=1092937
*both* seems to be fixed with 3.14.5-200.fc20.x86_64 while i am unable to find the relevant change in the kernel-upstream-changelog
would be nice to know that it is fixed for a reason and not by random as it came - *maybe* the change to "data=ordered" instead "data=writeback" is responsible but i don't want to test that since there where enough data-damages by that freezes
however, rebootet my workstation 40 times after the update from koji and 4 raid-check runs without any freeze on two different machines
Am 08.05.2014 11:10, schrieb Reindl Harald:
Am 02.05.2014 11:09, schrieb Reindl Harald:
Am 01.05.2014 15:06, schrieb Reindl Harald:
Am 01.05.2014 14:55, schrieb Bruno Wolff III:
The bug I reported to upstream is: https://bugzilla.kernel.org/show_bug.cgi?id=68061
That was for 3.13, so if you were running into a varient of the problem I was seeing, you should have seen it in 3.13. I did not see the problem with 3.14 or 3.15 pre-release kernels. I'm using raid 1 instead of raid 10
different problem class you where able to look at cat/proc/mdstat
in my case the machine is just dead and don't react on any input including ACPI powerbutton, this morning i saw a frozen KDE desktop with high CPU load from the past in monitoring widgets, last week it froze while login (after enter username and password in KDM the first black screen before build the desktop appeared and any operatins stopped)
i will wait some hours for possible feedback here and than file a bugreport, sadly there is not much constrcutive i can report caused by the complete system freeze and no logs or anything after hard power off and boot again
ok, it's not only raid-check, 15 minutes ago it happened again freeze number 3 - i fear a bugreport makes not much sense because "system freezes once or two per week before lunch" is not that much helpful, most likely that will not hit only me and get away with a following 3.14.x update
Apr 21 23:34:54 Installed: kernel-3.14.1-200.fc20.x86_64 Apr 28 20:50:54 Installed: kernel-3.14.2-200.fc20.x86_64
3.14.3-200.fc20.x86_64 and sadly today the same on two machines - the only thing i can say for sure that after whatever happens in the background *any* write to disks hangs forever
- woke up -> no music
- turn on screen, move the mouse, KDM login screen
- try to enter password
- see the first asterisk and followed input ignored
- move the mousepointer still works
- STRG+ALT+F3 -> thank god there is a active root session
- type "sync" -> no disk activity, no response
- well, power off hard
second machine in the office:
- KDM hangs
- login on TTY3 by luck possible
- dmesg -> only the usual lines about starting raid-check and delay the two other raid devices
- nothing else in dmesg or syslog
- also here: any write to disk stalls
sadly both re-opened today, after some hours of running shutdown and raid-check with 3.14 is a pain and taht is *for sure* 3.14.x because my co-developer stayed at the last 3.13 until i thought it's fine now, had never that problems and both 3.14.x shutdowns freezed with mdraid
Am 03.06.2014 21:10, schrieb Reindl Harald:
https://bugzilla.redhat.com/show_bug.cgi?id=1096414 https://bugzilla.redhat.com/show_bug.cgi?id=1092937
*both* seems to be fixed with 3.14.5-200.fc20.x86_64 while i am unable to find the relevant change in the kernel-upstream-changelog
would be nice to know that it is fixed for a reason and not by random as it came - *maybe* the change to "data=ordered" instead "data=writeback" is responsible but i don't want to test that since there where enough data-damages by that freezes
however, rebootet my workstation 40 times after the update from koji and 4 raid-check runs without any freeze on two different machines
Am 08.05.2014 11:10, schrieb Reindl Harald:
Am 02.05.2014 11:09, schrieb Reindl Harald:
Am 01.05.2014 15:06, schrieb Reindl Harald:
Am 01.05.2014 14:55, schrieb Bruno Wolff III:
The bug I reported to upstream is: https://bugzilla.kernel.org/show_bug.cgi?id=68061
That was for 3.13, so if you were running into a varient of the problem I was seeing, you should have seen it in 3.13. I did not see the problem with 3.14 or 3.15 pre-release kernels. I'm using raid 1 instead of raid 10
different problem class you where able to look at cat/proc/mdstat
in my case the machine is just dead and don't react on any input including ACPI powerbutton, this morning i saw a frozen KDE desktop with high CPU load from the past in monitoring widgets, last week it froze while login (after enter username and password in KDM the first black screen before build the desktop appeared and any operatins stopped)
i will wait some hours for possible feedback here and than file a bugreport, sadly there is not much constrcutive i can report caused by the complete system freeze and no logs or anything after hard power off and boot again
ok, it's not only raid-check, 15 minutes ago it happened again freeze number 3 - i fear a bugreport makes not much sense because "system freezes once or two per week before lunch" is not that much helpful, most likely that will not hit only me and get away with a following 3.14.x update
Apr 21 23:34:54 Installed: kernel-3.14.1-200.fc20.x86_64 Apr 28 20:50:54 Installed: kernel-3.14.2-200.fc20.x86_64
3.14.3-200.fc20.x86_64 and sadly today the same on two machines - the only thing i can say for sure that after whatever happens in the background *any* write to disks hangs forever
- woke up -> no music
- turn on screen, move the mouse, KDM login screen
- try to enter password
- see the first asterisk and followed input ignored
- move the mousepointer still works
- STRG+ALT+F3 -> thank god there is a active root session
- type "sync" -> no disk activity, no response
- well, power off hard
second machine in the office:
- KDM hangs
- login on TTY3 by luck possible
- dmesg -> only the usual lines about starting raid-check and delay the two other raid devices
- nothing else in dmesg or syslog
- also here: any write to disk stalls
Am 06.06.2014 00:28, schrieb Reindl Harald:
sadly both re-opened today, after some hours of running shutdown and raid-check with 3.14 is a pain and taht is *for sure* 3.14.x because my co-developer stayed at the last 3.13 until i thought it's fine now, had never that problems and both 3.14.x shutdowns freezed with mdraid
the two commits below smell like related not sure how to understand the second one filestems on affected machines are mounted with nobarrier
https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.14.6 ____________________________________________________________________________________________
commit 0bc4091108e8f2e65faef3082e5261f2c35cd2b4 Author: NeilBrown neilb@suse.de Date: Tue May 6 09:36:08 2014 +1000
md: avoid possible spinning md thread at shutdown.
commit 0f62fb220aa4ebabe8547d3a9ce4a16d3c045f21 upstream.
If an md array with externally managed metadata (e.g. DDF or IMSM) is in use, then we should not set safemode==2 at shutdown because:
1/ this is ineffective: user-space need to be involved in any 'safemode' handling, 2/ The safemode management code doesn't cope with safemode==2 on external metadata and md_check_recover enters an infinite loop.
Even at shutdown, an infinite-looping process can be problematic, so this could cause shutdown to hang.
Signed-off-by: NeilBrown neilb@suse.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org ____________________________________________________________________________________________
commit 8c7311a1c4a8d804bde91b00a2f2c1a22a954c30 Author: NeilBrown neilb@suse.de Date: Mon May 5 13:34:37 2014 +1000
md/raid10: call wait_barrier() for each request submitted.
commit cc13b1d1500656a20e41960668f3392dda9fa6e2 upstream.
wait_barrier() includes a counter, so we must call it precisely once (unless balanced by allow_barrier()) for each request submitted.
Since commit 20d0189b1012a37d2533a87fb451f7852f2418d1 block: Introduce new bio_split() in 3.14-rc1, we don't call it for the extra requests generated when we need to split a bio.
When this happens the counter goes negative, any resync/recovery will never start, and "mdadm --stop" will hang.
Reported-by: Chris Murphy lists@colorremedies.com Fixes: 20d0189b1012a37d2533a87fb451f7852f2418d1 Cc: Kent Overstreet kmo@daterainc.com Signed-off-by: NeilBrown neilb@suse.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org ____________________________________________________________________________________________
Am 03.06.2014 21:10, schrieb Reindl Harald:
https://bugzilla.redhat.com/show_bug.cgi?id=1096414 https://bugzilla.redhat.com/show_bug.cgi?id=1092937
*both* seems to be fixed with 3.14.5-200.fc20.x86_64 while i am unable to find the relevant change in the kernel-upstream-changelog
would be nice to know that it is fixed for a reason and not by random as it came - *maybe* the change to "data=ordered" instead "data=writeback" is responsible but i don't want to test that since there where enough data-damages by that freezes
however, rebootet my workstation 40 times after the update from koji and 4 raid-check runs without any freeze on two different machines
Am 08.05.2014 11:10, schrieb Reindl Harald:
Am 02.05.2014 11:09, schrieb Reindl Harald:
Am 01.05.2014 15:06, schrieb Reindl Harald:
Am 01.05.2014 14:55, schrieb Bruno Wolff III:
The bug I reported to upstream is: https://bugzilla.kernel.org/show_bug.cgi?id=68061
That was for 3.13, so if you were running into a varient of the problem I was seeing, you should have seen it in 3.13. I did not see the problem with 3.14 or 3.15 pre-release kernels. I'm using raid 1 instead of raid 10
different problem class you where able to look at cat/proc/mdstat
in my case the machine is just dead and don't react on any input including ACPI powerbutton, this morning i saw a frozen KDE desktop with high CPU load from the past in monitoring widgets, last week it froze while login (after enter username and password in KDM the first black screen before build the desktop appeared and any operatins stopped)
i will wait some hours for possible feedback here and than file a bugreport, sadly there is not much constrcutive i can report caused by the complete system freeze and no logs or anything after hard power off and boot again
ok, it's not only raid-check, 15 minutes ago it happened again freeze number 3 - i fear a bugreport makes not much sense because "system freezes once or two per week before lunch" is not that much helpful, most likely that will not hit only me and get away with a following 3.14.x update
Apr 21 23:34:54 Installed: kernel-3.14.1-200.fc20.x86_64 Apr 28 20:50:54 Installed: kernel-3.14.2-200.fc20.x86_64
3.14.3-200.fc20.x86_64 and sadly today the same on two machines - the only thing i can say for sure that after whatever happens in the background *any* write to disks hangs forever
- woke up -> no music
- turn on screen, move the mouse, KDM login screen
- try to enter password
- see the first asterisk and followed input ignored
- move the mousepointer still works
- STRG+ALT+F3 -> thank god there is a active root session
- type "sync" -> no disk activity, no response
- well, power off hard
second machine in the office:
- KDM hangs
- login on TTY3 by luck possible
- dmesg -> only the usual lines about starting raid-check and delay the two other raid devices
- nothing else in dmesg or syslog
- also here: any write to disk stalls
On Fri, Jun 6, 2014 at 1:28 AM, Reindl Harald h.reindl@thelounge.net wrote:
sadly both re-opened today, after some hours of running shutdown and raid-check with 3.14 is a pain and taht is *for sure* 3.14.x because my co-developer stayed at the last 3.13 until i thought it's fine now, had never that problems and both 3.14.x shutdowns freezed with mdraid
I can confirm the above on two machines w/ MD RAID10 (and boot on MD RAID1).
Thus far, I've yet to see machines w/ RAID5 or RAID6 exhibit the same crash.
- Gilboa
On 08.06.2014 11:11, Gilboa Davara wrote:
On Fri, Jun 6, 2014 at 1:28 AM, Reindl Harald h.reindl@thelounge.net wrote:
sadly both re-opened today, after some hours of running shutdown and raid-check with 3.14 is a pain and taht is *for sure* 3.14.x because my co-developer stayed at the last 3.13 until i thought it's fine now, had never that problems and both 3.14.x shutdowns freezed with mdraid
I can confirm the above on two machines w/ MD RAID10 (and boot on MD RAID1).
Thus far, I've yet to see machines w/ RAID5 or RAID6 exhibit the same crash.
- Gilboa
According[1] to NeilBrown it's resolved and applied in the 3.14.6[2]. If the problem is still present, you can continue the discussion on linux-raid@vger.kernel.org[3]. Don't forget to CC here, or vice versa.
poma
[1] http://marc.info/?l=linux-raid&m=140062838306788 [2] https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.14.6 [3] http://vger.kernel.org/vger-lists.html#linux-raid
Am 11.06.2014 00:00, schrieb poma:
On 08.06.2014 11:11, Gilboa Davara wrote:
On Fri, Jun 6, 2014 at 1:28 AM, Reindl Harald h.reindl@thelounge.net wrote:
sadly both re-opened today, after some hours of running shutdown and raid-check with 3.14 is a pain and taht is *for sure* 3.14.x because my co-developer stayed at the last 3.13 until i thought it's fine now, had never that problems and both 3.14.x shutdowns freezed with mdraid
I can confirm the above on two machines w/ MD RAID10 (and boot on MD RAID1).
Thus far, I've yet to see machines w/ RAID5 or RAID6 exhibit the same crash.
- Gilboa
According[1] to NeilBrown it's resolved and applied in the 3.14.6[2]. If the problem is still present, you can continue the discussion on linux-raid@vger.kernel.org[3]. Don't forget to CC here, or vice versa.
i really stressed my office-machine over the last few days by move many gigabytes of data while raid-ckechk was running and *both* issues (the frezze at raid-check and hang at shutdown) seems to be fixed with 3.14.6
well, since i closed both reported bugs with 3.14.5 followed by re-open both with a few hours i will look at that a few days
however, since 3.13 was EOL there was nothing really wrong with the updates push given the the security relevant fixes and using kernels from koji over years the first time with real troubles is not that bad
On Sun, Jun 8, 2014 at 12:11 PM, Gilboa Davara gilboad@gmail.com wrote:
On Fri, Jun 6, 2014 at 1:28 AM, Reindl Harald h.reindl@thelounge.net wrote:
sadly both re-opened today, after some hours of running shutdown and raid-check with 3.14 is a pain and taht is *for sure* 3.14.x because my co-developer stayed at the last 3.13 until i thought it's fine now, had never that problems and both 3.14.x shutdowns freezed with mdraid
I can confirm the above on two machines w/ MD RAID10 (and boot on MD RAID1).
Thus far, I've yet to see machines w/ RAID5 or RAID6 exhibit the same crash.
- Gilboa
I'm currently running a full RAID check on 8TB RAID10 volume w/ 3.14.6. Thus far, everything seems to be working just fine (knock wood).
- Gilboa
kernel@lists.fedoraproject.org
-
Bruno Wolff III -
Gilboa Davara -
poma -
Reindl Harald