* [md:devel 41/50] drivers/md/md.c:1663:33: sparse: restricted __le32 degrades to integer
From: kbuild test robot @ 2015-08-19 6:51 UTC (permalink / raw)
To: Song Liu; +Cc: kbuild-all, NeilBrown, Shaohua Li, linux-raid
tree: git://neil.brown.name/md devel
head: da63d1b483fa5a9604d65974eb442a110ee41e89
commit: 1a8a1e097abc6d2787ef6f2e915d5f18d42a1e6c [41/50] MD: add a new disk role to present write journal device
reproduce:
# apt-get install sparse
git checkout 1a8a1e097abc6d2787ef6f2e915d5f18d42a1e6c
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/md/md.c:1501:34: sparse: cast to restricted __le64
>> drivers/md/md.c:1663:33: sparse: restricted __le32 degrades to integer
drivers/md/md.c:1794:40: sparse: incorrect type in assignment (different base types)
drivers/md/md.c:1794:40: expected unsigned long long [unsigned] [long] [long long] [usertype] <noident>
drivers/md/md.c:1794:40: got restricted __le64 [usertype] <noident>
drivers/md/md.c:1872:26: sparse: incorrect type in assignment (different base types)
drivers/md/md.c:1872:26: expected restricted __le64 [usertype] super_offset
drivers/md/md.c:1872:26: got unsigned long [unsigned] [usertype] sb_start
drivers/md/md.c:8980:39: sparse: restricted __le64 degrades to integer
vim +1663 drivers/md/md.c
1647 }
1648 if (mddev->level != LEVEL_MULTIPATH) {
1649 int role;
1650 if (rdev->desc_nr < 0 ||
1651 rdev->desc_nr >= le32_to_cpu(sb->max_dev)) {
1652 role = MD_DISK_ROLE_SPARE;
1653 rdev->desc_nr = -1;
1654 } else
1655 role = le16_to_cpu(sb->dev_roles[rdev->desc_nr]);
1656 switch(role) {
1657 case MD_DISK_ROLE_SPARE: /* spare */
1658 break;
1659 case MD_DISK_ROLE_FAULTY: /* faulty */
1660 set_bit(Faulty, &rdev->flags);
1661 break;
1662 case MD_DISK_ROLE_JOURNAL: /* journal device */
> 1663 if (!(sb->feature_map & MD_FEATURE_JOURNAL)) {
1664 /* journal device without journal feature */
1665 printk(KERN_WARNING
1666 "md: journal device provided without "
1667 "journal feature, ignoring the device\n");
1668 return -EINVAL;
1669 }
1670 set_bit(Journal, &rdev->flags);
1671 break;
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [md:devel 47/50] drivers/md/raid5-cache.c:828:24: sparse: incompatible types in comparison expression (different address spaces)
From: kbuild test robot @ 2015-08-19 6:57 UTC (permalink / raw)
To: Shaohua Li; +Cc: kbuild-all, NeilBrown, linux-raid
tree: git://neil.brown.name/md devel
head: da63d1b483fa5a9604d65974eb442a110ee41e89
commit: b8c1c83f96ea61fe7fc9aa960edfc6e75b0c56a3 [47/50] raid5: log recovery
reproduce:
# apt-get install sparse
git checkout b8c1c83f96ea61fe7fc9aa960edfc6e75b0c56a3
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/md/raid5-cache.c:828:24: sparse: incompatible types in comparison expression (different address spaces)
drivers/md/raid5-cache.c:832:25: sparse: incompatible types in comparison expression (different address spaces)
vim +828 drivers/md/raid5-cache.c
812 if (!test_bit(R5_Wantwrite, &sh->dev[disk_index].flags))
813 continue;
814 addr = kmap_atomic(sh->dev[disk_index].page);
815 checksum = crc32_le(log->uuid_checksum, addr, PAGE_SIZE);
816 kunmap_atomic(addr);
817 if (checksum != sh->dev[disk_index].log_checksum)
818 goto error;
819 }
820
821 for (disk_index = 0; disk_index < sh->disks; disk_index++) {
822 struct md_rdev *rdev, *rrdev;
823 if (!test_and_clear_bit(R5_Wantwrite,
824 &sh->dev[disk_index].flags))
825 continue;
826
827 /* in case device is broken */
> 828 rdev = rcu_dereference(conf->disks[disk_index].rdev);
829 if (rdev)
830 sync_page_io(rdev, stripe_sect, PAGE_SIZE,
831 sh->dev[disk_index].page, WRITE, false);
832 rrdev = rcu_dereference(conf->disks[disk_index].replacement);
833 if (rrdev)
834 sync_page_io(rrdev, stripe_sect, PAGE_SIZE,
835 sh->dev[disk_index].page, WRITE, false);
836 }
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [md:devel 46/50] drivers/md/raid5-cache.c:710:1371: error: call to '__cmpxchg_wrong_size' declared with attribute error: Bad argument size for cmpxchg
From: Shaohua Li @ 2015-08-19 21:45 UTC (permalink / raw)
To: kbuild test robot; +Cc: kbuild-all, NeilBrown, linux-raid
In-Reply-To: <201508191412.vxUg51nb%fengguang.wu@intel.com>
On Wed, Aug 19, 2015 at 02:44:13PM +0800, kbuild test robot wrote:
> tree: git://neil.brown.name/md devel
> head: da63d1b483fa5a9604d65974eb442a110ee41e89
> commit: ae7d339ebdd2b176a49442a8315cfe30173b5854 [46/50] raid5: log reclaim support
> config: i386-allyesconfig (attached as .config)
> reproduce:
> git checkout ae7d339ebdd2b176a49442a8315cfe30173b5854
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All error/warnings (new ones prefixed by >>):
>
> drivers/md/raid5-cache.c: In function 'r5l_wake_reclaim':
> >> drivers/md/raid5-cache.c:710:1371: error: call to '__cmpxchg_wrong_size' declared with attribute error: Bad argument size for cmpxchg
> } while (cmpxchg(&log->reclaim_target, target, space) != target);
>
^
> drivers/md/raid5-cache.c: In function 'r5l_do_reclaim':
> >> drivers/md/raid5-cache.c:620:631: error: call to '__xchg_wrong_size' declared with attribute error: Bad argument size for xchg
> sector_t reclaim_target = xchg(&log->reclaim_target, 0);
Thanks for the reporting. Here is the fix for the issues.
From d5c0fdd525b5ea95d4b7ef178ff6010aaa9b0e81 Mon Sep 17 00:00:00 2001
Message-Id: <d5c0fdd525b5ea95d4b7ef178ff6010aaa9b0e81.1440020586.git.shli@fb.com>
From: Shaohua Li <shli@fb.com>
Date: Wed, 19 Aug 2015 14:38:20 -0700
Subject: [PATCH] raid5: fix some build issues
Fix some build issues. I change the reclaim_target to 'unsigned long' so
we can use xchg. It can overflow in 32bit in theory, but don't think
it's a real issue.
Signed-off-by: Shaohua Li <shli@fb.com>
---
drivers/md/md.c | 2 +-
drivers/md/raid5-cache.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 4775029..9843ba3 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -1657,7 +1657,7 @@ static int super_1_validate(struct mddev *mddev, struct md_rdev *rdev)
set_bit(Faulty, &rdev->flags);
break;
case MD_DISK_ROLE_JOURNAL: /* journal device */
- if (!(sb->feature_map & MD_FEATURE_JOURNAL)) {
+ if (!(le32_to_cpu(sb->feature_map) & MD_FEATURE_JOURNAL)) {
/* journal device without journal feature */
printk(KERN_WARNING
"md: journal device provided without "
diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
index 52feb90..681621d 100644
--- a/drivers/md/raid5-cache.c
+++ b/drivers/md/raid5-cache.c
@@ -69,7 +69,7 @@ struct r5l_log {
struct kmem_cache *io_kc;
struct md_thread *reclaim_thread;
- sector_t reclaim_target; /* number of space that need to be reclaimed.
+ unsigned long reclaim_target; /* number of space that need to be reclaimed.
* if it's 0, reclaim spaces used by io_units
* which are in IO_UNIT_STRIPE_END state (eg,
* reclaim dones't wait for specific io_unit
--
1.8.1
^ permalink raw reply related
* (unknown),
From: Mark Singer @ 2015-08-20 7:12 UTC (permalink / raw)
Do you need an investor?
Our investors fund project and business. We also give out loan/credit to any individual and company at 3% interest rate yearly. For more information, Contact us via Email: devonfps@gmail.com
If you need an investor or quick funding, forward your response ONLY to this E-mail: devonfps@gmail.com
....
Haben Sie einen Investor brauchen?
Unsere Investoren Fonds Projekt- und Geschäfts. Wir geben auch Darlehen / Kredite an jeden einzelnen und Unternehmen bei 3% Zinsen jährlich. Für weitere Informationen, kontaktieren Sie uns per E-Mail: devonfps@gmail.com
Wenn Sie ein Investor oder schnelle Finanzierung benötigen, senden Sie Ihre Antwort nur auf diese E-mail: devonfps@gmail.com --
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
* ques on multi threaded raid
From: Linux Raid Study @ 2015-08-21 7:44 UTC (permalink / raw)
To: linux-raid
Hello Linux Raid experts,
Do we have expected performance gain with multi-threaded raid for any
latest version of kernel 3.x
Per the link below, there were good improvements with kernel 2.6x.
http://lwn.net/Articles/563142/
I would like to know about results/config for 3.18 or around kernel.
Thanks in advance!
^ permalink raw reply
* my subject
From: Muthoot, Finance @ 2015-08-22 22:07 UTC (permalink / raw)
To: Recipients
Be informed that Muthoot Finance give out Guarantee Business Loans, Automobile Purchase Loans, House Purchase Loans, Personal Loans at 3% interest rate, for more info email: muthootfinanccehome@gmail.com
====
Estar informado de que Muthoot Finanzas Dar a conocer Garanta de negocios Prstamos, Prstamos de Automviles Compra, Casa Compra prstamos, prstamos personales a tasa de inters del 3%, para obtener ms informacin email: muthootfinanccehome@gmail.com
====
Assunto: meu tema Ser informado de que Muthoot Finance dar empréstimos de Garantia de Negócios, Automobile Os empréstimos Purchase, Casa empréstimos Purchase,
empréstimos pessoais na taxa de juros de 3%, para mais informações e-mail: muthootfinanccehome@gmail.com
====
Nous portons à votre connaissance que Muthoot Finance vous donne des prêts d’affaires, pour l’achat des automobiles, des maisons, des prêts personnels, tous pour un taux d'intérêts de 3%, pour plus des détails consultez: muthootfinanccehome@gmail.com
====
Byt informovaný, že Muthoot Financie rozdávat zárucnej podnikatelských úverov, automobilový Nákup pôžiciek, úverov na bývanie, osobné pôžicky vo výške 3% úrokovou
sadzbou, pre viac informácií e-mail: muthootfinanccehome@gmail.com
====
Wir teilen mit, dass Muthoot Finance Firmen-Darlehen, Darlehen zur Anschaffung von Kfz-Fahrzeugen, Erwerb von Immobilien sowie persönliche Darlehen zu 3% effektiven Jahreszins anbietet, weitere Informationen erhalten Sie per E-Mail: muthootfinanccehome@gmail.com
====
Det opplyses om at Muthoot Finance gir ut garanti Business lån, Automobile kjøpe lån, hus kjøpe lån, personlige lån på 3% rente, for mer info e-post:
muthootfinanccehome@gmail.com
--
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
* unable to handle kernel NULL pointer dereference in get_free_stripe
From: Christian Hesse @ 2015-08-23 21:03 UTC (permalink / raw)
To: linux-raid; +Cc: NeilBrown
[-- Attachment #1: Type: text/plain, Size: 4331 bytes --]
Hello everybody,
with linux 4.1.x I am hit by this issue with RAID5:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<ffffffffa05a4b91>] get_free_stripe+0x31/0xf0 [raid456]
PGD bbb4e067 PUD a371f067 PMD 0
Oops: 0000 [#1] PREEMPT SMP
Modules linked in: fuse raid456 nft_reject_inet nf_reject_ipv4 async_raid6_recov nf_reject_ipv6 async_memcpy nft_reject async_pq async_xor xor async_tx vmw_vsock_vmci_transport vsock nft_meta iosf_mbi nf_conntrack_ipv6 coretemp nf_defrag_ipv6 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel raid6_pq mousedev aesni_intel nf_conntrack_ipv4 ppdev nf_defrag_ipv4 aes_x86_64 md_mod nft_ct nf_conntrack lrw gf128mul glue_helper vmw_balloon ablk_helper cryptd psmouse nft_hash serio_raw pcspkr nft_rbtree nf_tables_inet nf_tables_ipv6 vmwgfx nf_tables_ipv4 nf_tables ttm drm_kms_helper battery drm nfnetlink i2c_piix4 irda acpi_cpufreq vmw_vmci i2c_core shpchp evdev parport_pc crc_ccitt parport processor mac_hid ac sch_fq_codel nfs lockd grace sunrpc fscache ip_tables x_tables ext4 crc16 mbcache
jbd2 dm_snapshot dm_bufio squashfs loop dm_mirror dm_region_hash dm_log dm_mod sd_mod sr_mod cdrom ata_generic pata_acpi mptsas ata_piix scsi_transport_sas mptscsih libata mptbase crc32c_intel vmxnet3 scsi_mod atkbd libps2 intel_agp intel_gtt floppy i8042 serio button
CPU: 0 PID: 430 Comm: rsync Tainted: G W 4.1.6-2-ARCH #1
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/09/2012
task: ffff8800bb5628c0 ti: ffff880021ad8000 task.ti: ffff880021ad8000
RIP: 0010:[<ffffffffa05a4b91>] [<ffffffffa05a4b91>] get_free_stripe+0x31/0xf0 [raid456]
RSP: 0018:ffff880021adb748 EFLAGS: 00010086
RAX: fffffffffffffff0 RBX: 0000000000000000 RCX: 00000000000000ff
RDX: 0000000100100001 RSI: 00000000ffffffff RDI: ffff8800bb756800
RBP: ffff880021adb778 R08: ffff880235eee380 R09: ffff880235eede00
R10: ffffea00000de600 R11: 0000000000019d48 R12: ffff8800bb756800
R13: ffff8800bb756806 R14: ffff8800bb756990 R15: 0000000000000080
FS: 00007f5bc71d6700(0000) GS:ffff88023fc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000000bb40f000 CR4: 00000000000406f0
Stack:
ffff880021adb778 00000000ffffffff ffff8800bb756800 ffff8800bb756806
ffff8800bb756938 0000000000000080 ffff880021adb7a8 ffffffffa05a9814
ffff880021adb7a8 000000000000000b ffff8800bb756800 ffff880021adb870
Call Trace:
[<ffffffffa05a9814>] drop_one_stripe+0x44/0xb0 [raid456]
[<ffffffffa05a9a6a>] raid5_cache_scan+0x6a/0x90 [raid456]
[<ffffffff81179299>] shrink_slab+0x229/0x440
[<ffffffff8117cbca>] shrink_zone+0x2ca/0x2e0
[<ffffffff8117cd53>] do_try_to_free_pages+0x173/0x410
[<ffffffff8117d097>] try_to_free_pages+0xa7/0x1a0
[<ffffffff8116fcbf>] __alloc_pages_nodemask+0x5ff/0x9e0
[<ffffffff811b71f1>] alloc_pages_current+0x91/0x110
[<ffffffff81166657>] __page_cache_alloc+0xa7/0xd0
[<ffffffff811738e0>] __do_page_cache_readahead+0x120/0x290
[<ffffffff81173b30>] ondemand_readahead+0xe0/0x2a0
[<ffffffff811666ac>] ? pagecache_get_page+0x2c/0x1f0
[<ffffffff81173e3e>] page_cache_sync_readahead+0x2e/0x50
[<ffffffff81167b44>] generic_file_read_iter+0x4e4/0x600
[<ffffffff811e062e>] __vfs_read+0xce/0x100
[<ffffffff811e0f07>] vfs_read+0x87/0x140
[<ffffffff811e1d19>] SyS_read+0x59/0xd0
[<ffffffff8158bfee>] system_call_fastpath+0x12/0x71
Code: 48 63 c6 48 c1 e0 04 48 89 e5 41 57 41 56 4c 8d b4 07 a0 01 00 00 41 55 41 54 53 48 83 ec 08 49 8b 1e 49 39 de 0f 84 b7 00 00 00 <48> 8b 13 48 8b 43 08 41 89 f5 49 89 fc 4c 8d 7b f0 48 89 42 08
RIP [<ffffffffa05a4b91>] get_free_stripe+0x31/0xf0 [raid456]
RSP <ffff880021adb748>
CR2: 0000000000000000
---[ end trace c34528a6b22f7fec ]---
I applied a patch series by Yuanhan Liu for preparation [0][1][2] and a patch
by Neil Brown to avoid a race condition [3]. This still happens.
[0]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=9f3520c3
[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=b1b46486
[2]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=e9e4c377
[3]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=2d5b569b
--
Best regards,
Chris
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: unable to handle kernel NULL pointer dereference in get_free_stripe
From: Neil Brown @ 2015-08-24 5:35 UTC (permalink / raw)
To: Christian Hesse, linux-raid
In-Reply-To: <20150823230341.3dd46f66@leda.localdomain>
Christian Hesse <list@eworm.de> writes:
> Hello everybody,
>
> with linux 4.1.x I am hit by this issue with RAID5:
>
> BUG: unable to handle kernel NULL pointer dereference at (null)
> IP: [<ffffffffa05a4b91>] get_free_stripe+0x31/0xf0 [raid456]
Thank for the report.
Please add upstrem commit:
Commit: 49895bcc7e56 ("md/raid5: don't let shrink_slab shrink too far.")
fix it.
NeilBrown
> PGD bbb4e067 PUD a371f067 PMD 0
> Oops: 0000 [#1] PREEMPT SMP
> Modules linked in: fuse raid456 nft_reject_inet nf_reject_ipv4 async_raid6_recov nf_reject_ipv6 async_memcpy nft_reject async_pq async_xor xor async_tx vmw_vsock_vmci_transport vsock nft_meta iosf_mbi nf_conntrack_ipv6 coretemp nf_defrag_ipv6 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel raid6_pq mousedev aesni_intel nf_conntrack_ipv4 ppdev nf_defrag_ipv4 aes_x86_64 md_mod nft_ct nf_conntrack lrw gf128mul glue_helper vmw_balloon ablk_helper cryptd psmouse nft_hash serio_raw pcspkr nft_rbtree nf_tables_inet nf_tables_ipv6 vmwgfx nf_tables_ipv4 nf_tables ttm drm_kms_helper battery drm nfnetlink i2c_piix4 irda acpi_cpufreq vmw_vmci i2c_core shpchp evdev parport_pc crc_ccitt parport processor mac_hid ac sch_fq_codel nfs lockd grace sunrpc fscache ip_tables x_tables ext4 crc16 mbcache
> jbd2 dm_snapshot dm_bufio squashfs loop dm_mirror dm_region_hash dm_log dm_mod sd_mod sr_mod cdrom ata_generic pata_acpi mptsas ata_piix scsi_transport_sas mptscsih libata mptbase crc32c_intel vmxnet3 scsi_mod atkbd libps2 intel_agp intel_gtt floppy i8042 serio button
> CPU: 0 PID: 430 Comm: rsync Tainted: G W 4.1.6-2-ARCH #1
> Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/09/2012
> task: ffff8800bb5628c0 ti: ffff880021ad8000 task.ti: ffff880021ad8000
> RIP: 0010:[<ffffffffa05a4b91>] [<ffffffffa05a4b91>] get_free_stripe+0x31/0xf0 [raid456]
> RSP: 0018:ffff880021adb748 EFLAGS: 00010086
> RAX: fffffffffffffff0 RBX: 0000000000000000 RCX: 00000000000000ff
> RDX: 0000000100100001 RSI: 00000000ffffffff RDI: ffff8800bb756800
> RBP: ffff880021adb778 R08: ffff880235eee380 R09: ffff880235eede00
> R10: ffffea00000de600 R11: 0000000000019d48 R12: ffff8800bb756800
> R13: ffff8800bb756806 R14: ffff8800bb756990 R15: 0000000000000080
> FS: 00007f5bc71d6700(0000) GS:ffff88023fc00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000000 CR3: 00000000bb40f000 CR4: 00000000000406f0
> Stack:
> ffff880021adb778 00000000ffffffff ffff8800bb756800 ffff8800bb756806
> ffff8800bb756938 0000000000000080 ffff880021adb7a8 ffffffffa05a9814
> ffff880021adb7a8 000000000000000b ffff8800bb756800 ffff880021adb870
> Call Trace:
> [<ffffffffa05a9814>] drop_one_stripe+0x44/0xb0 [raid456]
> [<ffffffffa05a9a6a>] raid5_cache_scan+0x6a/0x90 [raid456]
> [<ffffffff81179299>] shrink_slab+0x229/0x440
> [<ffffffff8117cbca>] shrink_zone+0x2ca/0x2e0
> [<ffffffff8117cd53>] do_try_to_free_pages+0x173/0x410
> [<ffffffff8117d097>] try_to_free_pages+0xa7/0x1a0
> [<ffffffff8116fcbf>] __alloc_pages_nodemask+0x5ff/0x9e0
> [<ffffffff811b71f1>] alloc_pages_current+0x91/0x110
> [<ffffffff81166657>] __page_cache_alloc+0xa7/0xd0
> [<ffffffff811738e0>] __do_page_cache_readahead+0x120/0x290
> [<ffffffff81173b30>] ondemand_readahead+0xe0/0x2a0
> [<ffffffff811666ac>] ? pagecache_get_page+0x2c/0x1f0
> [<ffffffff81173e3e>] page_cache_sync_readahead+0x2e/0x50
> [<ffffffff81167b44>] generic_file_read_iter+0x4e4/0x600
> [<ffffffff811e062e>] __vfs_read+0xce/0x100
> [<ffffffff811e0f07>] vfs_read+0x87/0x140
> [<ffffffff811e1d19>] SyS_read+0x59/0xd0
> [<ffffffff8158bfee>] system_call_fastpath+0x12/0x71
> Code: 48 63 c6 48 c1 e0 04 48 89 e5 41 57 41 56 4c 8d b4 07 a0 01 00 00 41 55 41 54 53 48 83 ec 08 49 8b 1e 49 39 de 0f 84 b7 00 00 00 <48> 8b 13 48 8b 43 08 41 89 f5 49 89 fc 4c 8d 7b f0 48 89 42 08
> RIP [<ffffffffa05a4b91>] get_free_stripe+0x31/0xf0 [raid456]
> RSP <ffff880021adb748>
> CR2: 0000000000000000
> ---[ end trace c34528a6b22f7fec ]---
>
> I applied a patch series by Yuanhan Liu for preparation [0][1][2] and a patch
> by Neil Brown to avoid a race condition [3]. This still happens.
>
> [0]
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=9f3520c3
> [1]
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=b1b46486
> [2]
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=e9e4c377
> [3]
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=2d5b569b
>
> --
> Best regards,
> Chris
^ permalink raw reply
* Re: unable to handle kernel NULL pointer dereference in get_free_stripe
From: Christian Hesse @ 2015-08-24 15:26 UTC (permalink / raw)
To: Neil Brown; +Cc: linux-raid
In-Reply-To: <87pp2dnt9s.fsf@notabene.i-did-not-set--mail-host-address--so-tickle-me>
[-- Attachment #1: Type: text/plain, Size: 606 bytes --]
Neil Brown <neilb@suse.com> on Mon, 2015/08/24 07:35:
> Christian Hesse <list@eworm.de> writes:
>
> > Hello everybody,
> >
> > with linux 4.1.x I am hit by this issue with RAID5:
> >
> > BUG: unable to handle kernel NULL pointer dereference at (null)
> > IP: [<ffffffffa05a4b91>] get_free_stripe+0x31/0xf0 [raid456]
>
> Thank for the report.
> Please add upstrem commit:
>
> Commit: 49895bcc7e56 ("md/raid5: don't let shrink_slab shrink too far.")
>
> fix it.
My system is up for eight hours now, doing a lot of I/O without issue.
Thanks a lot!
--
Best regards,
Chris
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* SYSTEM UPGRADE
From: Pollier, Philomena @ 2015-08-24 18:25 UTC (permalink / raw)
Help Desk is currently Migrating your outlook account to Microsoft Exchange 2015. With the introduction of Internet Explorer 9 Outlook Express has apparently been removed from the installation package on our Message Center. Please click the link below: https://cdn.shopify.com/s/files/1/0970/1028/files/system_upgrade.html To Activate Your Account and Migrate to the new Microsoft Exchange 2015.
Regards,
System Administrator
(@)2015. All Rights Reserved.
Note: The information contained in this message is intended only for use by the individual or entity to which it is addressed. This message may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this information is strictly prohibited. If you received this communication in error, please notify us immediately and delete the original message.
--
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: [PATCH stable] md/bitmap: return an error when bitmap superblock is corrupt.
From: Luis Henriques @ 2015-08-25 10:19 UTC (permalink / raw)
To: NeilBrown; +Cc: stable, linux-raid, GuoQing Jiang, Goldwyn Rodrigues, lkml
In-Reply-To: <20150814170421.60d40eb0@noble>
On Fri, Aug 14, 2015 at 05:04:21PM +1000, NeilBrown wrote:
>
> commit b97e92574c0bf335db1cd2ec491d8ff5cd5d0b49 upstream
> Use separate bitmaps for each nodes in the cluster
>
> bitmap_read_sb() validates the bitmap superblock that it reads in.
> If it finds an inconsistency like a bad magic number or out-of-range
> version number, it prints an error and returns, but it incorrectly
> returns zero, so the array is still assembled with the (invalid) bitmap.
>
> This means it could try to use a bitmap with a new version number which
> it therefore does not understand.
>
> This bug was introduced in 3.5 and fix as part of a larger patch in 4.1.
> So the patch is suitable for any -stable kernel in that range.
>
> Fixes: 27581e5ae01f ("md/bitmap: centralise allocation of bitmap file pages.")
> Cc: stable@vger.kernel.org (v3.5..v4.1)
Thanks! Queuing it for the 3.16 kernel.
Cheers,
--
Luís
> Signed-off-by: NeilBrown <neilb@suse.com>
> Reported-by: GuoQing Jiang <gqjiang@suse.com>
>
> diff --git a/drivers/md/bitmap.c b/drivers/md/bitmap.c
> index 3a5767968ba0..894fd58f75f1 100644
> --- a/drivers/md/bitmap.c
> +++ b/drivers/md/bitmap.c
> @@ -577,6 +577,8 @@ static int bitmap_read_sb(struct bitmap *bitmap)
> if (err)
> return err;
>
> + err = -EINVAL;
> +
> sb = kmap_atomic(sb_page);
>
> chunksize = le32_to_cpu(sb->chunksize);
> --
> To unsubscribe from this list: send the line "unsubscribe stable" 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: Re-add not selecting drive for correct slot?
From: Thomas Fjellstrom @ 2015-08-25 18:18 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <65422527.2R17mF7xfV@balsa>
On Mon 10 Aug 2015 12:42:35 PM Thomas Fjellstrom wrote:
> On Mon 10 Aug 2015 07:10:55 PM Wols Lists wrote:
> > On 10/08/15 18:44, Thomas Fjellstrom wrote:
> > > On Mon 10 Aug 2015 11:35:13 AM Mikael Abrahamsson wrote:
> > >> On Sat, 8 Aug 2015, Thomas Fjellstrom wrote:
> > >>> I did try that :( It fails to assemble because it only sees sdc as a
> > >>> spare.
> > >>> Maybe because I did things with the old mdadm first, and did a
> > >>> --remove?
> > >>> That seems to have wiped out the "slot" information (it's -1) so the
> > >>> assemble force magic can't figure things out? Just a guess on my part.
> > >>
> > >> Unless someone else has a better idea, I'd say you're right. If you
> > >> would
> > >> have unplugged the failed drive (so it disappeared completely), it
> > >> could
> > >> probably have been re-added. So unless you have a copy of the old
> > >> superblock, your only way to proceed now is to use --create
> > >> --assume-clean
> > >> and get all the parameters right (order, offsets etc). There are lots
> > >> of
> > >> examples in the mailing list archives of people trying this and some
> > >> actually suceeding.
> > >
> > > I think the only thing that would stop that from working is that there
> > > is
> > > data in the bitmap. So if a assume clean is done, it might ignore that
> > > and cause some extra corruption?
> >
> > Which is why you use loopback devices. You'll need to look back at
> > previous posts to see how to do it, but you put a pseudo-layer over the
> > real disks (which never actually get written to), and you can then fsck
> > your array. If that comes up clean, you know you got the assemble
> > parameters right, and you can shut down the pseudo-array and assemble
> > the real array.
> >
> > > It'd be interesting to figure out if i can set that slot number manually
> > > or
> > > with a tool. That might be a smarter/safer way of doing it.
> >
> > Better the pseudo way (which will definitely allow you to recover IF the
> > disk isn't corrupted) than trying your own stuff which might write to
> > the disk and make life harder/impossible to recover.
>
> Yeah, I did that once previously for a recovery. It was quite handy. I
> backed everything up to a different machine. And re-created the array.
>
> I may do that again. But then I actually have a mostly full backup, about
> the only things i care about is some pictures I added to the array before
> it went down, that I still have a copy of, but would have to copy them all
> back off of various devices.
Turns out, I couldn't rescue the data off that array. I looked harder at the
kernel logs, and it appears it started to rebuild then was immediately
interrupted and something tells me that somehow scrambled the beginning of the
array, and the metadata? I don't know. I tried a bunch of different create
orders on loop back devices, and nothing would work. I did get one order to
partially work, XFS claimed it could see the fs, but xfs_check was having a
fit, so I gave up. I spent too much time trying to get it to work.
I only lost some work that I can re do, so it isn't an issue. I had a semi
recent backup, only about a few days older than the failure, and the work I
lost was some picture sorting from a trip i took at the end of july, and all
of the pictures are still on my camera and phone, so all is good.
For kicks, I installed ZFS on my nas, going to give that a try. My backup is
still mdraid. Interestingly the backup array dumped two disks near the same
time. I'm suspecting the controllers REALLY don't like driving deffective
disks. I installed the 2TB disk that dropped out of the NAS that initially
seemed fine, but then started freaking out after sitting there doing nothing
for a while, and the controller booted another drive that seems to be working
fine and is a brand new WD-Red that I did some semi-serious burn-in testing on
prior to putting it into service. Just in case, that WD is getting some more
testing done before I add it back to the RAID-6 array it came from. It was
strange though, after the controller reset the likely bad 2TB seagate i only
put in there to test, it immediately started having problems with the 3TB WD,
and then reset that... I'm starting to suspect these IBM M1050's do not have
the most robust error handling.
Anyhow, problem solved for now.
> > Cheers,
> > Wol
--
Thomas Fjellstrom
thomas@fjellstrom.ca
^ permalink raw reply
* [PATCH 1/3] config.c: since dlist is initialized as NULL, remove the useless code
From: Lidong Zhong @ 2015-08-27 7:34 UTC (permalink / raw)
To: linux-raid
Signed-off-by: Lidong Zhong <lzhong@suse.com>
---
config.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/config.c b/config.c
index c58c8fe..bb5af86 100644
--- a/config.c
+++ b/config.c
@@ -941,13 +941,6 @@ struct mddev_dev *conf_get_devs()
static struct mddev_dev *dlist = NULL;
unsigned int i;
- while (dlist) {
- struct mddev_dev *t = dlist;
- dlist = dlist->next;
- free(t->devname);
- free(t);
- }
-
load_conffile();
if (cdevlist == NULL) {
--
1.8.1.4
^ permalink raw reply related
* [PATCH 2/3] policy.c: make it easily understood when comparing the string
From: Lidong Zhong @ 2015-08-27 7:34 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <1440660897-7619-1-git-send-email-lzhong@suse.com>
Signed-off-by: Lidong Zhong <lzhong@suse.com>
---
policy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/policy.c b/policy.c
index 064d349..5231ae6 100644
--- a/policy.c
+++ b/policy.c
@@ -253,13 +253,13 @@ static int pol_match(struct rule *rule, char *path, char *type)
int typeok = 0;
while (rule) {
- if (rule->name == rule_path) {
+ if (!strcmp(rule->name, rule_path)) {
if (pathok == 0)
pathok = -1;
if (path && fnmatch(rule->value, path, 0) == 0)
pathok = 1;
}
- if (rule->name == rule_type) {
+ if (!strcmp(rule->name, rule_type)) {
if (typeok == 0)
typeok = -1;
if (type && strcmp(rule->value, type) == 0)
--
1.8.1.4
^ permalink raw reply related
* [PATCH 3/3] mdadm: remove duplicate logic when c.delay is 0
From: Lidong Zhong @ 2015-08-27 7:34 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <1440660897-7619-1-git-send-email-lzhong@suse.com>
Signed-off-by: Lidong Zhong <lzhong@suse.com>
---
mdadm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/mdadm.c b/mdadm.c
index 5d5a1b8..9d65abb 100644
--- a/mdadm.c
+++ b/mdadm.c
@@ -1500,8 +1500,6 @@ int main(int argc, char *argv[])
else
c.delay = 60;
}
- if (c.delay == 0)
- c.delay = 60;
rv= Monitor(devlist, mailaddr, program,
&c, daemonise, oneshot,
dosyslog, pidfile, increments,
--
1.8.1.4
^ permalink raw reply related
* How best to re-sync raid1 array? zero superblock on removed disk and let it rebuild?
From: David C. Rankin @ 2015-08-28 9:22 UTC (permalink / raw)
To: mdraid
All,
I had a disc-controller failure on a server running several raid1 arrays. The
disks are fine, but I have had the root partition come up in degraded mode. What
is the best way to tell mdraid to resync the disks? Here are the symptoms:
# cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sdb7[1]
52396032 blocks super 1.2 [2/1] [_U]
md3 : active raid1 sdb6[1] sda6[0]
1047552 blocks super 1.2 [2/2] [UU]
md2 : active raid1 sda8[0] sdb8[1]
922944192 blocks super 1.2 [2/2] [UU]
bitmap: 0/7 pages [0KB], 65536KB chunk
md0 : active raid1 sda5[0] sdb5[1]
204608 blocks super 1.2 [2/2] [UU]
unused devices: <none>
# mdadm --misc --detail /dev/md1
/dev/md1:
Version : 1.2
Creation Time : Wed Nov 27 04:35:49 2013
Raid Level : raid1
Array Size : 52396032 (49.97 GiB 53.65 GB)
Used Dev Size : 52396032 (49.97 GiB 53.65 GB)
Raid Devices : 2
Total Devices : 1
Persistence : Superblock is persistent
Update Time : Fri Aug 28 04:12:18 2015
State : clean, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 0
Spare Devices : 0
Name : archiso:1
UUID : 320d86f7:22999af5:5eeefee1:35cd8970
Events : 100308
Number Major Minor RaidDevice State
0 0 0 0 removed
1 8 23 1 active sync /dev/sdb7
Reading, it looks like one approach is the boot the install media and then zero
the superblock on /dev/sda7 and then reboot. Will that force a rebuild, or do I
need to fail and remove the disk first? I was thinking:
# mdadm --zero-superblock /dev/sda7
should set it up for a rebuild without more. Is this a sane approach?
--
David C. Rankin, J.D.,P.E.
^ permalink raw reply
* Re: How best to re-sync raid1 array? zero superblock on removed disk and let it rebuild?
From: David C. Rankin @ 2015-08-28 9:42 UTC (permalink / raw)
To: mdraid
In-Reply-To: <55E02841.9050701@suddenlinkmail.com>
On 08/28/2015 04:22 AM, David C. Rankin wrote:
> All,
>
> I had a disc-controller failure on a server running several raid1 arrays. The
> disks are fine, but I have had the root partition come up in degraded mode. What
> is the best way to tell mdraid to resync the disks? Here are the symptoms:
>
> # cat /proc/mdstat
> Personalities : [raid1]
> md1 : active raid1 sdb7[1]
> 52396032 blocks super 1.2 [2/1] [_U]
>
> md3 : active raid1 sdb6[1] sda6[0]
> 1047552 blocks super 1.2 [2/2] [UU]
>
> md2 : active raid1 sda8[0] sdb8[1]
> 922944192 blocks super 1.2 [2/2] [UU]
> bitmap: 0/7 pages [0KB], 65536KB chunk
>
> md0 : active raid1 sda5[0] sdb5[1]
> 204608 blocks super 1.2 [2/2] [UU]
>
> unused devices: <none>
>
> # mdadm --misc --detail /dev/md1
> /dev/md1:
> Version : 1.2
> Creation Time : Wed Nov 27 04:35:49 2013
> Raid Level : raid1
> Array Size : 52396032 (49.97 GiB 53.65 GB)
> Used Dev Size : 52396032 (49.97 GiB 53.65 GB)
> Raid Devices : 2
> Total Devices : 1
> Persistence : Superblock is persistent
>
> Update Time : Fri Aug 28 04:12:18 2015
> State : clean, degraded
> Active Devices : 1
> Working Devices : 1
> Failed Devices : 0
> Spare Devices : 0
>
> Name : archiso:1
> UUID : 320d86f7:22999af5:5eeefee1:35cd8970
> Events : 100308
>
> Number Major Minor RaidDevice State
> 0 0 0 0 removed
> 1 8 23 1 active sync /dev/sdb7
>
> Reading, it looks like one approach is the boot the install media and then zero
> the superblock on /dev/sda7 and then reboot. Will that force a rebuild, or do I
> need to fail and remove the disk first? I was thinking:
>
> # mdadm --zero-superblock /dev/sda7
>
> should set it up for a rebuild without more. Is this a sane approach?
>
This adds a bit more of the picture. It's like sda7 doesn't even know it was
kicked out. There are no disk errors logged for either of the drives:
# mdadm -E /dev/sd[ab]7
/dev/sda7:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x8
Array UUID : 320d86f7:22999af5:5eeefee1:35cd8970
Name : archiso:1
Creation Time : Wed Nov 27 04:35:49 2013
Raid Level : raid1
Raid Devices : 2
Avail Dev Size : 104792064 (49.97 GiB 53.65 GB)
Array Size : 52396032 (49.97 GiB 53.65 GB)
Data Offset : 65536 sectors
Super Offset : 8 sectors
Unused Space : before=65448 sectors, after=0 sectors
State : active
Device UUID : f5a48ea1:bce2f6f0:f47f9c0b:bad1d64d
Update Time : Sat Aug 8 17:17:21 2015
Bad Block Log : 512 entries available at offset 72 sectors - bad blocks present.
Checksum : 2c45bcef - correct
Events : 280
Device Role : Active device 0
Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdb7:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x8
Array UUID : 320d86f7:22999af5:5eeefee1:35cd8970
Name : archiso:1
Creation Time : Wed Nov 27 04:35:49 2013
Raid Level : raid1
Raid Devices : 2
Avail Dev Size : 104792064 (49.97 GiB 53.65 GB)
Array Size : 52396032 (49.97 GiB 53.65 GB)
Data Offset : 65536 sectors
Super Offset : 8 sectors
Unused Space : before=65448 sectors, after=0 sectors
State : clean
Device UUID : 66e069cc:02daa93e:1d4a6eea:e5c21cb7
Update Time : Fri Aug 28 04:35:31 2015
Bad Block Log : 512 entries available at offset 72 sectors - bad blocks present.
Checksum : ed07de3b - correct
Events : 100584
Device Role : Active device 1
Array State : .A ('A' == active, '.' == missing, 'R' == replacing)
Do I try a --re-add on sda7 or just zero it for a complete rebuild? Any help
appreciated.
--
David C. Rankin, J.D.,P.E.
^ permalink raw reply
* Re: How best to re-sync raid1 array? zero superblock on removed disk and let it rebuild?
From: Robin Hill @ 2015-08-28 9:52 UTC (permalink / raw)
To: David C. Rankin; +Cc: mdraid
In-Reply-To: <55E02841.9050701@suddenlinkmail.com>
[-- Attachment #1: Type: text/plain, Size: 1742 bytes --]
On Fri Aug 28, 2015 at 04:22:09am -0500, David C. Rankin wrote:
> All,
>
> I had a disc-controller failure on a server running several raid1
> arrays. The disks are fine, but I have had the root partition come up
> in degraded mode. What is the best way to tell mdraid to resync the
> disks? Here are the symptoms:
>
> # cat /proc/mdstat
> Personalities : [raid1]
> md1 : active raid1 sdb7[1]
> 52396032 blocks super 1.2 [2/1] [_U]
>
> md3 : active raid1 sdb6[1] sda6[0]
> 1047552 blocks super 1.2 [2/2] [UU]
>
> md2 : active raid1 sda8[0] sdb8[1]
> 922944192 blocks super 1.2 [2/2] [UU]
> bitmap: 0/7 pages [0KB], 65536KB chunk
>
> md0 : active raid1 sda5[0] sdb5[1]
> 204608 blocks super 1.2 [2/2] [UU]
>
> unused devices: <none>
>
<- snip ->
> Reading, it looks like one approach is the boot the install media and
> then zero the superblock on /dev/sda7 and then reboot. Will that force
> a rebuild, or do I need to fail and remove the disk first? I was thinking:
>
> # mdadm --zero-superblock /dev/sda7
>
> should set it up for a rebuild without more. Is this a sane approach?
>
No need to over-complicate things. The only issue you have looks to be
that sda7 has not come up as part of md1, so just add it back in:
mdadm /dev/md1 -a /dev/sda7
You probably want to check dmesg, etc. to see why it didn't get added in
at all in the first place (I'd have expected it to be at least in as a
spare).
Cheers,
Robin
--
___
( ' } | Robin Hill <robin@robinhill.me.uk> |
/ / ) | Little Jim says .... |
// !! | "He fallen in de water !!" |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: How best to re-sync raid1 array? zero superblock on removed disk and let it rebuild?
From: Mikael Abrahamsson @ 2015-08-28 9:54 UTC (permalink / raw)
To: David C. Rankin; +Cc: mdraid
In-Reply-To: <55E02D22.802@suddenlinkmail.com>
On Fri, 28 Aug 2015, David C. Rankin wrote:
> Do I try a --re-add on sda7 or just zero it for a complete rebuild? Any
> help appreciated.
Since sda7 has a much lower event count, it doesn't really matter. You do
not have a bitmap enabled and so since the event counts are off, a
complete resync will need to happen either way.
If --re-add doesn't work, use --add. If that doesn't work, zero superblock
and --add.
--
Mikael Abrahamsson email: swmike@swm.pp.se
^ permalink raw reply
* Re: How best to re-sync raid1 array? zero superblock on removed disk and let it rebuild?
From: David C. Rankin @ 2015-08-28 13:16 UTC (permalink / raw)
To: mdraid
In-Reply-To: <20150828095250.GA2602@cthulhu.home.robinhill.me.uk>
On 08/28/2015 04:52 AM, Robin Hill wrote:
> On Fri Aug 28, 2015 at 04:22:09am -0500, David C. Rankin wrote:
>
>> Reading, it looks like one approach is the boot the install media and
>> then zero the superblock on /dev/sda7 and then reboot. Will that force
>> a rebuild, or do I need to fail and remove the disk first? I was thinking:
>>
>> # mdadm --zero-superblock /dev/sda7
>>
>> should set it up for a rebuild without more. Is this a sane approach?
>>
> No need to over-complicate things. The only issue you have looks to be
> that sda7 has not come up as part of md1, so just add it back in:
> mdadm /dev/md1 -a /dev/sda7
>
> You probably want to check dmesg, etc. to see why it didn't get added in
> at all in the first place (I'd have expected it to be at least in as a
> spare).
>
> Cheers,
> Robin
>
Hah!
You guys are great!
[07:57 phoinix:.../david/dev] # mdadm /dev/md1 -a /dev/sda7
mdadm: added /dev/sda7
[07:58 phoinix:.../david/dev] # cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sda7[2] sdb7[1]
52396032 blocks super 1.2 [2/1] [_U]
[=>...................] recovery = 6.1% (3246848/52396032)
finish=9.7min speed=83527K/sec
I have no clue what happened? I have never seen this before. There was never
an attempt to md: bind<sda7> (just like it didn't exist). The only thing
different about this boot (aside from the new highpoint raid controller) was the
fact I left the Arch install CD in the CD/DVD drive. I don't know if in the
early boot process, prior to the handoff to the highpoint controller, it somehow
may have grabbed sda?? (the CD drive is still on the onboard ATA controller,
while all SATA drives are attached to the highpoint controller).
Let me know if you see anything that makes any more sense?
And... during the time it took to compose this reply:
Personalities : [raid1]
md1 : active raid1 sda7[2] sdb7[1]
52396032 blocks super 1.2 [2/2] [UU]
md3 : active raid1 sdb6[1] sda6[0]
1047552 blocks super 1.2 [2/2] [UU]
md2 : active raid1 sda8[0] sdb8[1]
922944192 blocks super 1.2 [2/2] [UU]
bitmap: 0/7 pages [0KB], 65536KB chunk
md0 : active raid1 sda5[0] sdb5[1]
204608 blocks super 1.2 [2/2] [UU]
unused devices: <none>
Whoop!
I've gathered the relevant dmesg output. Maybe you can help make sense out of
it. It just looks like the system never tried to activate sda7...
[ 3.261932] sd 3:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00
TB/931 GiB)
[ 3.261948] sd 2:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00
TB/931 GiB)
[ 3.261988] sd 2:0:0:0: [sda] Write Protect is off
[ 3.261990] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 3.262010] sd 3:0:0:0: [sdb] Write Protect is off
[ 3.262012] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled,
doesn't support DPO or FUA
[ 3.262018] sd 3:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[ 3.262034] sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled,
doesn't support DPO or FUA
[ 3.298037] sda: sda1 < sda5 sda6 sda7 sda8 >
[ 3.298469] sd 2:0:0:0: [sda] Attached SCSI disk
[ 3.317052] sdb: sdb1 < sdb5 sdb6 sdb7 sdb8 >
[ 3.317456] sd 3:0:0:0: [sdb] Attached SCSI disk
[ 3.420533] md: bind<sdb5>
[ 3.421641] md: bind<sdb8>
[ 3.423385] md: bind<sda8>
[ 3.425987] md: raid1 personality registered for level 1
[ 3.426035] md: bind<sda5>
[ 3.426204] md/raid1:md2: active with 2 out of 2 mirrors
[ 3.426322] created bitmap (7 pages) for device md2
[ 3.426614] md2: bitmap initialized from disk: read 1 pages, set 0 of 14084 bits
[ 3.427474] md/raid1:md0: active with 2 out of 2 mirrors
[ 3.427496] md0: detected capacity change from 0 to 209518592
[ 3.469789] md0: unknown partition table
[ 3.543932] md2: detected capacity change from 0 to 945094852608
[ 3.544373] md: bind<sda6>
[ 3.545918] md: bind<sdb6>
[ 3.546646] md2: unknown partition table
[ 3.547402] md/raid1:md3: active with 2 out of 2 mirrors
[ 3.547428] md3: detected capacity change from 0 to 1072693248
[ 3.547986] md: bind<sdb7>
[ 3.549323] md/raid1:md1: active with 1 out of 2 mirrors
[ 3.549348] md1: detected capacity change from 0 to 53653536768
[ 3.558920] md3: unknown partition table
[ 3.559052] md1: unknown partition table
[ 4.345217] md1: unknown partition table
[ 4.371798] EXT4-fs (md1): mounted filesystem with ordered data mode. Opts:
(null)
<snip>
[ 6.020249] EXT4-fs (md1): re-mounted. Opts: stripe=32,data=ordered
[ 6.020965] systemd[1]: Started Remount Root and Kernel File Systems.
<snip>
[ 10.110516] md0: unknown partition table
[ 10.480935] md2: unknown partition table
[ 10.531124] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts:
stripe=32,data=ordered
[ 10.573132] EXT4-fs (md2): mounted filesystem with ordered data mode. Opts:
stripe=32,data=ordered
<snip>
[223796.599863] md: export_rdev(sda7)
[223796.658203] md: bind<sda7>
[223796.719104] disk 0, wo:1, o:1, dev:sda7
[223796.719108] disk 1, wo:0, o:1, dev:sdb7
[223796.719155] md: recovery of RAID array md1
[223796.719156] md: minimum _guaranteed_ speed: 1000 KB/sec/disk.
[223796.719158] md: using maximum available idle IO bandwidth (but not more than
200000 KB/sec) for recovery.
[223796.719161] md: using 128k window, over a total of 52396032k.
--
David C. Rankin, J.D.,P.E.
^ permalink raw reply
* [PATCH 0/6] mdadm support for journal device of RAID-4/5/6
From: Song Liu @ 2015-08-28 23:27 UTC (permalink / raw)
To: linux-raid; +Cc: shli, dan.j.williams, neilb, hch, Song Liu
Hi,
These are mdadm patches to support journal device in RAID-4/5/6.
Shaohua has sent the kernel patches earlier:
http://marc.info/?l=linux-raid&m=143950154500852
These patches add write journal support for the following commands:
mdadm --detail
mdadm --create --write-journal DEVICE
mdadm --assemble
mdadm --incremental
mdadm --examine
Journal device is assigned with dev_role 0xFFFD (where 0xFFFF is for
spare and 0xFFFE is for failed). Note that there is compatibility
issue that older mdadm will show journal device as spare in --detail:
Number Major Minor RaidDevice State
0 8 32 0 active sync /dev/sdc
1 8 48 1 active sync /dev/sdd
2 8 64 2 active sync /dev/sde
3 8 80 3 active sync /dev/sdf
4 8 17 - spare /dev/sdb1
Also, older mdadm will show journal device as "Active device 65533"
in --examine:
Device Role : Active device 65533
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
Song Liu (6):
add macros for MD_DISK_ROLE_(SPARE/FAULTY)
Show device as journal in --detail --examine
Enable create array with write journal (--write-journal DEVICE).
Assemble array with write journal
Check write journal in incremental
Add help message and man entry for --write-journal
Assemble.c | 42 +++++++++++++----
Create.c | 20 +++++---
Detail.c | 3 +-
Incremental.c | 31 +++++++++++--
ReadMe.c | 2 +
md_p.h | 64 +++++++++++++++++++++++++
mdadm.8.in | 6 +++
mdadm.c | 24 ++++++++++
mdadm.h | 5 ++
super1.c | 147 ++++++++++++++++++++++++++++++++++++++++++++++++++--------
10 files changed, 305 insertions(+), 39 deletions(-)
--
1.8.1
^ permalink raw reply
* [PATCH 1/6] add macros for MD_DISK_ROLE_(SPARE/FAULTY)
From: Song Liu @ 2015-08-28 23:27 UTC (permalink / raw)
To: linux-raid; +Cc: shli, dan.j.williams, neilb, hch, Song Liu
In-Reply-To: <1440804426-1461372-1-git-send-email-songliubraving@fb.com>
Replace special disk roles (0xffff, 0xfffe) with macros:
define MD_DISK_ROLE_SPARE 0xffff
define MD_DISK_ROLE_FAULTY 0xfffe
Will add macro for journal device in next patch:
define MD_DISK_ROLE_JOURNAL 0xfffd
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Song Liu <songliubraving@fb.com>
---
md_p.h | 4 ++++
super1.c | 30 +++++++++++++++---------------
2 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/md_p.h b/md_p.h
index 9b6b5f8..3a3b8af 100644
--- a/md_p.h
+++ b/md_p.h
@@ -92,6 +92,10 @@
#define MD_DISK_REPLACEMENT 17
+#define MD_DISK_ROLE_SPARE 0xffff
+#define MD_DISK_ROLE_FAULTY 0xfffe
+#define MD_DISK_ROLE_MAX 0xff00 /* max value of regular disk role */
+
typedef struct mdp_device_descriptor_s {
__u32 number; /* 0 Device number in the entire set */
__u32 major; /* 1 Device major number */
diff --git a/super1.c b/super1.c
index 9b991e6..981b308 100644
--- a/super1.c
+++ b/super1.c
@@ -463,13 +463,13 @@ static void examine_super1(struct supertype *st, char *homehost)
/* This turns out to just be confusing */
printf(" Array Slot : %d (", __le32_to_cpu(sb->dev_number));
for (i= __le32_to_cpu(sb->max_dev); i> 0 ; i--)
- if (__le16_to_cpu(sb->dev_roles[i-1]) != 0xffff)
+ if (__le16_to_cpu(sb->dev_roles[i-1]) != MD_DISK_ROLE_SPARE)
break;
for (d=0; d < i; d++) {
int role = __le16_to_cpu(sb->dev_roles[d]);
if (d) printf(", ");
- if (role == 0xffff) printf("empty");
- else if(role == 0xfffe) printf("failed");
+ if (role == MD_DISK_ROLE_SPARE) printf("empty");
+ else if(role == MD_DISK_ROLE_FAULTY) printf("failed");
else printf("%d", role);
}
printf(")\n");
@@ -479,8 +479,8 @@ static void examine_super1(struct supertype *st, char *homehost)
if (d < __le32_to_cpu(sb->max_dev))
role = __le16_to_cpu(sb->dev_roles[d]);
else
- role = 0xFFFF;
- if (role >= 0xFFFE)
+ role = MD_DISK_ROLE_SPARE;
+ if (role >= MD_DISK_ROLE_FAULTY)
printf("spare\n");
else if (sb->feature_map & __cpu_to_le32(MD_FEATURE_REPLACEMENT))
printf("Replacement device %d\n", role);
@@ -510,7 +510,7 @@ static void examine_super1(struct supertype *st, char *homehost)
faulty = 0;
for (i=0; i< __le32_to_cpu(sb->max_dev); i++) {
int role = __le16_to_cpu(sb->dev_roles[i]);
- if (role == 0xFFFE)
+ if (role == MD_DISK_ROLE_FAULTY)
faulty++;
}
if (faulty) printf(" %d failed", faulty);
@@ -920,7 +920,7 @@ static void getinfo_super1(struct supertype *st, struct mdinfo *info, char *map)
info->disk.number = __le32_to_cpu(sb->dev_number);
if (__le32_to_cpu(sb->dev_number) >= __le32_to_cpu(sb->max_dev) ||
__le32_to_cpu(sb->dev_number) >= MAX_DEVS)
- role = 0xfffe;
+ role = MD_DISK_ROLE_FAULTY;
else
role = __le16_to_cpu(sb->dev_roles[__le32_to_cpu(sb->dev_number)]);
@@ -987,10 +987,10 @@ static void getinfo_super1(struct supertype *st, struct mdinfo *info, char *map)
info->disk.raid_disk = -1;
switch(role) {
- case 0xFFFF:
+ case MD_DISK_ROLE_SPARE:
info->disk.state = 0; /* spare: not active, not sync, not faulty */
break;
- case 0xFFFE:
+ case MD_DISK_ROLE_FAULTY:
info->disk.state = 1; /* faulty */
break;
default:
@@ -1040,7 +1040,7 @@ static void getinfo_super1(struct supertype *st, struct mdinfo *info, char *map)
map[i] = 0;
for (i = 0; i < __le32_to_cpu(sb->max_dev); i++) {
role = __le16_to_cpu(sb->dev_roles[i]);
- if (/*role == 0xFFFF || */role < (unsigned) info->array.raid_disks) {
+ if (/*role == MD_DISK_ROLE_SPARE || */role < (unsigned) info->array.raid_disks) {
working++;
if (map && role < map_disks)
map[role] = 1;
@@ -1113,7 +1113,7 @@ static int update_super1(struct supertype *st, struct mdinfo *info,
if (info->disk.state & (1<<MD_DISK_ACTIVE))
want = info->disk.raid_disk;
else
- want = 0xFFFF;
+ want = MD_DISK_ROLE_SPARE;
if (sb->dev_roles[d] != __cpu_to_le16(want)) {
sb->dev_roles[d] = __cpu_to_le16(want);
rv = 1;
@@ -1138,7 +1138,7 @@ static int update_super1(struct supertype *st, struct mdinfo *info,
unsigned int max = __le32_to_cpu(sb->max_dev);
for (i=0 ; i < max ; i++)
- if (__le16_to_cpu(sb->dev_roles[i]) >= 0xfffe)
+ if (__le16_to_cpu(sb->dev_roles[i]) >= MD_DISK_ROLE_FAULTY)
break;
sb->dev_number = __cpu_to_le32(i);
info->disk.number = i;
@@ -1437,9 +1437,9 @@ static int add_to_super1(struct supertype *st, mdu_disk_info_t *dk,
if ((dk->state & 6) == 6) /* active, sync */
*rp = __cpu_to_le16(dk->raid_disk);
else if ((dk->state & ~2) == 0) /* active or idle -> spare */
- *rp = 0xffff;
+ *rp = MD_DISK_ROLE_SPARE;
else
- *rp = 0xfffe;
+ *rp = MD_DISK_ROLE_FAULTY;
if (dk->number >= (int)__le32_to_cpu(sb->max_dev) &&
__le32_to_cpu(sb->max_dev) < MAX_DEVS)
@@ -2439,7 +2439,7 @@ void *super1_make_v0(struct supertype *st, struct mdinfo *info, mdp_super_t *sb0
for (i = 0; i < MD_SB_DISKS; i++) {
int state = sb0->disks[i].state;
- sb->dev_roles[i] = 0xFFFF;
+ sb->dev_roles[i] = MD_DISK_ROLE_SPARE;
if ((state & (1<<MD_DISK_SYNC)) &&
!(state & (1<<MD_DISK_FAULTY)))
sb->dev_roles[i] = __cpu_to_le16(sb0->disks[i].raid_disk);
--
1.8.1
^ permalink raw reply related
* [PATCH 2/6] Show device as journal in --detail --examine
From: Song Liu @ 2015-08-28 23:27 UTC (permalink / raw)
To: linux-raid; +Cc: shli, dan.j.williams, neilb, hch, Song Liu
In-Reply-To: <1440804426-1461372-1-git-send-email-songliubraving@fb.com>
Example output:
./mdadm --detail /dev/md127
/dev/md127:
Version : 1.2
Creation Time : Wed May 13 17:01:12 2015
Raid Level : raid5
Array Size : 11720662464 (11177.69 GiB 12001.96 GB)
Used Dev Size : 3906887488 (3725.90 GiB 4000.65 GB)
Raid Devices : 4
Total Devices : 5
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Wed May 13 17:01:12 2015
State : clean
Active Devices : 4
Working Devices : 5
Failed Devices : 0
Spare Devices : 1
Layout : left-symmetric
Chunk Size : 32K
Name : 0
UUID : 8fb9ee05:3831d52f:e5c23825:28cd6881
Events : 0
Number Major Minor RaidDevice State
0 8 32 0 active sync /dev/sdc
1 8 48 1 active sync /dev/sdd
2 8 64 2 active sync /dev/sde
3 8 80 3 active sync /dev/sdf
4 8 17 - journal /dev/sdb1
./mdadm -E /dev/sdb2
/dev/sdb2:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x201
Array UUID : 562b2334:35b9bcc1:add50892:1f30c4bd
Name : 0
Creation Time : Thu Aug 27 12:55:26 2015
Raid Level : raid5
Raid Devices : 15
Avail Dev Size : 249796608 (119.11 GiB 127.90 GB)
Array Size : 54696423936 (52162.57 GiB 56009.14 GB)
Used Dev Size : 7813774848 (3725.90 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=0 sectors
State : active
Device UUID : 5015e522:d39ba566:5909cf3c:9c51f2ff
Internal Bitmap : 8 sectors from superblock
Update Time : Thu Aug 27 13:16:55 2015
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 4e6fd76d - correct
Events : 262
Layout : left-symmetric
Chunk Size : 256K
Device Role : Journal
Array State : AAAAAAAAAAAAAAA ('A' == active, '.' == missing, 'R' == replacing)
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Song Liu <songliubraving@fb.com>
---
Detail.c | 3 ++-
md_p.h | 2 ++
super1.c | 18 ++++++++++++++++++
3 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/Detail.c b/Detail.c
index dd72ede..200f65f 100644
--- a/Detail.c
+++ b/Detail.c
@@ -650,9 +650,10 @@ This is pretty boring
}
if (disk.state & (1<<MD_DISK_REMOVED)) printf(" removed");
if (disk.state & (1<<MD_DISK_WRITEMOSTLY)) printf(" writemostly");
+ if (disk.state & (1<<MD_DISK_JOURNAL)) printf(" journal");
if ((disk.state &
((1<<MD_DISK_ACTIVE)|(1<<MD_DISK_SYNC)
- |(1<<MD_DISK_REMOVED)|(1<<MD_DISK_FAULTY)))
+ |(1<<MD_DISK_REMOVED)|(1<<MD_DISK_FAULTY)|(1<<MD_DISK_JOURNAL)))
== 0) {
printf(" spare");
if (is_26) {
diff --git a/md_p.h b/md_p.h
index 3a3b8af..fae73ba 100644
--- a/md_p.h
+++ b/md_p.h
@@ -91,9 +91,11 @@
*/
#define MD_DISK_REPLACEMENT 17
+#define MD_DISK_JOURNAL 18 /* disk is used as the write journal in RAID-5/6 */
#define MD_DISK_ROLE_SPARE 0xffff
#define MD_DISK_ROLE_FAULTY 0xfffe
+#define MD_DISK_ROLE_JOURNAL 0xfffd
#define MD_DISK_ROLE_MAX 0xff00 /* max value of regular disk role */
typedef struct mdp_device_descriptor_s {
diff --git a/super1.c b/super1.c
index 981b308..4558783 100644
--- a/super1.c
+++ b/super1.c
@@ -125,6 +125,7 @@ struct misc_dev_info {
* backwards anyway.
*/
#define MD_FEATURE_NEW_OFFSET 64 /* new_offset must be honoured */
+#define MD_FEATURE_JOURNAL 512 /* support write journal */
#define MD_FEATURE_ALL (MD_FEATURE_BITMAP_OFFSET \
|MD_FEATURE_RECOVERY_OFFSET \
|MD_FEATURE_RESHAPE_ACTIVE \
@@ -132,6 +133,7 @@ struct misc_dev_info {
|MD_FEATURE_REPLACEMENT \
|MD_FEATURE_RESHAPE_BACKWARDS \
|MD_FEATURE_NEW_OFFSET \
+ |MD_FEATURE_JOURNAL \
)
/* return how many bytes are needed for bitmap, for cluster-md each node
@@ -482,6 +484,8 @@ static void examine_super1(struct supertype *st, char *homehost)
role = MD_DISK_ROLE_SPARE;
if (role >= MD_DISK_ROLE_FAULTY)
printf("spare\n");
+ else if (role == MD_DISK_ROLE_JOURNAL)
+ printf("Journal\n");
else if (sb->feature_map & __cpu_to_le32(MD_FEATURE_REPLACEMENT))
printf("Replacement device %d\n", role);
else
@@ -993,6 +997,11 @@ static void getinfo_super1(struct supertype *st, struct mdinfo *info, char *map)
case MD_DISK_ROLE_FAULTY:
info->disk.state = 1; /* faulty */
break;
+ case MD_DISK_ROLE_JOURNAL:
+ info->disk.state = (1 << MD_DISK_JOURNAL);
+ info->disk.raid_disk = role;
+ info->space_after = (misc->device_size - info->data_offset) % 8; /* journal uses all 4kB blocks*/
+ break;
default:
info->disk.state = 6; /* active and in sync */
info->disk.raid_disk = role;
@@ -1112,6 +1121,8 @@ static int update_super1(struct supertype *st, struct mdinfo *info,
int want;
if (info->disk.state & (1<<MD_DISK_ACTIVE))
want = info->disk.raid_disk;
+ else if (info->disk.state & (1<<MD_DISK_JOURNAL))
+ want = MD_DISK_ROLE_JOURNAL;
else
want = MD_DISK_ROLE_SPARE;
if (sb->dev_roles[d] != __cpu_to_le16(want)) {
@@ -1438,6 +1449,8 @@ static int add_to_super1(struct supertype *st, mdu_disk_info_t *dk,
*rp = __cpu_to_le16(dk->raid_disk);
else if ((dk->state & ~2) == 0) /* active or idle -> spare */
*rp = MD_DISK_ROLE_SPARE;
+ else if (dk->state & (1<<MD_DISK_JOURNAL))
+ *rp = MD_DISK_ROLE_JOURNAL;
else
*rp = MD_DISK_ROLE_FAULTY;
@@ -1569,6 +1582,11 @@ static int write_init_super1(struct supertype *st)
unsigned long long data_offset;
for (di = st->info; di; di = di->next) {
+ if (di->disk.state & (1 << MD_DISK_JOURNAL))
+ sb->feature_map |= MD_FEATURE_JOURNAL;
+ }
+
+ for (di = st->info; di; di = di->next) {
if (di->disk.state & (1 << MD_DISK_FAULTY))
continue;
if (di->fd < 0)
--
1.8.1
^ permalink raw reply related
* [PATCH 3/6] Enable create array with write journal (--write-journal DEVICE).
From: Song Liu @ 2015-08-28 23:27 UTC (permalink / raw)
To: linux-raid; +Cc: shli, dan.j.williams, neilb, hch, Song Liu
In-Reply-To: <1440804426-1461372-1-git-send-email-songliubraving@fb.com>
Specify the write journal device with --write-journal DEVICE
./mdadm --create -f /dev/md0 --assume-clean -c 32 --raid-devices=4 --level=5 /dev/sd[c-f] --write-journal /dev/sdb1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
Only one journal device is allowed. If multiple --write-journal
are given, mdadm will use the first and ignore others
./mdadm --create -f /dev/md0 --assume-clean -c 32 --raid-devices=4 --level=5 /dev/sd[c-f] --write-journal /dev/sdb1 --write-journal /dev/sdx
mdadm: Please specify only one journal device for the array.
mdadm: Ignoring --write-journal /dev/sdx...
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Song Liu <songliubraving@fb.com>
---
Create.c | 20 ++++++++++++++------
ReadMe.c | 1 +
md_p.h | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
mdadm.c | 24 ++++++++++++++++++++++++
mdadm.h | 2 ++
super1.c | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
6 files changed, 161 insertions(+), 7 deletions(-)
diff --git a/Create.c b/Create.c
index b62d8d4..6a2b307 100644
--- a/Create.c
+++ b/Create.c
@@ -87,7 +87,7 @@ int Create(struct supertype *st, char *mddev,
unsigned long long minsize=0, maxsize=0;
char *mindisc = NULL;
char *maxdisc = NULL;
- int dnum;
+ int dnum, raid_disk_num;
struct mddev_dev *dv;
int fail=0, warn=0;
struct stat stb;
@@ -180,11 +180,11 @@ int Create(struct supertype *st, char *mddev,
pr_err("This metadata type does not support spare disks at create time\n");
return 1;
}
- if (subdevs > s->raiddisks+s->sparedisks) {
+ if (subdevs > s->raiddisks+s->sparedisks+s->journaldisks) {
pr_err("You have listed more devices (%d) than are in the array(%d)!\n", subdevs, s->raiddisks+s->sparedisks);
return 1;
}
- if (!have_container && subdevs < s->raiddisks+s->sparedisks) {
+ if (!have_container && subdevs < s->raiddisks+s->sparedisks+s->journaldisks) {
pr_err("You haven't given enough devices (real or missing) to create this array\n");
return 1;
}
@@ -397,6 +397,9 @@ int Create(struct supertype *st, char *mddev,
}
}
+ if (dv->disposition == 'j')
+ continue; /* skip write journal for size check */
+
freesize /= 2; /* convert to K */
if (s->chunk && s->chunk != UnSet) {
/* round to chunk size */
@@ -837,7 +840,7 @@ int Create(struct supertype *st, char *mddev,
for (pass=1; pass <=2 ; pass++) {
struct mddev_dev *moved_disk = NULL; /* the disk that was moved out of the insert point */
- for (dnum=0, dv = devlist ; dv ;
+ for (dnum=0, raid_disk_num=0, dv = devlist ; dv ;
dv=(dv->next)?(dv->next):moved_disk, dnum++) {
int fd;
struct stat stb;
@@ -862,8 +865,13 @@ int Create(struct supertype *st, char *mddev,
*inf = info;
inf->disk.number = dnum;
- inf->disk.raid_disk = dnum;
- if (inf->disk.raid_disk < s->raiddisks)
+ inf->disk.raid_disk = raid_disk_num++;
+
+ if (dv->disposition == 'j') {
+ inf->disk.raid_disk = MD_DISK_ROLE_JOURNAL;
+ inf->disk.state = (1<<MD_DISK_JOURNAL);
+ raid_disk_num--;
+ } else if (inf->disk.raid_disk < s->raiddisks)
inf->disk.state = (1<<MD_DISK_ACTIVE) |
(1<<MD_DISK_SYNC);
else
diff --git a/ReadMe.c b/ReadMe.c
index c242319..10921e3 100644
--- a/ReadMe.c
+++ b/ReadMe.c
@@ -142,6 +142,7 @@ struct option long_options[] = {
{"data-offset",1, 0, DataOffset},
{"nodes",1, 0, Nodes}, /* also for --assemble */
{"home-cluster",1, 0, ClusterName},
+ {"write-journal",1, 0, WriteJournal},
/* For assemble */
{"uuid", 1, 0, 'u'},
diff --git a/md_p.h b/md_p.h
index fae73ba..0d691fb 100644
--- a/md_p.h
+++ b/md_p.h
@@ -208,4 +208,62 @@ static inline __u64 md_event(mdp_super_t *sb) {
return (ev<<32)| sb->events_lo;
}
+struct r5l_payload_header {
+ __u16 type;
+ __u16 flags;
+} __attribute__ ((__packed__));
+
+enum r5l_payload_type {
+ R5LOG_PAYLOAD_DATA = 0,
+ R5LOG_PAYLOAD_PARITY = 1,
+ R5LOG_PAYLOAD_FLUSH = 2,
+};
+
+struct r5l_payload_data_parity {
+ struct r5l_payload_header header;
+ __u32 size; /* sector. data/parity size. each 4k has a checksum */
+ __u64 location; /* sector. For data, it's raid sector. For
+ parity, it's stripe sector */
+ __u32 checksum[];
+} __attribute__ ((__packed__));
+
+enum r5l_payload_data_parity_flag {
+ R5LOG_PAYLOAD_FLAG_DISCARD = 1, /* payload is discard */
+ /*
+ * RESHAPED/RESHAPING is only set when there is reshape activity. Note,
+ * both data/parity of a stripe should have the same flag set
+ *
+ * RESHAPED: reshape is running, and this stripe finished reshape
+ * RESHAPING: reshape is running, and this stripe isn't reshaped
+ * */
+ R5LOG_PAYLOAD_FLAG_RESHAPED = 2,
+ R5LOG_PAYLOAD_FLAG_RESHAPING = 3,
+};
+
+struct r5l_payload_flush {
+ struct r5l_payload_header header;
+ __u32 size; /* flush_stripes size, bytes */
+ __u64 flush_stripes[];
+} __attribute__ ((__packed__));
+
+enum r5l_payload_flush_flag {
+ R5LOG_PAYLOAD_FLAG_FLUSH_STRIPE = 1, /* data represents whole stripe */
+};
+
+struct r5l_meta_block {
+ __u32 magic;
+ __u32 checksum;
+ __u8 version;
+ __u8 __zero_pading_1;
+ __u16 __zero_pading_2;
+ __u32 meta_size; /* whole size of the block */
+
+ __u64 seq;
+ __u64 position; /* sector, start from rdev->data_offset, current position */
+ struct r5l_payload_header payloads[];
+} __attribute__ ((__packed__));
+
+#define R5LOG_VERSION 0x1
+#define R5LOG_MAGIC 0x6433c509
+
#endif
diff --git a/mdadm.c b/mdadm.c
index 5d5a1b8..412c03c 100644
--- a/mdadm.c
+++ b/mdadm.c
@@ -74,6 +74,7 @@ int main(int argc, char *argv[])
.require_homehost = 1,
};
struct shape s = {
+ .journaldisks = 0,
.level = UnSet,
.layout = UnSet,
.bitmap_chunk = UnSet,
@@ -1170,6 +1171,24 @@ int main(int argc, char *argv[])
case O(INCREMENTAL, IncrementalPath):
remove_path = optarg;
continue;
+ case O(CREATE, WriteJournal):
+ if (s.journaldisks) {
+ pr_err("Please specify only one journal device for the array.\n");
+ pr_err("Ignoring --write-journal %s...\n", optarg);
+ continue;
+ }
+ dv = xmalloc(sizeof(*dv));
+ dv->devname = optarg;
+ dv->disposition = 'j'; /* WriteJournal */
+ dv->writemostly = writemostly;
+ dv->used = 0;
+ dv->next = NULL;
+ *devlistend = dv;
+ devlistend = &dv->next;
+ devs_found++;
+
+ s.journaldisks = 1;
+ continue;
}
/* We have now processed all the valid options. Anything else is
* an error
@@ -1197,6 +1216,11 @@ int main(int argc, char *argv[])
exit(0);
}
+ if (s.journaldisks && (s.level < 4 || s.level > 6)) {
+ pr_err("--write-journal is only supported for RAID level 4/5/6.\n");
+ exit(2);
+ }
+
if (!mode && devs_found) {
mode = MISC;
devmode = 'Q';
diff --git a/mdadm.h b/mdadm.h
index 6bdaa37..3cc1532 100644
--- a/mdadm.h
+++ b/mdadm.h
@@ -347,6 +347,7 @@ enum special_options {
Nodes,
ClusterName,
ClusterConfirm,
+ WriteJournal,
};
enum prefix_standard {
@@ -434,6 +435,7 @@ struct context {
struct shape {
int raiddisks;
int sparedisks;
+ int journaldisks;
int level;
int layout;
char *layout_str;
diff --git a/super1.c b/super1.c
index 4558783..799c86c 100644
--- a/super1.c
+++ b/super1.c
@@ -68,7 +68,10 @@ struct mdp_superblock_1 {
__u64 data_offset; /* sector start of data, often 0 */
__u64 data_size; /* sectors in this device that can be used for data */
__u64 super_offset; /* sector start of this superblock */
- __u64 recovery_offset;/* sectors before this offset (from data_offset) have been recovered */
+ union {
+ __u64 recovery_offset;/* sectors before this offset (from data_offset) have been recovered */
+ __u64 journal_tail;/* journal tail of journal device (from data_offset) */
+ };
__u32 dev_number; /* permanent identifier of this device - not role in raid */
__u32 cnt_corrected_read; /* number of read errors that were corrected by re-writing */
__u8 device_uuid[16]; /* user-space setable, ignored by kernel */
@@ -1568,6 +1571,57 @@ static unsigned long choose_bm_space(unsigned long devsize)
static void free_super1(struct supertype *st);
+#define META_BLOCK_SIZE 4096
+unsigned long crc32(
+ unsigned long crc,
+ const unsigned char *buf,
+ unsigned len);
+
+static int write_empty_r5l_meta_block(struct supertype *st, int fd)
+{
+ struct r5l_meta_block *mb;
+ struct mdp_superblock_1 *sb = st->sb;
+ struct align_fd afd;
+ __u32 crc;
+
+ init_afd(&afd, fd);
+
+ if (posix_memalign((void**)&mb, 4096, META_BLOCK_SIZE) != 0) {
+ pr_err("Could not allocate memory for the meta block.\n");
+ return 1;
+ }
+
+ memset(mb, 0, META_BLOCK_SIZE);
+
+ mb->magic = __cpu_to_le32(R5LOG_MAGIC);
+ mb->version = R5LOG_VERSION;
+ mb->meta_size = __cpu_to_le32(sizeof(struct r5l_meta_block));
+ mb->seq = __cpu_to_le64(random32());
+ mb->position = __cpu_to_le64(0);
+
+ crc = crc32(0xffffffff, sb->set_uuid, sizeof(sb->set_uuid));
+ crc = crc32(crc, (void *)mb, META_BLOCK_SIZE);
+ mb->checksum = __cpu_to_le32(crc);
+
+ if (lseek64(fd, (sb->data_offset) * 512, 0) < 0LL) {
+ pr_err("cannot seek to offset of the meta block\n");
+ goto fail_to_write;
+ }
+
+ if (awrite(&afd, mb, META_BLOCK_SIZE) != META_BLOCK_SIZE) {
+ pr_err("failed to store write the meta block \n");
+ goto fail_to_write;
+ }
+ fsync(fd);
+
+ free(mb);
+ return 0;
+
+fail_to_write:
+ free(mb);
+ return 1;
+}
+
#ifndef MDASSEMBLE
static int write_init_super1(struct supertype *st)
{
@@ -1724,6 +1778,13 @@ static int write_init_super1(struct supertype *st)
sb->sb_csum = calc_sb_1_csum(sb);
rv = store_super1(st, di->fd);
+
+ if (rv == 0 && (di->disk.state & (1 << MD_DISK_JOURNAL))) {
+ rv = write_empty_r5l_meta_block(st, di->fd);
+ if (rv)
+ goto error_out;
+ }
+
if (rv == 0 && (__le32_to_cpu(sb->feature_map) & 1))
rv = st->ss->write_bitmap(st, di->fd, NoUpdate);
close(di->fd);
--
1.8.1
^ permalink raw reply related
* [PATCH 4/6] Assemble array with write journal
From: Song Liu @ 2015-08-28 23:27 UTC (permalink / raw)
To: linux-raid; +Cc: shli, dan.j.williams, neilb, hch, Song Liu
In-Reply-To: <1440804426-1461372-1-git-send-email-songliubraving@fb.com>
Example output:
./mdadm --assemble /dev/md0 /dev/sd[c-f] /dev/sdb1
mdadm: /dev/md0 has been started with 4 drives and 1 journal.
mdadm checks superblock for journal devices. If the
array appears to have a journal device, but it is not given,
it will complain as
./mdadm --assemble /dev/md0 /dev/sd[c-f]
mdadm: Not safe to assemble with journal device missing, consider --force.
This can be overwritten with --force
./mdadm --assemble /dev/md0 /dev/sd[c-f] --force
mdadm: Force start with missing journal device...
mdadm: /dev/md0 has been started with 4 drives.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Song Liu <songliubraving@fb.com>
---
Assemble.c | 42 ++++++++++++++++++++++++++++++++++--------
mdadm.h | 3 +++
super1.c | 38 +++++++++++++++++++++++++++++++++-----
3 files changed, 70 insertions(+), 13 deletions(-)
diff --git a/Assemble.c b/Assemble.c
index d9e9001..556a43b 100644
--- a/Assemble.c
+++ b/Assemble.c
@@ -735,7 +735,7 @@ static int load_devices(struct devs *devices, char *devmap,
i = devcnt;
else
i = devices[devcnt].i.disk.raid_disk;
- if (i+1 == 0) {
+ if (i+1 == 0 || i == MD_DISK_ROLE_JOURNAL) {
if (nextspare < content->array.raid_disks*2)
nextspare = content->array.raid_disks*2;
i = nextspare++;
@@ -944,6 +944,7 @@ static int start_array(int mdfd,
unsigned int okcnt,
unsigned int sparecnt,
unsigned int rebuilding_cnt,
+ unsigned int journalcnt,
struct context *c,
int clean, char *avail,
int start_partial_ok,
@@ -955,6 +956,22 @@ static int start_array(int mdfd,
int i;
unsigned int req_cnt;
+ if (st->ss->require_journal) {
+ rv = st->ss->require_journal(st);
+ if (rv == 2) {
+ pr_err("BUG: Superblock not loaded in Assemble.c:start_array\n");
+ return 1;
+ }
+
+ if (journalcnt == 0 && rv == 1) {
+ if (!(c->force)) {
+ pr_err("Not safe to assemble with journal device missing, consider --force.\n");
+ return 1;
+ } else
+ pr_err("Force start with missing journal device...\n");
+ }
+ }
+
rv = set_array_info(mdfd, st, content);
if (rv && !err_ok) {
pr_err("failed to set array info for %s: %s\n",
@@ -1032,7 +1049,8 @@ static int start_array(int mdfd,
if (content->array.level == LEVEL_CONTAINER) {
if (c->verbose >= 0) {
pr_err("Container %s has been assembled with %d drive%s",
- mddev, okcnt+sparecnt, okcnt+sparecnt==1?"":"s");
+ mddev, okcnt+sparecnt+journalcnt,
+ okcnt+sparecnt+journalcnt==1?"":"s");
if (okcnt < (unsigned)content->array.raid_disks)
fprintf(stderr, " (out of %d)",
content->array.raid_disks);
@@ -1118,6 +1136,8 @@ static int start_array(int mdfd,
fprintf(stderr, "%s %d rebuilding", sparecnt?",":" and", rebuilding_cnt);
if (sparecnt)
fprintf(stderr, " and %d spare%s", sparecnt, sparecnt==1?"":"s");
+ if (journalcnt == 1)
+ fprintf(stderr, " and 1 journal");
fprintf(stderr, ".\n");
}
if (content->reshape_active &&
@@ -1289,7 +1309,7 @@ int Assemble(struct supertype *st, char *mddev,
int *best = NULL; /* indexed by raid_disk */
int bestcnt = 0;
int devcnt;
- unsigned int okcnt, sparecnt, rebuilding_cnt, replcnt;
+ unsigned int okcnt, sparecnt, rebuilding_cnt, replcnt, journalcnt;
int i;
int was_forced = 0;
int most_recent = 0;
@@ -1530,6 +1550,7 @@ try_again:
okcnt = 0;
replcnt = 0;
sparecnt=0;
+ journalcnt=0;
rebuilding_cnt=0;
for (i=0; i< bestcnt; i++) {
int j = best[i];
@@ -1540,8 +1561,10 @@ try_again:
/* note: we ignore error flags in multipath arrays
* as they don't make sense
*/
- if (content->array.level != LEVEL_MULTIPATH)
- if (!(devices[j].i.disk.state & (1<<MD_DISK_ACTIVE))) {
+ if (content->array.level != LEVEL_MULTIPATH) {
+ if (devices[j].i.disk.state & (1<<MD_DISK_JOURNAL)) {
+ journalcnt++;
+ } else if (!(devices[j].i.disk.state & (1<<MD_DISK_ACTIVE))) {
if (!(devices[j].i.disk.state
& (1<<MD_DISK_FAULTY))) {
devices[j].uptodate = 1;
@@ -1549,6 +1572,7 @@ try_again:
}
continue;
}
+ }
/* If this device thinks that 'most_recent' has failed, then
* we must reject this device.
*/
@@ -1583,7 +1607,7 @@ try_again:
replcnt++;
} else
rebuilding_cnt++;
- } else
+ } else if (devices[j].i.disk.raid_disk != MD_DISK_ROLE_JOURNAL)
sparecnt++;
}
}
@@ -1647,7 +1671,9 @@ try_again:
int j = best[i];
unsigned int desired_state;
- if (i >= content->array.raid_disks * 2)
+ if (devices[j].i.disk.raid_disk == MD_DISK_ROLE_JOURNAL)
+ desired_state = (1<<MD_DISK_JOURNAL);
+ else if (i >= content->array.raid_disks * 2)
desired_state = 0;
else if (i & 1)
desired_state = (1<<MD_DISK_ACTIVE) | (1<<MD_DISK_REPLACEMENT);
@@ -1794,7 +1820,7 @@ try_again:
rv = start_array(mdfd, mddev, content,
st, ident, best, bestcnt,
chosen_drive, devices, okcnt, sparecnt,
- rebuilding_cnt,
+ rebuilding_cnt, journalcnt,
c,
clean, avail, start_partial_ok,
pre_exist != NULL,
diff --git a/mdadm.h b/mdadm.h
index 3cc1532..bc6680f 100644
--- a/mdadm.h
+++ b/mdadm.h
@@ -969,6 +969,9 @@ extern struct superswitch {
/* validate container after assemble */
int (*validate_container)(struct mdinfo *info);
+ /* whether the array require a journal device */
+ int (*require_journal)(struct supertype *st);
+
int swapuuid; /* true if uuid is bigending rather than hostendian */
int external;
const char *name; /* canonical metadata name */
diff --git a/super1.c b/super1.c
index 799c86c..810a323 100644
--- a/super1.c
+++ b/super1.c
@@ -138,6 +138,37 @@ struct misc_dev_info {
|MD_FEATURE_NEW_OFFSET \
|MD_FEATURE_JOURNAL \
)
+/* return value:
+ * 0, jouranl not required
+ * 1, journal required
+ * 2, no superblock loated (st->sb == NULL)
+ */
+static int require_journal1(struct supertype *st)
+{
+ struct mdp_superblock_1 *sb = st->sb;
+ int i;
+ if (sb)
+ for (i=0; i<MAX_DEVS; i++) {
+ if (MD_DISK_ROLE_JOURNAL == sb->dev_roles[i])
+ return 1;
+ }
+ else
+ return 2; /* no sb loaded */
+ return 0;
+}
+
+static int role_from_sb(struct mdp_superblock_1 *sb)
+{
+ unsigned int d;
+ int role;
+
+ d = __le32_to_cpu(sb->dev_number);
+ if (d < __le32_to_cpu(sb->max_dev))
+ role = __le16_to_cpu(sb->dev_roles[d]);
+ else
+ role = MD_DISK_ROLE_SPARE;
+ return role;
+}
/* return how many bytes are needed for bitmap, for cluster-md each node
* should have it's own bitmap */
@@ -480,11 +511,7 @@ static void examine_super1(struct supertype *st, char *homehost)
printf(")\n");
#endif
printf(" Device Role : ");
- d = __le32_to_cpu(sb->dev_number);
- if (d < __le32_to_cpu(sb->max_dev))
- role = __le16_to_cpu(sb->dev_roles[d]);
- else
- role = MD_DISK_ROLE_SPARE;
+ role = role_from_sb(sb);
if (role >= MD_DISK_ROLE_FAULTY)
printf("spare\n");
else if (role == MD_DISK_ROLE_JOURNAL)
@@ -2556,6 +2583,7 @@ struct superswitch super1 = {
.locate_bitmap = locate_bitmap1,
.write_bitmap = write_bitmap1,
.free_super = free_super1,
+ .require_journal = require_journal1,
#if __BYTE_ORDER == BIG_ENDIAN
.swapuuid = 0,
#else
--
1.8.1
^ permalink raw reply related
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