* Re: Help recovering an interrupted raid0 reshape
From: NeilBrown @ 2015-04-07 1:50 UTC (permalink / raw)
To: Jonathan Harker (Jesusaurus); +Cc: linux-raid
In-Reply-To: <20150407094608.4a9dd142@notabene.brown>
[-- Attachment #1: Type: text/plain, Size: 642 bytes --]
On Tue, 7 Apr 2015 09:46:08 +1000 NeilBrown <neilb@suse.de> wrote:
> On Fri, 3 Apr 2015 19:22:15 -0700 "Jonathan Harker (Jesusaurus)"
> <jesusaurus@gentlydownthe.net> wrote:
>
> >
> > Third, is it possible to resume the reshape? If not, can it be reverted?
> >
>
> I'll have to get back to you on that. Hopefully you can be patient a little
> longer.
>
> NeilBrown
>
>
Hi again Jonathan,
please report what version of mdadm and of Linux that you are running.
Also is there any chance that you tried
mdadm --assemble .... --update=revert-reshape
??
And if you did, why didn't you say so :-)
NeilBrown
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: Can't mount partitions after "mdadm --zero-superblock"
From: Eduard Rozenberg @ 2015-04-07 1:33 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <20150407105230.4ff9a97a@notabene.brown>
Thanks very much Neil!
I never do anything forward thinking like mdadm —examine before
doing destructive things :). Unfortunately.
I couldn’t figure out how to make the offset work so I used
losetup -f --show -P /dev/sdac
which automatically creates:
/dev/loop0
/dev/loop0p1
/dev/loop0p2
/dev/loop0p3
/dev/loop0p4
/dev/loop0p5
/dev/loop0p6
/dev/loop0p7
/dev/loop0p7
/dev/loop0p8
But the errors are the same (below). No idea why it thinks
NTFS is involved. I’ll probably have to give up on
this and figure out how to get way better at backups because
my history of success with recovery once things get hosed
in some way is very poor.
[root@repo1 ~]# fsck.ext4 /dev/loop0p2
e2fsck 1.42.8 (20-Jun-2013)
ext2fs_open2: Bad magic number in super-block
/sbin/e2fsck: Superblock invalid, trying backup blocks...
/sbin/e2fsck: Bad magic number in super-block while trying to open /dev/loop0p2
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
======
mount -o ro /dev/loop0p2 /mnt
Failed to mount '/dev/loop0p2': Invalid argument
The device '/dev/loop0p2' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
mount -o ro /dev/loop0p3 /mnt
NTFS signature is missing.
Failed to mount '/dev/loop0p3': Invalid argument
The device '/dev/loop0p3' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
Regards,
—Ed
> On Apr 6, 2015, at 17:52, NeilBrown <neilb@suse.de> wrote:
>
> On Mon, 6 Apr 2015 16:45:58 -0700 Eduard Rozenberg <eduardr@pobox.com> wrote:
>
>> Hello folks,
>>
>> I previously had the following setup:
>>
>> sda & sdb partitioned w/ GPT, 7 partitions each (usr, opt, var etc...)
>> 7 raid1’s with 2 devices for each pair of partitions (/dev/sda1 & /dev/sdab1, etc)
>> They’d been created under Slackware 13.37.
>>
>> I was trying to clean out mdadm from those partitions but keep the data so I ran
>> "mdadm --zero-superblock” on each of those previously RAID1 mdadm 1.2 ext4
>> partitions.
>
> The "1.2" metadata is stored 4k from the start of the device. The actual
> data is some megabytes further in. I don't suppose you still have the output
> of "mdadm --examine" from before you destroyed the superblocks??
>
>>
>> As a result I am now currently unable to mount any partition after the first one on either
>> disk. The first partition does mount. The partition table is visible and looks fine in gdisk.
>>
>> mount -t ext4 /dev/sdac2 /mnt
>> mount: wrong fs type, bad option, bad superblock on /dev/sdac2,
>> missing codepage or helper program, or other error
>> In some cases useful info is found in syslog - try
>> dmesg | tail or so
>>
>> I did try superblock recovery with each backup superblock that ext4 normally creates,
>> but none of the superblock locations worked.
>>
>> For example:
>>
>> fsck.ext4 -b 4096000 /dev/sdac2
>> e2fsck 1.42.8 (20-Jun-2013)
>> /sbin/e2fsck: Invalid argument while trying to open /dev/sdac2
>>
>> The superblock could not be read or does not describe a correct ext2
>> filesystem. If the device is valid and it really contains an ext2
>> filesystem (and not swap or ufs or something else), then the superblock
>> is corrupt, and you might try running e2fsck with an alternate superblock:
>> e2fsck -b 8193 <device>
>>
>>
>> Would be grateful for any advice on anything else I can try.
>
> You need to find where the filesystem actually starts, then you need to
> create some way to access it as a block device, then it should "just work".
>
> An ext4 filesystem superblock has 0xef53 at an offset of 0x38, and the
> superblock is typically 1K from the start of the partition.
>
> So you could:
> od -x /dev/sdac2 | awk '$6 == "ef53"'
>
> Then subtrace 0002060 (octal) from the leading number, and that might be the
> start of the partition.
>
> Then
> losetup -o "start in decimal" /dev/loop0 /dev/sdac2
>
> and try 'fsck' on /dev/loop0
>
> Good luck.
>
> NeilBrown
>
>
>
>>
>> Regards,
>> —Ed--
>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: write barrier in RAID5
From: NeilBrown @ 2015-04-07 1:25 UTC (permalink / raw)
To: Eric Mei; +Cc: linux-raid
In-Reply-To: <551C37E6.6090201@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1236 bytes --]
On Wed, 01 Apr 2015 12:24:38 -0600 Eric Mei <meijia@gmail.com> wrote:
> I can see how FUA is handled, but REQ_FLUSH seems problematic. My
> understanding of REQ_FLUSH semantics: all requests before the flush
> request must *complete* before the flush request complete. For IO remap
> layer like MD, we need to guarantee all previous requests are
> *submitted* to component devices before submitting the flush request. Is
> that correct?
No.
See Documentation/block/writeback_cache_control.txt
Only "previously completed" requests are affect by REQ_FLUSH.
So any code using REQ_FLUSH must first wait for previous requests to
complete, and then submit REQ_FLUSH. The REQ_FLUSH will not return until the
data written by those requests is actually in stable storage, rather than
write-behind cache.
NeilBrown
>
> If so why I don't see the code which make sure the pending write
> requests in stripe cache are processed & submitted before
> submit_flushes() get called? Thanks
>
> Eric
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: openSUSE 13.2: md - Need advice which raid1 super format (1.0/1.2) is preferred
From: NeilBrown @ 2015-04-07 1:14 UTC (permalink / raw)
To: Dieter Nützel; +Cc: linux-raid
In-Reply-To: <309b2c5704621339acbe84a19d84f766@mail.ud03.udmedia.de>
[-- Attachment #1: Type: text/plain, Size: 1839 bytes --]
On Wed, 01 Apr 2015 01:55:18 +0200 Dieter Nützel <Dieter@nuetzel-hh.de> wrote:
> Hello List,
>
> I need advice from the 'gurus' which raid1 md super format (1.0 or 1.2)
> is preferred for SSD/'old' SATA disks.
It depends on what you want.
If you want the filesystem in the partition to be visible without configuring
RAID, then 1.0.
If you explicitly don't. i.e. you don't see the filesystem until you
assemble the raid1, then 1.2.
Personally, I prefer 1.2, but your needs might be different.
If you boot off the raid1 array, then your boot loader might have a
preference.
NeilBrown
>
> Currently I have this on my gfx devel machine (Xeon X3430):
>
> cat /proc/mdstat
> Personalities : [raid1]
> md2 : active raid1 sdc1[0] sdd1[1]
> 156288896 blocks super 1.0 [2/2] [UU]
> bitmap: 0/2 pages [0KB], 65536KB chunk
>
> md1 : active raid1 sdb2[1] sda2[0]
> 60391744 blocks super 1.2 [2/2] [UU]
>
> md0 : active raid1 sdb1[1] sda1[0]
> 2095104 blocks super 1.2 [2/2] [UU]
>
> unused devices: <none>
>
> md0 and md1
> are on my SSD's which I've created by 'hand' (with mdadm) under openSUSE
> 13.2.
>
> md2
> is on my SATAs which I've created 'automatically' under yast2.
>
> My question to you is:
> Looks this sane (chunk only for super 1.0 on real SATAs and super 1.2 on
> SSDs) or should I change anything, here.
>
> I'll nuke md0 (swap) and merge it with md1 (root) 'cause I've upgraded
> my RAM from 4 GB to 16 GB (soon to 24/32 GB max) and do not need swap
> anylonger.
>
> Any hints?
>
> -Dieter
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: multi-threaded raid5
From: NeilBrown @ 2015-04-07 1:11 UTC (permalink / raw)
To: stkoupr; +Cc: linux-raid
In-Reply-To: <551AD6AE.4030607@cra.cz>
[-- Attachment #1: Type: text/plain, Size: 879 bytes --]
On Tue, 31 Mar 2015 19:17:34 +0200 stkoupr <p.kouril@cra.cz> wrote:
> Hi,
>
> We are testing write performance of md raid5 with SSD array and we are
> hitting limit which I understand is caused by writes being handled in
> single thread (md0_raid5 process is eating 100% of 1 CPU core when the
> test is running). I understood that there is some work in progress which
> should make write handling multi-threaded. I'd like to ask about the
> status of this work, is it still in progress or planned?
>
> Regards,
> Prema
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
See /sys/block/mdXXX/md/group_thread_cnt
Set it to a bigger number, get more threads.
Requires 3.12 or later.
NeilBrown
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: Can't mount partitions after "mdadm --zero-superblock"
From: NeilBrown @ 2015-04-07 0:52 UTC (permalink / raw)
To: Eduard Rozenberg; +Cc: linux-raid
In-Reply-To: <F271C907-A2A7-4132-BA11-D33353AE9FFF@pobox.com>
[-- Attachment #1: Type: text/plain, Size: 2697 bytes --]
On Mon, 6 Apr 2015 16:45:58 -0700 Eduard Rozenberg <eduardr@pobox.com> wrote:
> Hello folks,
>
> I previously had the following setup:
>
> sda & sdb partitioned w/ GPT, 7 partitions each (usr, opt, var etc...)
> 7 raid1’s with 2 devices for each pair of partitions (/dev/sda1 & /dev/sdab1, etc)
> They’d been created under Slackware 13.37.
>
> I was trying to clean out mdadm from those partitions but keep the data so I ran
> "mdadm --zero-superblock” on each of those previously RAID1 mdadm 1.2 ext4
> partitions.
The "1.2" metadata is stored 4k from the start of the device. The actual
data is some megabytes further in. I don't suppose you still have the output
of "mdadm --examine" from before you destroyed the superblocks??
>
> As a result I am now currently unable to mount any partition after the first one on either
> disk. The first partition does mount. The partition table is visible and looks fine in gdisk.
>
> mount -t ext4 /dev/sdac2 /mnt
> mount: wrong fs type, bad option, bad superblock on /dev/sdac2,
> missing codepage or helper program, or other error
> In some cases useful info is found in syslog - try
> dmesg | tail or so
>
> I did try superblock recovery with each backup superblock that ext4 normally creates,
> but none of the superblock locations worked.
>
> For example:
>
> fsck.ext4 -b 4096000 /dev/sdac2
> e2fsck 1.42.8 (20-Jun-2013)
> /sbin/e2fsck: Invalid argument while trying to open /dev/sdac2
>
> The superblock could not be read or does not describe a correct ext2
> filesystem. If the device is valid and it really contains an ext2
> filesystem (and not swap or ufs or something else), then the superblock
> is corrupt, and you might try running e2fsck with an alternate superblock:
> e2fsck -b 8193 <device>
>
>
> Would be grateful for any advice on anything else I can try.
You need to find where the filesystem actually starts, then you need to
create some way to access it as a block device, then it should "just work".
An ext4 filesystem superblock has 0xef53 at an offset of 0x38, and the
superblock is typically 1K from the start of the partition.
So you could:
od -x /dev/sdac2 | awk '$6 == "ef53"'
Then subtrace 0002060 (octal) from the leading number, and that might be the
start of the partition.
Then
losetup -o "start in decimal" /dev/loop0 /dev/sdac2
and try 'fsck' on /dev/loop0
Good luck.
NeilBrown
>
> Regards,
> —Ed--
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: Help recovering an interrupted raid0 reshape
From: NeilBrown @ 2015-04-06 23:46 UTC (permalink / raw)
To: Jonathan Harker (Jesusaurus); +Cc: linux-raid
In-Reply-To: <CAC_83AFDEijn-7gNmnWNNabzcuPRMabNwr8xfRFt0xacsvZfog@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7552 bytes --]
On Fri, 3 Apr 2015 19:22:15 -0700 "Jonathan Harker (Jesusaurus)"
<jesusaurus@gentlydownthe.net> wrote:
> I have a raid0 array whose component devices are raid1 arrays. In an
> attempt to expand the pre-existing raid0 array, I created a new raid1
> device and then added it, growing the raid0 array.
> But then the system lost power shortly after the reshaping began.
>
> After rebooting the original two components are listed as spares in an
> inactive raid4 array and the new component is not listed in
> /proc/mdstat:
>
>
> Personalities : [raid6] [raid5] [raid4] [raid1] [raid10] [raid0]
> [linear] [multipath]
> md124 : inactive md126[0](S) md127[1](S)
> 3907022200 blocks super 1.2
>
> md0 : active raid1 sda5[0] sdb2[1]
> 107652416 blocks [2/2] [UU]
> bitmap: 1/1 pages [4KB], 65536KB chunk
>
> md125 : active raid1 sdh1[0] sdg1[1]
> 2930134016 blocks super 1.2 [2/2] [UU]
> bitmap: 0/22 pages [0KB], 65536KB chunk
>
> md126 : active raid1 sdc1[0] sdd1[1]
> 1953512312 blocks super 1.2 [2/2] [UU]
>
> md127 : active raid1 sde1[2] sdf1[1]
> 1953512312 blocks super 1.2 [2/2] [UU]
>
> unused devices: <none>
>
>
> Looking at the details of the inactive array shows that it is in a
> reshape between raid0 and raid4:
>
>
> /dev/md124:
> Version : 1.2
> Raid Level : raid0
> Total Devices : 2
> Persistence : Superblock is persistent
>
> State : inactive
>
> Delta Devices : -1, (1->0)
> New Level : raid4
> New Chunksize : 512K
>
> Name : hordern:hordern1 (local to host hordern)
> UUID : 1f4979ba:c49a77c0:59e689c2:bcc21c0a
> Events : 14013
>
> Number Major Minor RaidDevice
>
> - 9 126 - /dev/md/beta
> - 9 127 - /dev/md/alpha
>
>
> And examining each component shows that they have a consistent view of
> where in that reshape they are (based on the reshape position), but
> not consistent in the size of the array:
>
> /dev/md/alpha:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x4
> Array UUID : 1f4979ba:c49a77c0:59e689c2:bcc21c0a
> Name : hordern:hordern1 (local to host hordern)
> Creation Time : Fri Jan 2 09:59:40 2009
> Raid Level : raid4
> Raid Devices : 3
>
> Avail Dev Size : 3907021824 (1863.01 GiB 2000.40 GB)
> Array Size : 3907021824 (3726.03 GiB 4000.79 GB)
> Data Offset : 2048 sectors
> Super Offset : 8 sectors
> Unused Space : before=1968 sectors, after=752 sectors
> State : active
> Device UUID : 63aaa2e4:2a09f495:8372c7f9:eb2f2773
>
> Reshape pos'n : 129067008 (123.09 GiB 132.16 GB)
> Delta Devices : -1 (4->3)
>
> Update Time : Sun Mar 29 15:11:35 2015
> Checksum : 8be5e0e6 - correct
> Events : 14013
>
> Chunk Size : 512K
>
> Device Role : Active device 1
> Array State : AA.. ('A' == active, '.' == missing, 'R' == replacing)
> /dev/md/beta:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x4
> Array UUID : 1f4979ba:c49a77c0:59e689c2:bcc21c0a
> Name : hordern:hordern1 (local to host hordern)
> Creation Time : Fri Jan 2 09:59:40 2009
> Raid Level : raid4
> Raid Devices : 3
>
> Avail Dev Size : 3907022576 (1863.01 GiB 2000.40 GB)
> Array Size : 3907021824 (3726.03 GiB 4000.79 GB)
> Used Dev Size : 3907021824 (1863.01 GiB 2000.40 GB)
> Data Offset : 2048 sectors
> Super Offset : 8 sectors
> Unused Space : before=1968 sectors, after=752 sectors
> State : clean
> Device UUID : 6e6dce14:3ebb2bb5:187aa292:403a55f6
>
> Reshape pos'n : 129067008 (123.09 GiB 132.16 GB)
> Delta Devices : -1 (4->3)
>
> Update Time : Sun Mar 29 15:11:35 2015
> Checksum : f7526add - correct
> Events : 14013
>
> Chunk Size : 512K
>
> Device Role : Active device 0
> Array State : AA.. ('A' == active, '.' == missing, 'R' == replacing)
> /dev/md/gamma:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x6
> Array UUID : 1f4979ba:c49a77c0:59e689c2:bcc21c0a
> Name : hordern:hordern1 (local to host hordern)
> Creation Time : Fri Jan 2 09:59:40 2009
> Raid Level : raid4
> Raid Devices : 4
>
> Avail Dev Size : 5860265984 (2794.39 GiB 3000.46 GB)
> Array Size : 5860532736 (5589.04 GiB 6001.19 GB)
> Used Dev Size : 3907021824 (1863.01 GiB 2000.40 GB)
> Data Offset : 2048 sectors
> Super Offset : 8 sectors
> Recovery Offset : 86403072 sectors
> Unused Space : before=1960 sectors, after=1953244160 sectors
> State : active
> Device UUID : 782873ea:e265ecd4:5cc80ddf:035ba2b4
>
> Reshape pos'n : 129067008 (123.09 GiB 132.16 GB)
> Delta Devices : 1 (3->4)
>
> Update Time : Sun Mar 29 00:05:29 2015
> Bad Block Log : 512 entries available at offset 72 sectors
> Checksum : 710dc078 - correct
> Events : 673
>
> Chunk Size : 512K
>
> Device Role : Active device 2
> Array State : AAA. ('A' == active, '.' == missing, 'R' == replacing)
>
>
> When I stop the inactive array and try to assemble it from all three
> components, I get an error about the superblock on the third component
> not matching the other two components (which makes sense since the
> array sizes are different):
>
> hordern ~ # mdadm --verbose --verbose --assemble /dev/md/hordern1
> /dev/md/alpha /dev/md/beta /dev/md/gamma
> mdadm: looking for devices for /dev/md/hordern1
> mdadm: UUID differs from /dev/md0.
> mdadm: UUID differs from /dev/md/alpha.
> mdadm: UUID differs from /dev/md/beta.
> mdadm: UUID differs from /dev/md/gamma.
> mdadm: UUID differs from /dev/md0.
> mdadm: UUID differs from /dev/md/alpha.
> mdadm: UUID differs from /dev/md/beta.
> mdadm: UUID differs from /dev/md/gamma.
> mdadm: UUID differs from /dev/md0.
> mdadm: UUID differs from /dev/md/alpha.
> mdadm: UUID differs from /dev/md/beta.
> mdadm: UUID differs from /dev/md/gamma.
> mdadm: superblock on /dev/md/gamma doesn't match others - assembly aborted
>
>
> First, what could cause the initial two components to have a different
> superblock than the newly added component? And can I convince them to
> be the same?
Good question. The important difference is this line:
> Delta Devices : -1 (4->3)
> Delta Devices : 1 (3->4)
Also "Raid Devices" are different. This is what leads to the array size
being reported differently.
I don't know why this happened. I'll have to hunt through the code.
>
> Second, is there documentation anywhere about the internal process of
> growing a raid0 array? Why does it convert to a raid4 array? And what
> do the Delta Devices lines mean?
- no documentation like that
- the "raid0" module does support reshape. The "raid5" module does.
So the array is converted to a RAID4 with a missing parity device, then
reshaped, then converted back. It is just an internal detail really.
- "Delta devices" means that there is reshape happening that is changing
then number of devices - "delta" is a difference.
It is clearly confused.
>
> Third, is it possible to resume the reshape? If not, can it be reverted?
>
I'll have to get back to you on that. Hopefully you can be patient a little
longer.
NeilBrown
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Can't mount partitions after "mdadm --zero-superblock"
From: Eduard Rozenberg @ 2015-04-06 23:45 UTC (permalink / raw)
To: linux-raid
Hello folks,
I previously had the following setup:
sda & sdb partitioned w/ GPT, 7 partitions each (usr, opt, var etc...)
7 raid1’s with 2 devices for each pair of partitions (/dev/sda1 & /dev/sdab1, etc)
They’d been created under Slackware 13.37.
I was trying to clean out mdadm from those partitions but keep the data so I ran
"mdadm --zero-superblock” on each of those previously RAID1 mdadm 1.2 ext4
partitions.
As a result I am now currently unable to mount any partition after the first one on either
disk. The first partition does mount. The partition table is visible and looks fine in gdisk.
mount -t ext4 /dev/sdac2 /mnt
mount: wrong fs type, bad option, bad superblock on /dev/sdac2,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
I did try superblock recovery with each backup superblock that ext4 normally creates,
but none of the superblock locations worked.
For example:
fsck.ext4 -b 4096000 /dev/sdac2
e2fsck 1.42.8 (20-Jun-2013)
/sbin/e2fsck: Invalid argument while trying to open /dev/sdac2
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
Would be grateful for any advice on anything else I can try.
Regards,
—Ed--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Recovery of RAID 6 after three rapid disk events (disks are still working)
From: NeilBrown @ 2015-04-06 23:33 UTC (permalink / raw)
To: Mike; +Cc: linux-raid
In-Reply-To: <104310d53affd63c6e13088daa8dd5f2@zeus.bigmiketrading.com>
[-- Attachment #1: Type: text/plain, Size: 912 bytes --]
On Mon, 06 Apr 2015 18:28:55 -0500 Mike <mboulter@gmail.com> wrote:
> Hi guys,
>
> mdadm 3.2.5, 14 disk RAID 6
>
> Had a drive failure Friday. Two more today in rapid succession. All
> drives seem fully operational.
>
> This is roughly 40TB array, I could use your help please to rescue the
> array.
>
> All members are on partition 2 of each physical disk.
>
> # mdadm --assemble --scan
Add "--force" to that line, and it will work.
In this context, "--force" means "yes, I know that some devices are a bit out
of date and that that if there was a write happening while one of the devices
appeared to fail then there could be some corruption of a few blocks in the
array, but I want all the rest of the data and I promise to be careful and I
won't assume that everything is perfect and I won't blame you if a few files
are lost - just do what you can. Please."
NeilBrown
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Recovery of RAID 6 after three rapid disk events (disks are still working)
From: Mike @ 2015-04-06 23:28 UTC (permalink / raw)
To: linux-raid
Hi guys,
mdadm 3.2.5, 14 disk RAID 6
Had a drive failure Friday. Two more today in rapid succession. All
drives seem fully operational.
This is roughly 40TB array, I could use your help please to rescue the
array.
All members are on partition 2 of each physical disk.
# mdadm --assemble --scan
mdadm: /dev/md/media:0 assembled from 11 drives - not enough to start
the array.
mdadm: No arrays found in config file or automatically
# mdadm --assemble --scan --verbose
mdadm: looking for devices for further assembly
mdadm: no recogniseable superblock on /dev/loop0
mdadm: Cannot assemble mbr metadata on /dev/sdo1
mdadm: Cannot assemble mbr metadata on /dev/sdo
mdadm: no RAID superblock on /dev/sdm1
mdadm: no RAID superblock on /dev/sdm
mdadm: no RAID superblock on /dev/sdn1
mdadm: no RAID superblock on /dev/sdn
mdadm: no RAID superblock on /dev/sdj1
mdadm: no RAID superblock on /dev/sdj
mdadm: no RAID superblock on /dev/sdk1
mdadm: no RAID superblock on /dev/sdk
mdadm: no RAID superblock on /dev/sdl1
mdadm: no RAID superblock on /dev/sdl
mdadm: no RAID superblock on /dev/sdi1
mdadm: no RAID superblock on /dev/sdi
mdadm: no RAID superblock on /dev/sdh1
mdadm: no RAID superblock on /dev/sdh
mdadm: no RAID superblock on /dev/sdb1
mdadm: no RAID superblock on /dev/sdb
mdadm: no RAID superblock on /dev/sda1
mdadm: no RAID superblock on /dev/sda
mdadm: no RAID superblock on /dev/sdf1
mdadm: no RAID superblock on /dev/sdf
mdadm: no RAID superblock on /dev/sdd1
mdadm: no RAID superblock on /dev/sdd
mdadm: no RAID superblock on /dev/sdc1
mdadm: no RAID superblock on /dev/sdc
mdadm: no RAID superblock on /dev/sdg1
mdadm: no RAID superblock on /dev/sdg
mdadm: no RAID superblock on /dev/sde1
mdadm: no RAID superblock on /dev/sde
mdadm: /dev/sdm2 is identified as a member of /dev/md/media:0, slot 3.
mdadm: /dev/sdn2 is identified as a member of /dev/md/media:0, slot 8.
mdadm: /dev/sdj2 is identified as a member of /dev/md/media:0, slot 5.
mdadm: /dev/sdk2 is identified as a member of /dev/md/media:0, slot 11.
mdadm: /dev/sdl2 is identified as a member of /dev/md/media:0, slot 4.
mdadm: /dev/sdi2 is identified as a member of /dev/md/media:0, slot 7.
mdadm: /dev/sdh2 is identified as a member of /dev/md/media:0, slot 1.
mdadm: /dev/sdb2 is identified as a member of /dev/md/media:0, slot 6.
mdadm: /dev/sda2 is identified as a member of /dev/md/media:0, slot 13.
mdadm: /dev/sdf2 is identified as a member of /dev/md/media:0, slot 2.
mdadm: /dev/sdd2 is identified as a member of /dev/md/media:0, slot 9.
mdadm: /dev/sdc2 is identified as a member of /dev/md/media:0, slot 6.
mdadm: /dev/sdg2 is identified as a member of /dev/md/media:0, slot 12.
mdadm: /dev/sde2 is identified as a member of /dev/md/media:0, slot 0.
mdadm: added /dev/sdh2 to /dev/md/media:0 as 1
mdadm: added /dev/sdf2 to /dev/md/media:0 as 2
mdadm: added /dev/sdm2 to /dev/md/media:0 as 3
mdadm: added /dev/sdl2 to /dev/md/media:0 as 4
mdadm: added /dev/sdj2 to /dev/md/media:0 as 5
mdadm: added /dev/sdc2 to /dev/md/media:0 as 6 (possibly out of date)
mdadm: added /dev/sdi2 to /dev/md/media:0 as 7
mdadm: added /dev/sdn2 to /dev/md/media:0 as 8
mdadm: added /dev/sdd2 to /dev/md/media:0 as 9 (possibly out of date)
mdadm: no uptodate device for slot 10 of /dev/md/media:0
mdadm: added /dev/sdk2 to /dev/md/media:0 as 11
mdadm: added /dev/sdg2 to /dev/md/media:0 as 12
mdadm: added /dev/sda2 to /dev/md/media:0 as 13
mdadm: added /dev/sde2 to /dev/md/media:0 as 0
mdadm: /dev/md/media:0 assembled from 11 drives - not enough to start
the array.
mdadm: looking for devices for further assembly
mdadm: No arrays found in config file or automatically
# mdadm --examine /dev/sd?2 --verbose
/dev/sda2:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : b1c40379:914e5d18:dddb893b:4dc5a28f
Name : media:0
Creation Time : Wed Nov 7 22:06:02 2012
Raid Level : raid6
Raid Devices : 14
Avail Dev Size : 5860265984 (2794.39 GiB 3000.46 GB)
Array Size : 35160446976 (33531.62 GiB 36004.30 GB)
Used Dev Size : 5860074496 (2794.30 GiB 3000.36 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 822fd02b:454da94c:57f68535:964996b1
Update Time : Mon Apr 6 19:19:53 2015
Checksum : 8e7a48ab - correct
Events : 2384973
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 13
Array State : AAAAAA.AA..AAA ('A' == active, '.' == missing)
/dev/sdb2:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x2
Array UUID : b1c40379:914e5d18:dddb893b:4dc5a28f
Name : media:0
Creation Time : Wed Nov 7 22:06:02 2012
Raid Level : raid6
Raid Devices : 14
Avail Dev Size : 5860265984 (2794.39 GiB 3000.46 GB)
Array Size : 35160446976 (33531.62 GiB 36004.30 GB)
Used Dev Size : 5860074496 (2794.30 GiB 3000.36 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Recovery Offset : 0 sectors
State : clean
Device UUID : 5c4a1046:c232402c:45f1c604:569f6896
Update Time : Mon Apr 6 16:12:05 2015
Checksum : 3c7663c2 - correct
Events : 2382358
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 6
Array State : AAAAAAAAAA.AAA ('A' == active, '.' == missing)
/dev/sdc2:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x2
Array UUID : b1c40379:914e5d18:dddb893b:4dc5a28f
Name : media:0
Creation Time : Wed Nov 7 22:06:02 2012
Raid Level : raid6
Raid Devices : 14
Avail Dev Size : 5860265984 (2794.39 GiB 3000.46 GB)
Array Size : 35160446976 (33531.62 GiB 36004.30 GB)
Used Dev Size : 5860074496 (2794.30 GiB 3000.36 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Recovery Offset : 0 sectors
State : clean
Device UUID : e211f88d:5c355522:fbeb7134:16b17684
Update Time : Mon Apr 6 16:28:09 2015
Checksum : 982c3e96 - correct
Events : 2382480
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 6
Array State : AAAAAAAAAA.AAA ('A' == active, '.' == missing)
/dev/sdd2:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : b1c40379:914e5d18:dddb893b:4dc5a28f
Name : media:0
Creation Time : Wed Nov 7 22:06:02 2012
Raid Level : raid6
Raid Devices : 14
Avail Dev Size : 5860265984 (2794.39 GiB 3000.46 GB)
Array Size : 35160446976 (33531.62 GiB 36004.30 GB)
Used Dev Size : 5860074496 (2794.30 GiB 3000.36 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : active
Device UUID : de3f41b8:3016870c:344f2a92:c08e1085
Update Time : Mon Apr 6 19:19:34 2015
Checksum : af2bfdb - correct
Events : 2384965
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 9
Array State : AAAAAA.AAA.AAA ('A' == active, '.' == missing)
/dev/sde2:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : b1c40379:914e5d18:dddb893b:4dc5a28f
Name : media:0
Creation Time : Wed Nov 7 22:06:02 2012
Raid Level : raid6
Raid Devices : 14
Avail Dev Size : 5860265984 (2794.39 GiB 3000.46 GB)
Array Size : 35160446976 (33531.62 GiB 36004.30 GB)
Used Dev Size : 5860074496 (2794.30 GiB 3000.36 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 071afb12:f78f4f15:f65aa629:8eadcfa7
Update Time : Mon Apr 6 19:19:53 2015
Checksum : 28a53e70 - correct
Events : 2384973
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 0
Array State : AAAAAA.AA..AAA ('A' == active, '.' == missing)
/dev/sdf2:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : b1c40379:914e5d18:dddb893b:4dc5a28f
Name : media:0
Creation Time : Wed Nov 7 22:06:02 2012
Raid Level : raid6
Raid Devices : 14
Avail Dev Size : 5860265984 (2794.39 GiB 3000.46 GB)
Array Size : 35160446976 (33531.62 GiB 36004.30 GB)
Used Dev Size : 5860074496 (2794.30 GiB 3000.36 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : e319bdaa:22bc1153:c43b4878:8a9c1832
Update Time : Mon Apr 6 19:19:53 2015
Checksum : d7143a42 - correct
Events : 2384973
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 2
Array State : AAAAAA.AA..AAA ('A' == active, '.' == missing)
/dev/sdg2:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : b1c40379:914e5d18:dddb893b:4dc5a28f
Name : media:0
Creation Time : Wed Nov 7 22:06:02 2012
Raid Level : raid6
Raid Devices : 14
Avail Dev Size : 5860265984 (2794.39 GiB 3000.46 GB)
Array Size : 35160446976 (33531.62 GiB 36004.30 GB)
Used Dev Size : 5860074496 (2794.30 GiB 3000.36 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : f5477580:94357948:6e97fe82:c8805bcd
Update Time : Mon Apr 6 19:19:53 2015
Checksum : 482d21b8 - correct
Events : 2384973
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 12
Array State : AAAAAA.AA..AAA ('A' == active, '.' == missing)
/dev/sdh2:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : b1c40379:914e5d18:dddb893b:4dc5a28f
Name : media:0
Creation Time : Wed Nov 7 22:06:02 2012
Raid Level : raid6
Raid Devices : 14
Avail Dev Size : 5860265984 (2794.39 GiB 3000.46 GB)
Array Size : 35160446976 (33531.62 GiB 36004.30 GB)
Used Dev Size : 5860074496 (2794.30 GiB 3000.36 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 3dd1df1b:203c6453:0964ebad:245b1670
Update Time : Mon Apr 6 19:19:53 2015
Checksum : bc2a587a - correct
Events : 2384973
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AAAAAA.AA..AAA ('A' == active, '.' == missing)
/dev/sdi2:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : b1c40379:914e5d18:dddb893b:4dc5a28f
Name : media:0
Creation Time : Wed Nov 7 22:06:02 2012
Raid Level : raid6
Raid Devices : 14
Avail Dev Size : 5860265984 (2794.39 GiB 3000.46 GB)
Array Size : 35160446976 (33531.62 GiB 36004.30 GB)
Used Dev Size : 5860074496 (2794.30 GiB 3000.36 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 4a013330:37c565f9:cb761d35:7ce4ddb4
Update Time : Mon Apr 6 19:19:53 2015
Checksum : 4278adbb - correct
Events : 2384973
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 7
Array State : AAAAAA.AA..AAA ('A' == active, '.' == missing)
/dev/sdj2:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : b1c40379:914e5d18:dddb893b:4dc5a28f
Name : media:0
Creation Time : Wed Nov 7 22:06:02 2012
Raid Level : raid6
Raid Devices : 14
Avail Dev Size : 5860265984 (2794.39 GiB 3000.46 GB)
Array Size : 35160446976 (33531.62 GiB 36004.30 GB)
Used Dev Size : 5860074496 (2794.30 GiB 3000.36 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : d5521994:6c4f04f9:f7ca0dd9:dff3c6cd
Update Time : Mon Apr 6 19:19:53 2015
Checksum : 62d6ed06 - correct
Events : 2384973
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 5
Array State : AAAAAA.AA..AAA ('A' == active, '.' == missing)
/dev/sdk2:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : b1c40379:914e5d18:dddb893b:4dc5a28f
Name : media:0
Creation Time : Wed Nov 7 22:06:02 2012
Raid Level : raid6
Raid Devices : 14
Avail Dev Size : 5860265984 (2794.39 GiB 3000.46 GB)
Array Size : 35160446976 (33531.62 GiB 36004.30 GB)
Used Dev Size : 5860074496 (2794.30 GiB 3000.36 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : c1514b9f:24616fed:324a50fb:9469043a
Update Time : Mon Apr 6 19:19:53 2015
Checksum : f0f3f2a5 - correct
Events : 2384973
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 11
Array State : AAAAAA.AA..AAA ('A' == active, '.' == missing)
/dev/sdl2:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : b1c40379:914e5d18:dddb893b:4dc5a28f
Name : media:0
Creation Time : Wed Nov 7 22:06:02 2012
Raid Level : raid6
Raid Devices : 14
Avail Dev Size : 5860265984 (2794.39 GiB 3000.46 GB)
Array Size : 35160446976 (33531.62 GiB 36004.30 GB)
Used Dev Size : 5860074496 (2794.30 GiB 3000.36 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 6c33c472:af1ffd8f:22d10ea3:9edc75bb
Update Time : Mon Apr 6 19:19:53 2015
Checksum : 902a8ccd - correct
Events : 2384973
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 4
Array State : AAAAAA.AA..AAA ('A' == active, '.' == missing)
/dev/sdm2:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : b1c40379:914e5d18:dddb893b:4dc5a28f
Name : media:0
Creation Time : Wed Nov 7 22:06:02 2012
Raid Level : raid6
Raid Devices : 14
Avail Dev Size : 5860265984 (2794.39 GiB 3000.46 GB)
Array Size : 35160446976 (33531.62 GiB 36004.30 GB)
Used Dev Size : 5860074496 (2794.30 GiB 3000.36 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : b750b4e4:2b1bac5f:cbd3bde5:eab657e7
Update Time : Mon Apr 6 19:19:53 2015
Checksum : 405a828f - correct
Events : 2384973
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 3
Array State : AAAAAA.AA..AAA ('A' == active, '.' == missing)
/dev/sdn2:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : b1c40379:914e5d18:dddb893b:4dc5a28f
Name : media:0
Creation Time : Wed Nov 7 22:06:02 2012
Raid Level : raid6
Raid Devices : 14
Avail Dev Size : 5860265984 (2794.39 GiB 3000.46 GB)
Array Size : 35160446976 (33531.62 GiB 36004.30 GB)
Used Dev Size : 5860074496 (2794.30 GiB 3000.36 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 4670b36c:07cbe661:20e3d314:f7c3fd42
Update Time : Mon Apr 6 19:19:53 2015
Checksum : 55506e59 - correct
Events : 2384973
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 8
Array State : AAAAAA.AA..AAA ('A' == active, '.' == missing)
--
Mike
^ permalink raw reply
* Re: [PATCH 0/3] dm-crypt: Adds support for wiping key when doing suspend/hibernation
From: Pali Rohár @ 2015-04-06 21:27 UTC (permalink / raw)
To: Pavel Machek
Cc: Mike Snitzer, Alasdair Kergon, Neil Brown, Rafael J. Wysocki,
Len Brown, dm-devel, linux-raid, linux-kernel, linux-pm
In-Reply-To: <20150406181738.GC9978@amd>
[-- Attachment #1: Type: Text/Plain, Size: 3337 bytes --]
On Monday 06 April 2015 20:17:38 Pavel Machek wrote:
> On Mon 2015-04-06 15:29:57, Pali Rohár wrote:
> > On Monday 06 April 2015 15:00:46 Mike Snitzer wrote:
> > > On Sun, Apr 05 2015 at 1:20pm -0400,
> > >
> > > Pali Rohár <pali.rohar@gmail.com> wrote:
> > > > This patch series increase security of suspend and
> > > > hibernate actions. It allows user to safely wipe crypto
> > > > keys before suspend and hibernate actions starts
> > > > without race conditions on userspace process with heavy
> > > > I/O.
> > > >
> > > > To automatically wipe cryto key for <device> before
> > > > hibernate action call: $ dmsetup message <device> 0 key
> > > > wipe_on_hibernation 1
> > > >
> > > > To automatically wipe cryto key for <device> before
> > > > suspend action call: $ dmsetup message <device> 0 key
> > > > wipe_on_suspend 1
> > > >
> > > > (Value 0 after wipe_* string reverts original behaviour
> > > > - to not wipe key)
> > >
> > > Can you elaborate on the attack vector your changes are
> > > meant to protect against? The user already authorized
> > > access, why is it inherently dangerous to _not_ wipe the
> > > associated key across these events?
> >
> > Hi,
> >
> > yes, I will try to explain current problems with cryptsetup
> > luksSuspend command and hibernation.
> >
> > First, sometimes it is needed to put machine into other
> > hands. You can still watch other person what is doing with
> > machine, but once if you let machine unlocked (e.g opened
> > luks disk), she/he can access encrypted data.
> >
> > If you turn off machine, it could be safe, because luks disk
> > devices are locked. But if you enter machine into suspend or
> > hibernate state luks devices are still open. And my patches
> > try to achieve similar security as when machine is off (=
> > no crypto keys in RAM or on swap).
> >
> > When doing hibernate on unencrypted swap it is to prevent
> > leaking crypto keys to hibernate image (which is stored in
> > swap).
> >
> > When doing suspend action it is again to prevent leaking
> > crypto keys. E.g when you suspend laptop and put it off
> > (somebody can remove RAMs and do some cold boot attack).
> >
> > The most common situation is:
> > You have mounted partition from dm-crypt device (e.g.
> > /home/), some userspace processes access it (e.g opened
> > firefox which still reads/writes to cache ~/.firefox/) and
> > you want to drop crypto keys from kernel for some time.
> >
> > For that operation there is command cryptsetup luksSuspend,
> > which suspend dm device and then tell kernel to wipe crypto
> > keys. All I/O operations are then stopped and userspace
> > processes which want to do some those I/O operations are
> > stopped too (until you call cryptsetup luksResume and enter
> > correct key).
>
> Actually... is the list of sites where the process wait small
> enough? Could we modify them to be freezeable? Suspend should
> work even if user stopped the his crypto partitions...
>
> Pavel
If you suspend dm device and then you want to read file from fs
which is on that device, then process freeze and you even cannot
kill it with SIGKILL. Before entering suspend kernel tries to do
sync and that operation also fails...
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Why wipe crypto keys during suspend (was Re: [PATCH 0/3] dm-crypt: Adds support for wiping key when doing suspend/hibernation)
From: Pavel Machek @ 2015-04-06 21:13 UTC (permalink / raw)
To: Mike Snitzer
Cc: Pali Rohár, Alasdair Kergon, Neil Brown, Rafael J. Wysocki,
Len Brown, dm-devel, linux-raid, linux-kernel, linux-pm
In-Reply-To: <20150406205145.GA19677@redhat.com>
On Mon 2015-04-06 16:51:45, Mike Snitzer wrote:
> On Mon, Apr 06 2015 at 9:25am -0400,
> Pavel Machek <pavel@ucw.cz> wrote:
>
> > On Mon 2015-04-06 09:00:46, Mike Snitzer wrote:
> > > On Sun, Apr 05 2015 at 1:20pm -0400,
> > > Pali Rohár <pali.rohar@gmail.com> wrote:
> > >
> > > > This patch series increase security of suspend and hibernate actions. It allows
> > > > user to safely wipe crypto keys before suspend and hibernate actions starts
> > > > without race conditions on userspace process with heavy I/O.
> > > >
> > > > To automatically wipe cryto key for <device> before hibernate action call:
> > > > $ dmsetup message <device> 0 key wipe_on_hibernation 1
> > > >
> > > > To automatically wipe cryto key for <device> before suspend action call:
> > > > $ dmsetup message <device> 0 key wipe_on_suspend 1
> > > >
> > > > (Value 0 after wipe_* string reverts original behaviour - to not wipe key)
> > >
> > > Can you elaborate on the attack vector your changes are meant to protect
> > > against? The user already authorized access, why is it inherently
> > > dangerous to _not_ wipe the associated key across these events?
> >
> > Umm. You are using your notebook. It is unlikely to be stolen at that
> > point. You close the lid and board the airplane, stowing it in
> > overhead bin. There's much better chance of notebook being stolen now.
>
> Yes, pretty straight forward but the thief would need to then login upon
> resume (at least with most common desktop configs)... the barrier then
> is only the strength of the user's password and not the crypt
> passphrase.
Why would he want to do that? :-).
No; at that point, attacker would either wait for something remotely
exploitable to exploit, or attach JTAG debugger to the machine, or use
liquid nitrogen on RAMs and then attach them to running machine.
Yes, it is better when keys are not on your machine when it is stolen.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH 0/3] dm-crypt: Adds support for wiping key when doing suspend/hibernation
From: Mike Snitzer @ 2015-04-06 20:51 UTC (permalink / raw)
To: Pavel Machek
Cc: Pali Rohár, Alasdair Kergon, Neil Brown, Rafael J. Wysocki,
Len Brown, dm-devel, linux-raid, linux-kernel, linux-pm
In-Reply-To: <20150406132505.GB9978@amd>
On Mon, Apr 06 2015 at 9:25am -0400,
Pavel Machek <pavel@ucw.cz> wrote:
> On Mon 2015-04-06 09:00:46, Mike Snitzer wrote:
> > On Sun, Apr 05 2015 at 1:20pm -0400,
> > Pali Rohár <pali.rohar@gmail.com> wrote:
> >
> > > This patch series increase security of suspend and hibernate actions. It allows
> > > user to safely wipe crypto keys before suspend and hibernate actions starts
> > > without race conditions on userspace process with heavy I/O.
> > >
> > > To automatically wipe cryto key for <device> before hibernate action call:
> > > $ dmsetup message <device> 0 key wipe_on_hibernation 1
> > >
> > > To automatically wipe cryto key for <device> before suspend action call:
> > > $ dmsetup message <device> 0 key wipe_on_suspend 1
> > >
> > > (Value 0 after wipe_* string reverts original behaviour - to not wipe key)
> >
> > Can you elaborate on the attack vector your changes are meant to protect
> > against? The user already authorized access, why is it inherently
> > dangerous to _not_ wipe the associated key across these events?
>
> Umm. You are using your notebook. It is unlikely to be stolen at that
> point. You close the lid and board the airplane, stowing it in
> overhead bin. There's much better chance of notebook being stolen now.
Yes, pretty straight forward but the thief would need to then login upon
resume (at least with most common desktop configs)... the barrier then
is only the strength of the user's password and not the crypt
passphrase.
^ permalink raw reply
* Re: Two system lockups, Magic SysKeys works, RAID6 resyncs on reboot
From: Mark Knecht @ 2015-04-06 18:39 UTC (permalink / raw)
To: Roman Mamedov; +Cc: Linux-RAID
In-Reply-To: <20150401013032.5c908e85@natsu>
On Tue, Mar 31, 2015 at 1:30 PM, Roman Mamedov <rm@romanrm.net> wrote:
> On Tue, 31 Mar 2015 08:00:27 -0700
> Mark Knecht <markknecht@gmail.com> wrote:
>
>> md3 : active raid6 sdc3[9] sdg3[5] sdf3[6] sde3[7] sdd3[8]
>> 1452264480 blocks super 1.2 level 6, 16k chunk, algorithm 2 [5/5] [UUUUU]
>> [====>................] resync = 22.8% (110608304/484088160)
>> finish=78.5min speed=79206K/sec
>
> Looks like you are running this without a write intent bitmap, why? It would
> at least save you from a full resync each time.
>
> --
> With respect,
> Roman
I had a 3rd lockup this morning. No idea what's causing them but the
write intent bitmap really got past the resync issue quickly.
Thanks!
Cheers,
Mark
^ permalink raw reply
* Re: [PATCH 0/3] dm-crypt: Adds support for wiping key when doing suspend/hibernation
From: Pavel Machek @ 2015-04-06 18:17 UTC (permalink / raw)
To: Pali Rohár
Cc: Mike Snitzer, Alasdair Kergon, Neil Brown, Rafael J. Wysocki,
Len Brown, dm-devel, linux-raid, linux-kernel, linux-pm
In-Reply-To: <201504061529.57299@pali>
On Mon 2015-04-06 15:29:57, Pali Rohár wrote:
> On Monday 06 April 2015 15:00:46 Mike Snitzer wrote:
> > On Sun, Apr 05 2015 at 1:20pm -0400,
> >
> > Pali Rohár <pali.rohar@gmail.com> wrote:
> > > This patch series increase security of suspend and hibernate
> > > actions. It allows user to safely wipe crypto keys before
> > > suspend and hibernate actions starts without race
> > > conditions on userspace process with heavy I/O.
> > >
> > > To automatically wipe cryto key for <device> before
> > > hibernate action call: $ dmsetup message <device> 0 key
> > > wipe_on_hibernation 1
> > >
> > > To automatically wipe cryto key for <device> before suspend
> > > action call: $ dmsetup message <device> 0 key
> > > wipe_on_suspend 1
> > >
> > > (Value 0 after wipe_* string reverts original behaviour - to
> > > not wipe key)
> >
> > Can you elaborate on the attack vector your changes are meant
> > to protect against? The user already authorized access, why
> > is it inherently dangerous to _not_ wipe the associated key
> > across these events?
>
> Hi,
>
> yes, I will try to explain current problems with cryptsetup
> luksSuspend command and hibernation.
>
> First, sometimes it is needed to put machine into other hands.
> You can still watch other person what is doing with machine, but
> once if you let machine unlocked (e.g opened luks disk), she/he
> can access encrypted data.
>
> If you turn off machine, it could be safe, because luks disk
> devices are locked. But if you enter machine into suspend or
> hibernate state luks devices are still open. And my patches try
> to achieve similar security as when machine is off (= no crypto
> keys in RAM or on swap).
>
> When doing hibernate on unencrypted swap it is to prevent leaking
> crypto keys to hibernate image (which is stored in swap).
>
> When doing suspend action it is again to prevent leaking crypto
> keys. E.g when you suspend laptop and put it off (somebody can
> remove RAMs and do some cold boot attack).
>
> The most common situation is:
> You have mounted partition from dm-crypt device (e.g. /home/),
> some userspace processes access it (e.g opened firefox which
> still reads/writes to cache ~/.firefox/) and you want to drop
> crypto keys from kernel for some time.
>
> For that operation there is command cryptsetup luksSuspend, which
> suspend dm device and then tell kernel to wipe crypto keys. All
> I/O operations are then stopped and userspace processes which
> want to do some those I/O operations are stopped too (until you
> call cryptsetup luksResume and enter correct key).
Actually... is the list of sites where the process wait small enough?
Could we modify them to be freezeable? Suspend should work even if
user stopped the his crypto partitions...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH 0/3] dm-crypt: Adds support for wiping key when doing suspend/hibernation
From: Pali Rohár @ 2015-04-06 13:29 UTC (permalink / raw)
To: Mike Snitzer
Cc: Alasdair Kergon, Neil Brown, Rafael J. Wysocki, Len Brown,
Pavel Machek, dm-devel, linux-raid, linux-kernel, linux-pm
In-Reply-To: <20150406130045.GA18583@redhat.com>
[-- Attachment #1: Type: Text/Plain, Size: 3187 bytes --]
On Monday 06 April 2015 15:00:46 Mike Snitzer wrote:
> On Sun, Apr 05 2015 at 1:20pm -0400,
>
> Pali Rohár <pali.rohar@gmail.com> wrote:
> > This patch series increase security of suspend and hibernate
> > actions. It allows user to safely wipe crypto keys before
> > suspend and hibernate actions starts without race
> > conditions on userspace process with heavy I/O.
> >
> > To automatically wipe cryto key for <device> before
> > hibernate action call: $ dmsetup message <device> 0 key
> > wipe_on_hibernation 1
> >
> > To automatically wipe cryto key for <device> before suspend
> > action call: $ dmsetup message <device> 0 key
> > wipe_on_suspend 1
> >
> > (Value 0 after wipe_* string reverts original behaviour - to
> > not wipe key)
>
> Can you elaborate on the attack vector your changes are meant
> to protect against? The user already authorized access, why
> is it inherently dangerous to _not_ wipe the associated key
> across these events?
Hi,
yes, I will try to explain current problems with cryptsetup
luksSuspend command and hibernation.
First, sometimes it is needed to put machine into other hands.
You can still watch other person what is doing with machine, but
once if you let machine unlocked (e.g opened luks disk), she/he
can access encrypted data.
If you turn off machine, it could be safe, because luks disk
devices are locked. But if you enter machine into suspend or
hibernate state luks devices are still open. And my patches try
to achieve similar security as when machine is off (= no crypto
keys in RAM or on swap).
When doing hibernate on unencrypted swap it is to prevent leaking
crypto keys to hibernate image (which is stored in swap).
When doing suspend action it is again to prevent leaking crypto
keys. E.g when you suspend laptop and put it off (somebody can
remove RAMs and do some cold boot attack).
The most common situation is:
You have mounted partition from dm-crypt device (e.g. /home/),
some userspace processes access it (e.g opened firefox which
still reads/writes to cache ~/.firefox/) and you want to drop
crypto keys from kernel for some time.
For that operation there is command cryptsetup luksSuspend, which
suspend dm device and then tell kernel to wipe crypto keys. All
I/O operations are then stopped and userspace processes which
want to do some those I/O operations are stopped too (until you
call cryptsetup luksResume and enter correct key).
Now if you want to suspend/hiberate your machine (when some of dm
devices are suspeneded and some processes are stopped due to
pending I/O) it is not possible. Kernel freeze_processes function
will fail because userspace processes are still stopped inside
some I/O syscall (read/write, etc,...).
My patches fixes this problem and do those operations (suspend dm
device, wipe crypto keys, enter suspend/hiberate) in correct
order and without race condition.
dm device is suspended *after* userspace processes are freezed
and after that are crypto keys wiped. And then computer/laptop
enters into suspend/hibernate state.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] dm-crypt: Adds support for wiping key when doing suspend/hibernation
From: Pavel Machek @ 2015-04-06 13:25 UTC (permalink / raw)
To: Mike Snitzer
Cc: Pali Rohár, Alasdair Kergon, Neil Brown, Rafael J. Wysocki,
Len Brown, dm-devel, linux-raid, linux-kernel, linux-pm
In-Reply-To: <20150406130045.GA18583@redhat.com>
On Mon 2015-04-06 09:00:46, Mike Snitzer wrote:
> On Sun, Apr 05 2015 at 1:20pm -0400,
> Pali Rohár <pali.rohar@gmail.com> wrote:
>
> > This patch series increase security of suspend and hibernate actions. It allows
> > user to safely wipe crypto keys before suspend and hibernate actions starts
> > without race conditions on userspace process with heavy I/O.
> >
> > To automatically wipe cryto key for <device> before hibernate action call:
> > $ dmsetup message <device> 0 key wipe_on_hibernation 1
> >
> > To automatically wipe cryto key for <device> before suspend action call:
> > $ dmsetup message <device> 0 key wipe_on_suspend 1
> >
> > (Value 0 after wipe_* string reverts original behaviour - to not wipe key)
>
> Can you elaborate on the attack vector your changes are meant to protect
> against? The user already authorized access, why is it inherently
> dangerous to _not_ wipe the associated key across these events?
Umm. You are using your notebook. It is unlikely to be stolen at that
point. You close the lid and board the airplane, stowing it in
overhead bin. There's much better chance of notebook being stolen now.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH 0/3] dm-crypt: Adds support for wiping key when doing suspend/hibernation
From: Mike Snitzer @ 2015-04-06 13:00 UTC (permalink / raw)
To: Pali Rohár
Cc: Alasdair Kergon, Neil Brown, Rafael J. Wysocki, Len Brown,
Pavel Machek, dm-devel, linux-raid, linux-kernel, linux-pm
In-Reply-To: <1428254419-7334-1-git-send-email-pali.rohar@gmail.com>
On Sun, Apr 05 2015 at 1:20pm -0400,
Pali Rohár <pali.rohar@gmail.com> wrote:
> This patch series increase security of suspend and hibernate actions. It allows
> user to safely wipe crypto keys before suspend and hibernate actions starts
> without race conditions on userspace process with heavy I/O.
>
> To automatically wipe cryto key for <device> before hibernate action call:
> $ dmsetup message <device> 0 key wipe_on_hibernation 1
>
> To automatically wipe cryto key for <device> before suspend action call:
> $ dmsetup message <device> 0 key wipe_on_suspend 1
>
> (Value 0 after wipe_* string reverts original behaviour - to not wipe key)
Can you elaborate on the attack vector your changes are meant to protect
against? The user already authorized access, why is it inherently
dangerous to _not_ wipe the associated key across these events?
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 3/3] dm-crypt: Adds support for wiping key when doing suspend/hibernation
From: Pali Rohár @ 2015-04-05 17:20 UTC (permalink / raw)
To: Alasdair Kergon, Mike Snitzer, Neil Brown, Rafael J. Wysocki,
Len Brown, Pavel Machek
Cc: dm-devel, linux-raid, linux-kernel, linux-pm, Pali Rohár
In-Reply-To: <1428254419-7334-1-git-send-email-pali.rohar@gmail.com>
This patch adds dm message commands and option strings to optionally wipe key
from dm-crypt device before entering suspend or hibernate state.
Before key is wiped dm device must be suspended. To prevent race conditions with
I/O and userspace processes, wiping action must be called after processes are
freezed. Otherwise userspace processes could start reading/writing to disk after
dm device is suspened and freezing processes before suspend/hibernate action
will fail.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
---
drivers/md/dm-crypt.c | 109 +++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 102 insertions(+), 7 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 713a962..9b02824 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -23,6 +23,7 @@
#include <linux/atomic.h>
#include <linux/scatterlist.h>
#include <linux/rbtree.h>
+#include <linux/suspend.h>
#include <asm/page.h>
#include <asm/unaligned.h>
#include <crypto/hash.h>
@@ -31,6 +32,8 @@
#include <linux/device-mapper.h>
+#include "dm.h"
+
#define DM_MSG_PREFIX "crypt"
/*
@@ -112,13 +115,18 @@ struct iv_tcw_private {
* and encrypts / decrypts at the same time.
*/
enum flags { DM_CRYPT_SUSPENDED, DM_CRYPT_KEY_VALID,
- DM_CRYPT_SAME_CPU, DM_CRYPT_NO_OFFLOAD };
+ DM_CRYPT_SAME_CPU, DM_CRYPT_NO_OFFLOAD,
+ DM_CRYPT_KEY_WIPE_ON_HIBERNATION,
+ DM_CRYPT_KEY_WIPE_ON_SUSPEND,
+};
/*
* The fields in here must be read only after initialization.
*/
struct crypt_config {
struct dm_dev *dev;
+ struct dm_target *ti;
+ struct list_head entry;
sector_t start;
/*
@@ -181,6 +189,9 @@ struct crypt_config {
#define MIN_IOS 16
+static LIST_HEAD(crypt_list);
+static DEFINE_MUTEX(crypt_list_mtx);
+
static void clone_init(struct dm_crypt_io *, struct bio *);
static void kcryptd_queue_crypt(struct dm_crypt_io *io);
static u8 *iv_of_dmreq(struct crypt_config *cc, struct dm_crypt_request *dmreq);
@@ -1497,12 +1508,26 @@ out:
static int crypt_wipe_key(struct crypt_config *cc)
{
+ int ret;
+
+ if (cc->iv_gen_ops && cc->iv_gen_ops->wipe) {
+ ret = cc->iv_gen_ops->wipe(cc);
+ if (ret)
+ return ret;
+ }
+
clear_bit(DM_CRYPT_KEY_VALID, &cc->flags);
memset(&cc->key, 0, cc->key_size * sizeof(u8));
return crypt_setkey_allcpus(cc);
}
+static void crypt_suspend_and_wipe_key(struct crypt_config *cc)
+{
+ dm_suspend_md(dm_table_get_md(cc->ti->table));
+ crypt_wipe_key(cc);
+}
+
static void crypt_dtr(struct dm_target *ti)
{
struct crypt_config *cc = ti->private;
@@ -1512,6 +1537,10 @@ static void crypt_dtr(struct dm_target *ti)
if (!cc)
return;
+ mutex_lock(&crypt_list_mtx);
+ list_del(&cc->entry);
+ mutex_unlock(&crypt_list_mtx);
+
if (cc->write_thread)
kthread_stop(cc->write_thread);
@@ -1738,6 +1767,7 @@ static int crypt_ctr(struct dm_target *ti, unsigned int argc, char **argv)
cc->key_size = key_size;
ti->private = cc;
+ cc->ti = ti;
ret = crypt_ctr_cipher(ti, argv[0], argv[1]);
if (ret < 0)
goto bad;
@@ -1832,7 +1862,14 @@ static int crypt_ctr(struct dm_target *ti, unsigned int argc, char **argv)
else if (!strcasecmp(opt_string, "submit_from_crypt_cpus"))
set_bit(DM_CRYPT_NO_OFFLOAD, &cc->flags);
+ else if (!strcasecmp(opt_string, "key_wipe_on_hibernation"))
+ set_bit(DM_CRYPT_KEY_WIPE_ON_HIBERNATION, &cc->flags);
+
+ else if (!strcasecmp(opt_string, "key_wipe_on_suspend"))
+ set_bit(DM_CRYPT_KEY_WIPE_ON_SUSPEND, &cc->flags);
+
else {
+ ret = -EINVAL;
ti->error = "Invalid feature arguments";
goto bad;
}
@@ -1871,6 +1908,10 @@ static int crypt_ctr(struct dm_target *ti, unsigned int argc, char **argv)
ti->num_flush_bios = 1;
ti->discard_zeroes_data_unsupported = true;
+ mutex_lock(&crypt_list_mtx);
+ list_add(&cc->entry, &crypt_list);
+ mutex_unlock(&crypt_list_mtx);
+
return 0;
bad:
@@ -1979,6 +2020,8 @@ static void crypt_resume(struct dm_target *ti)
/* Message interface
* key set <key>
* key wipe
+ * key wipe_on_hibernation <0|1>
+ * key wipe_on_suspend <0|1>
*/
static int crypt_message(struct dm_target *ti, unsigned argc, char **argv)
{
@@ -1989,6 +2032,30 @@ static int crypt_message(struct dm_target *ti, unsigned argc, char **argv)
goto error;
if (!strcasecmp(argv[0], "key")) {
+ if (argc == 3 && !strcasecmp(argv[1], "wipe_on_hibernation")) {
+ if (!strcmp(argv[2], "1")) {
+ set_bit(DM_CRYPT_KEY_WIPE_ON_HIBERNATION, &cc->flags);
+ return 0;
+ } else if (!strcmp(argv[2], "0")) {
+ clear_bit(DM_CRYPT_KEY_WIPE_ON_HIBERNATION, &cc->flags);
+ return 0;
+ } else {
+ DMWARN("unrecognised message received.");
+ return -EINVAL;
+ }
+ }
+ if (argc == 3 && !strcasecmp(argv[1], "wipe_on_suspend")) {
+ if (!strcmp(argv[2], "1")) {
+ set_bit(DM_CRYPT_KEY_WIPE_ON_SUSPEND, &cc->flags);
+ return 0;
+ } else if (!strcmp(argv[2], "0")) {
+ clear_bit(DM_CRYPT_KEY_WIPE_ON_SUSPEND, &cc->flags);
+ return 0;
+ } else {
+ DMWARN("unrecognised message received.");
+ return -EINVAL;
+ }
+ }
if (!test_bit(DM_CRYPT_SUSPENDED, &cc->flags)) {
DMWARN("not suspended during key manipulation.");
return -EINVAL;
@@ -2002,11 +2069,6 @@ static int crypt_message(struct dm_target *ti, unsigned argc, char **argv)
return ret;
}
if (argc == 2 && !strcasecmp(argv[1], "wipe")) {
- if (cc->iv_gen_ops && cc->iv_gen_ops->wipe) {
- ret = cc->iv_gen_ops->wipe(cc);
- if (ret)
- return ret;
- }
return crypt_wipe_key(cc);
}
}
@@ -2055,19 +2117,52 @@ static struct target_type crypt_target = {
.iterate_devices = crypt_iterate_devices,
};
+static int dm_crypt_pm_notifier_call(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ struct crypt_config *cc;
+
+ mutex_lock(&crypt_list_mtx);
+
+ list_for_each_entry(cc, &crypt_list, entry) {
+ if ((action == PM_HIBERNATION_AFTER_FREEZE &&
+ test_bit(DM_CRYPT_KEY_WIPE_ON_HIBERNATION, &cc->flags)) ||
+ (action == PM_SUSPEND_AFTER_FREEZE &&
+ test_bit(DM_CRYPT_KEY_WIPE_ON_SUSPEND, &cc->flags))) {
+ crypt_suspend_and_wipe_key(cc);
+ }
+ }
+
+ mutex_unlock(&crypt_list_mtx);
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block dm_crypt_pm_notifier_block = {
+ .notifier_call = dm_crypt_pm_notifier_call,
+};
+
static int __init dm_crypt_init(void)
{
int r;
r = dm_register_target(&crypt_target);
- if (r < 0)
+ if (r < 0) {
DMERR("register failed %d", r);
+ return r;
+ }
+
+ r = register_pm_notifier(&dm_crypt_pm_notifier_block);
+ if (r) {
+ DMWARN("register_pm_notifier failed %d", r);
+ }
return r;
}
static void __exit dm_crypt_exit(void)
{
+ unregister_pm_notifier(&dm_crypt_pm_notifier_block);
dm_unregister_target(&crypt_target);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/3] dm: Export function dm_suspend_md()
From: Pali Rohár @ 2015-04-05 17:20 UTC (permalink / raw)
To: Alasdair Kergon, Mike Snitzer, Neil Brown, Rafael J. Wysocki,
Len Brown, Pavel Machek
Cc: dm-devel, linux-raid, linux-kernel, linux-pm, Pali Rohár
In-Reply-To: <1428254419-7334-1-git-send-email-pali.rohar@gmail.com>
This patch exports function dm_suspend_md() which suspend mapped device so other
kernel drivers can use it and could suspend mapped device when needed.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
---
drivers/md/dm.c | 6 ++++++
drivers/md/dm.h | 5 +++++
2 files changed, 11 insertions(+)
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 8001fe9..919ce95 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -3053,6 +3053,12 @@ out:
return r;
}
+int dm_suspend_md(struct mapped_device *md)
+{
+ return dm_suspend(md, DM_SUSPEND_LOCKFS_FLAG);
+}
+EXPORT_SYMBOL_GPL(dm_suspend_md);
+
/*
* Internal suspend/resume works like userspace-driven suspend. It waits
* until all bios finish and prevents issuing new bios to the target drivers.
diff --git a/drivers/md/dm.h b/drivers/md/dm.h
index 59f53e7..623c9a8 100644
--- a/drivers/md/dm.h
+++ b/drivers/md/dm.h
@@ -152,6 +152,11 @@ int dm_test_deferred_remove_flag(struct mapped_device *md);
void dm_deferred_remove(void);
/*
+ * Suspend mapped_device
+ */
+int dm_suspend_md(struct mapped_device *md);
+
+/*
* The device-mapper can be driven through one of two interfaces;
* ioctl or filesystem, depending which patch you have applied.
*/
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/3] PM suspend/hibernate: Call notifier after freezing processes
From: Pali Rohár @ 2015-04-05 17:20 UTC (permalink / raw)
To: Alasdair Kergon, Mike Snitzer, Neil Brown, Rafael J. Wysocki,
Len Brown, Pavel Machek
Cc: dm-devel, linux-raid, linux-kernel, linux-pm, Pali Rohár
In-Reply-To: <1428254419-7334-1-git-send-email-pali.rohar@gmail.com>
To prevent race conditions on userspace processes with I/O some taks must be
called after processes are freezed. This patch adds new events which are
delivered by pm_notifier_call_chain() after freezing processes when doing
suspend or hibernate action.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
---
include/linux/suspend.h | 2 ++
kernel/power/hibernate.c | 2 ++
kernel/power/suspend.c | 4 +++-
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/linux/suspend.h b/include/linux/suspend.h
index 5efe743..bc743c8 100644
--- a/include/linux/suspend.h
+++ b/include/linux/suspend.h
@@ -368,6 +368,8 @@ static inline bool hibernation_available(void) { return false; }
#define PM_POST_SUSPEND 0x0004 /* Suspend finished */
#define PM_RESTORE_PREPARE 0x0005 /* Going to restore a saved image */
#define PM_POST_RESTORE 0x0006 /* Restore failed */
+#define PM_HIBERNATION_AFTER_FREEZE 0x0007 /* After hibernation freeze */
+#define PM_SUSPEND_AFTER_FREEZE 0x0008 /* After suspend freeze */
extern struct mutex pm_mutex;
diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index 2329daa..184f7ee 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -671,6 +671,8 @@ int hibernate(void)
if (error)
goto Exit;
+ pm_notifier_call_chain(PM_HIBERNATION_AFTER_FREEZE);
+
lock_device_hotplug();
/* Allocate memory management structures */
error = create_basic_memory_bitmaps();
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index b7d6b3a..1776938 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -268,8 +268,10 @@ static int suspend_prepare(suspend_state_t state)
trace_suspend_resume(TPS("freeze_processes"), 0, true);
error = suspend_freeze_processes();
trace_suspend_resume(TPS("freeze_processes"), 0, false);
- if (!error)
+ if (!error) {
+ pm_notifier_call_chain(PM_SUSPEND_AFTER_FREEZE);
return 0;
+ }
suspend_stats.failed_freeze++;
dpm_save_failed_step(SUSPEND_FREEZE);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/3] dm-crypt: Adds support for wiping key when doing suspend/hibernation
From: Pali Rohár @ 2015-04-05 17:20 UTC (permalink / raw)
To: Alasdair Kergon, Mike Snitzer, Neil Brown, Rafael J. Wysocki,
Len Brown, Pavel Machek
Cc: dm-devel, linux-raid, linux-kernel, linux-pm, Pali Rohár
This patch series increase security of suspend and hibernate actions. It allows
user to safely wipe crypto keys before suspend and hibernate actions starts
without race conditions on userspace process with heavy I/O.
To automatically wipe cryto key for <device> before hibernate action call:
$ dmsetup message <device> 0 key wipe_on_hibernation 1
To automatically wipe cryto key for <device> before suspend action call:
$ dmsetup message <device> 0 key wipe_on_suspend 1
(Value 0 after wipe_* string reverts original behaviour - to not wipe key)
Pali Rohár (3):
PM suspend/hibernate: Call notifier after freezing processes
dm: Export function dm_suspend_md()
dm-crypt: Adds support for wiping key when doing suspend/hibernation
drivers/md/dm-crypt.c | 109 +++++++++++++++++++++++++++++++++++++++++++---
drivers/md/dm.c | 6 +++
drivers/md/dm.h | 5 +++
include/linux/suspend.h | 2 +
kernel/power/hibernate.c | 2 +
kernel/power/suspend.c | 4 +-
6 files changed, 120 insertions(+), 8 deletions(-)
--
1.7.9.5
^ permalink raw reply
* Help recovering an interrupted raid0 reshape
From: Jonathan Harker (Jesusaurus) @ 2015-04-04 2:22 UTC (permalink / raw)
To: linux-raid
I have a raid0 array whose component devices are raid1 arrays. In an
attempt to expand the pre-existing raid0 array, I created a new raid1
device and then added it, growing the raid0 array.
But then the system lost power shortly after the reshaping began.
After rebooting the original two components are listed as spares in an
inactive raid4 array and the new component is not listed in
/proc/mdstat:
Personalities : [raid6] [raid5] [raid4] [raid1] [raid10] [raid0]
[linear] [multipath]
md124 : inactive md126[0](S) md127[1](S)
3907022200 blocks super 1.2
md0 : active raid1 sda5[0] sdb2[1]
107652416 blocks [2/2] [UU]
bitmap: 1/1 pages [4KB], 65536KB chunk
md125 : active raid1 sdh1[0] sdg1[1]
2930134016 blocks super 1.2 [2/2] [UU]
bitmap: 0/22 pages [0KB], 65536KB chunk
md126 : active raid1 sdc1[0] sdd1[1]
1953512312 blocks super 1.2 [2/2] [UU]
md127 : active raid1 sde1[2] sdf1[1]
1953512312 blocks super 1.2 [2/2] [UU]
unused devices: <none>
Looking at the details of the inactive array shows that it is in a
reshape between raid0 and raid4:
/dev/md124:
Version : 1.2
Raid Level : raid0
Total Devices : 2
Persistence : Superblock is persistent
State : inactive
Delta Devices : -1, (1->0)
New Level : raid4
New Chunksize : 512K
Name : hordern:hordern1 (local to host hordern)
UUID : 1f4979ba:c49a77c0:59e689c2:bcc21c0a
Events : 14013
Number Major Minor RaidDevice
- 9 126 - /dev/md/beta
- 9 127 - /dev/md/alpha
And examining each component shows that they have a consistent view of
where in that reshape they are (based on the reshape position), but
not consistent in the size of the array:
/dev/md/alpha:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x4
Array UUID : 1f4979ba:c49a77c0:59e689c2:bcc21c0a
Name : hordern:hordern1 (local to host hordern)
Creation Time : Fri Jan 2 09:59:40 2009
Raid Level : raid4
Raid Devices : 3
Avail Dev Size : 3907021824 (1863.01 GiB 2000.40 GB)
Array Size : 3907021824 (3726.03 GiB 4000.79 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
Unused Space : before=1968 sectors, after=752 sectors
State : active
Device UUID : 63aaa2e4:2a09f495:8372c7f9:eb2f2773
Reshape pos'n : 129067008 (123.09 GiB 132.16 GB)
Delta Devices : -1 (4->3)
Update Time : Sun Mar 29 15:11:35 2015
Checksum : 8be5e0e6 - correct
Events : 14013
Chunk Size : 512K
Device Role : Active device 1
Array State : AA.. ('A' == active, '.' == missing, 'R' == replacing)
/dev/md/beta:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x4
Array UUID : 1f4979ba:c49a77c0:59e689c2:bcc21c0a
Name : hordern:hordern1 (local to host hordern)
Creation Time : Fri Jan 2 09:59:40 2009
Raid Level : raid4
Raid Devices : 3
Avail Dev Size : 3907022576 (1863.01 GiB 2000.40 GB)
Array Size : 3907021824 (3726.03 GiB 4000.79 GB)
Used Dev Size : 3907021824 (1863.01 GiB 2000.40 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
Unused Space : before=1968 sectors, after=752 sectors
State : clean
Device UUID : 6e6dce14:3ebb2bb5:187aa292:403a55f6
Reshape pos'n : 129067008 (123.09 GiB 132.16 GB)
Delta Devices : -1 (4->3)
Update Time : Sun Mar 29 15:11:35 2015
Checksum : f7526add - correct
Events : 14013
Chunk Size : 512K
Device Role : Active device 0
Array State : AA.. ('A' == active, '.' == missing, 'R' == replacing)
/dev/md/gamma:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x6
Array UUID : 1f4979ba:c49a77c0:59e689c2:bcc21c0a
Name : hordern:hordern1 (local to host hordern)
Creation Time : Fri Jan 2 09:59:40 2009
Raid Level : raid4
Raid Devices : 4
Avail Dev Size : 5860265984 (2794.39 GiB 3000.46 GB)
Array Size : 5860532736 (5589.04 GiB 6001.19 GB)
Used Dev Size : 3907021824 (1863.01 GiB 2000.40 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
Recovery Offset : 86403072 sectors
Unused Space : before=1960 sectors, after=1953244160 sectors
State : active
Device UUID : 782873ea:e265ecd4:5cc80ddf:035ba2b4
Reshape pos'n : 129067008 (123.09 GiB 132.16 GB)
Delta Devices : 1 (3->4)
Update Time : Sun Mar 29 00:05:29 2015
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 710dc078 - correct
Events : 673
Chunk Size : 512K
Device Role : Active device 2
Array State : AAA. ('A' == active, '.' == missing, 'R' == replacing)
When I stop the inactive array and try to assemble it from all three
components, I get an error about the superblock on the third component
not matching the other two components (which makes sense since the
array sizes are different):
hordern ~ # mdadm --verbose --verbose --assemble /dev/md/hordern1
/dev/md/alpha /dev/md/beta /dev/md/gamma
mdadm: looking for devices for /dev/md/hordern1
mdadm: UUID differs from /dev/md0.
mdadm: UUID differs from /dev/md/alpha.
mdadm: UUID differs from /dev/md/beta.
mdadm: UUID differs from /dev/md/gamma.
mdadm: UUID differs from /dev/md0.
mdadm: UUID differs from /dev/md/alpha.
mdadm: UUID differs from /dev/md/beta.
mdadm: UUID differs from /dev/md/gamma.
mdadm: UUID differs from /dev/md0.
mdadm: UUID differs from /dev/md/alpha.
mdadm: UUID differs from /dev/md/beta.
mdadm: UUID differs from /dev/md/gamma.
mdadm: superblock on /dev/md/gamma doesn't match others - assembly aborted
First, what could cause the initial two components to have a different
superblock than the newly added component? And can I convince them to
be the same?
Second, is there documentation anywhere about the internal process of
growing a raid0 array? Why does it convert to a raid4 array? And what
do the Delta Devices lines mean?
Third, is it possible to resume the reshape? If not, can it be reverted?
--
Jon
^ permalink raw reply
* Re: Breaks LSI RAID on C600 chipset
From: John Stoffel @ 2015-04-04 1:47 UTC (permalink / raw)
To: David F.; +Cc: linux-raid@vger.kernel.org
In-Reply-To: <CAGRSmLtoCz+wff+F=xnnusc5_bUYxWYT5V5iTncTnRfgRnTqtg@mail.gmail.com>
David> Loading V3.3.2 Aug 2014 on an asus z9pa-u8 mobo, with the
David> controller in LSI RAID mode and configured using RAID 1 via the
David> BIOS, will break the RAID. (no longer configured as RAID).
David> All it takes is starting mdadm which seems to work for that
David> session but on reboot the RAID is gone. The z9pa-u8 uses the
David> C602 intel chipset.
Which version of Linux kernel and disto are you using?
David> Customer reported same on what they called an Intel ESRT2 which
David> appears to use the same line C600 based chipset. Not sure if
David> in LSI mode, but presume so. That controller allows you to
David> pick LSI mode, Intel RAID mode, or just non RAID normal
David> controller mode.
David> Unfortunately, mine is a production server so I can't do much testing
David> (even trying to load it will probably break it). Not sure if you can
David> get your hands on one to test. Loading using DMRAID worked okay
David> which is how I got around it.
Can you please give us the exact steps you took, and the output at
each step? Also, which version of mdadm are you running which does
NOT break things? That would be good to know.
The output of 'cat /proc/mdstat', 'mdadm --detail /dev/md*' and 'mdadm
-E /dev/sd?e' for each device in the various raid arrays.
If you start then stop the new mdadm, do you see differences when you
then use the old, working mdadm to examine the various devices?
Basically, we need lots more information here to help.
John
^ permalink raw reply
* Breaks LSI RAID on C600 chipset
From: David F. @ 2015-04-04 0:25 UTC (permalink / raw)
To: linux-raid@vger.kernel.org
Loading V3.3.2 Aug 2014 on an asus z9pa-u8 mobo, with the controller
in LSI RAID mode and configured using RAID 1 via the BIOS, will break
the RAID. (no longer configured as RAID). All it takes is starting
mdadm which seems to work for that session but on reboot the RAID is
gone. The z9pa-u8 uses the C602 intel chipset.
Customer reported same on what they called an Intel ESRT2 which
appears to use the same line C600 based chipset. Not sure if in LSI
mode, but presume so. That controller allows you to pick LSI mode,
Intel RAID mode, or just non RAID normal controller mode.
Unfortunately, mine is a production server so I can't do much testing
(even trying to load it will probably break it). Not sure if you can
get your hands on one to test. Loading using DMRAID worked okay
which is how I got around it.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox