* LAON AANBIEDING OP 1,5% rente
From: DIAMOND SWISS LOAN COMPANY @ 2015-03-05 19:38 UTC (permalink / raw)
groeten
We zijn Diamond Zwitserse lening bedrijf het geven van leningen per post advertentie, Ter ondersteuning van banken zeer ernstig en georganiseerd. Als je benteen industriële, aannemer, met pensioen persoon of alle anderen willen krediet aan zijn of haar bedrijf te herstarten of het opzetten van een bedrijf
etc.
we geven leningen. Op 1,5% rente?
Neem vandaag nog contact met de volgende informatie hieronder.
naam:
adres:
leeftijd:
Geslacht:
Contact-Phone:
beroep:
Maandelijks inkomen:
Het benodigde bedrag van de lening:
Duur van de lening:
Het doel van de lening:
land:
Postcode:
Alle informatie moet worden gericht aan ons op: diamondswissloanscompanys@gmail.com
"Wij tonen u een betere manier om uw financiële vrijheid"
Met vriendelijke groet,
De heer Diamond Peters (Managing Director).
De heer Bill Anthony (Marketing Manager).
=============================================================================================================================
Greetings
We are DIAMOND SWISS LOAN COMPANY giving out loans by mail advert, In support of banks very serious and organized. If you are
an industrial, contractor, retire person or all others wanting credit to restart his or her business or to set up a company
etc.
we give out loans. At 1.5% interest rate?
Contact us today with the following information below.
Name:
Address:
Age:
Gender:
Contact-Phone:
Occupation:
Monthly income:
The required amount of loan:
Duration of loan:
The purpose of the loan:
Country:
ZIP code:
All information should be sent to us at: diamondswissloanscompanys@gmail.com
"We show you a better way to your financial freedom"
With kind regards,
Mr. Diamond Peters (Managing Director).
Mr. Bill Anthony (Marketing Manager).
--
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
* smartctl-timeouts_v1.01 scripts (scterc timeout fixes)
From: Chris @ 2015-03-05 18:21 UTC (permalink / raw)
To: smartmontools-support, linux-raid
In-Reply-To: <20150227144951.648ba949@smtp.arcor.de>
[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]
Hello list,
could readers please respond with a short yes/no, if they would like
smartctl scripts that fix mismatching scterc/controller timeouts to
prevent data loss?
(Testing them only requires to unzip the file into /etc/udev/rules.d/)
And dear maintainers, would you consider shipping the
scripts?
(Fixing the timeouts seems important for all systems without a
default smartctl -l scterc timeout. And all redundancy controlling
packages (mdadm, lvm, btrfs, ...) may want to suggest or depend on the
smartctl package and set shorter timeouts, i.e. they call the
appropriate scripts depending on redundancy states. Thus smartctl seems
the right package to ship the scripts and default udev rule, and other
packages ship their device specific udev rules.)
Cheers,
Chris
PS: v1.01 has smartctl-default_test.rules for udev and is working well
here with drives that have scterc timeout default to "Disabled".
Am Fri, 27 Feb 2015 14:49:51 +0100
schrieb Chris <email.bug@arcor.de>:
>
> Hi there,
>
> here are some "smartctl-timeouts" scripts that fix commonly
> mismatching defaults with drives that have no error recovery timeout
> configured, which has often lead to data loss. (See the README for
> further information.)
>
> The scripts are the result of discussions on the linux-raid
> mailinglist, but it may be best to ship the scripts with smartctl
> already (possibly together with a default "non-redundant-disk" udev
> rule to ensure proper default timeouts), and let redundancy
> controlling packages like mdadm, lvm, btrfs etc. ship their own udev
> rules to call the scripts appropriately.
>
> Please respond whether you'd like to ship the scripts together with
> smartctl.
>
> Cheers,
> Chris
[-- Attachment #2: smartctl-timeouts_v1.01.zip --]
[-- Type: application/zip, Size: 11266 bytes --]
^ permalink raw reply
* Raid 10 Issue
From: Stefan Lamby @ 2015-03-05 17:56 UTC (permalink / raw)
To: linux-raid@vger.kernel.org
Hello List.
I was setting up a new machine using ubuntu 14.04.02 lts using its installer,
configuring a raid 10 with 2 disks and lvm on top of it. I was using 2 disks and
now I like to add 2 more disks to the array so i want to end up with 4 disks, no
spare.
Searching the internet I found that I am not able to --grow the array with the
mdadm version this ubuntu is using (v3.2.5).
Is that right?
So I decided to build a new array that way and try to move my data afterwards,
which failed:
(Is it OK to do it that way or do you recommend another?)
root@kvm15:~# mdadm --verbose --create --level=10 --raid-devices=4 /dev/md10
missing missing /dev/sdc1 /dev/sdd1
mdadm: layout defaults to n2
mdadm: layout defaults to n2
mdadm: chunk size defaults to 512K
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid10 devices=4 ctime=Fri Feb 27 15:49:14 2015
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid10 devices=4 ctime=Fri Feb 27 15:49:14 2015
mdadm: size set to 1904165376K
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: RUN_ARRAY failed: Input/output error
<<<<<<<<<<<<<<<<<<<<<<<<<<<
root@kvm15:~#
root@kvm15:~#
root@kvm15:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid10] [raid6] [raid5]
[raid4]
md0 : active raid10 sdb1[1] sda1[0]
1904165376 blocks super 1.2 2 near-copies [2/2] [UU]
unused devices: <none>
md0 btw. is the current (running) array.
I did a few tries to get this running. This is must be the reason why mdadm
detects already existing raid config.
The partitions for sdc and sdd are created using fdisk, they do have the same
layout like disk sdb, which looks like this:
(parted) print
Modell: ATA WDC WD20PURX-64P (scsi)
Festplatte /dev/sdc: 2000GB
Sektorgröße (logisch/physisch): 512B/4096B
Partitionstabelle: msdos
Nummer Anfang Ende Größe Typ Dateisystem Flags
1 50.4GB 2000GB 1950GB primary RAID
Any help is very welcome.
Thanks.
Stefan
--
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: Last working drive in RAID1
From: Wols Lists @ 2015-03-05 15:55 UTC (permalink / raw)
To: NeilBrown, Eric Mei; +Cc: linux-raid
In-Reply-To: <20150305102622.016ec792@notabene.brown>
On 04/03/15 23:26, NeilBrown wrote:
> On Wed, 04 Mar 2015 15:48:57 -0700 Eric Mei <meijia@gmail.com>
> wrote:
>
>> Hi Neil,
>>
>> I see, that does make sense. Thank you.
>>
>> But it impose a problem for HA. We have 2 nodes as active-standby
>> pair, if HW on node 1 have problem (e.g. SAS cable get pulled,
>> thus all access to physical drives are gone), we hope the array
>> failover to node 2. But with lingering drive reference, mdadm
>> will report array is still alive thus failover won't happen.
>>
>> I guess it depends on what kind of error on the drive. If it's
>> just a media error we should keep it online as much as possible.
>> But if the drive is really bad or physically gone, keeping the
>> stale reference won't help anything. Back to your comparison with
>> single drive /dev/sda, I think MD as an array should do the same
>> as /dev/sda, not the individual drive inside MD, for them we
>> should just let it go. How do you think?
>
> If there were some what that md could be told that the device
> really was gone and just just returning errors, then I would be OK
> with it being marked as faulty and being removed from the array.
>
> I don't think there is any mechanism in the kernel to allow that.
> It would be easiest to capture a "REMOVE" event via udev, and have
> udev run "mdadm" to tell the md array that the device was gone.
>
> Currently there is no way to do that ... I guess we could change
> raid1 so that a 'fail' event that came from user-space would
> always cause the device to be marked failed, even when an IO error
> would not... To preserve current behaviour, it should require
> something like "faulty-force" to be written to the "state" file.
> We would need to check that raid1 copes with having zero working
> drives - currently it might always assume there is at least one
> device.
>
Sorry to butt in, but I'm finding this conversation a bit surreal ...
take everything I say with a pinch of salt. But the really weird bit
was "what does linux do if /dev/sda disappears?"
In the old days, with /dev/hd*, the * had a hard mapping to the
hardware. hda was the ide0 primary, hdd was the ide1 secondary, etc
etc. I think I ran several systems with just hdb and hdd. Not a good
idea, but.
Nowadays, with sd*, the letter is assigned in order of finding the
drive. So if sda is removed, linux moves all the other drives and what
was sdb becomes sda. Which is why you're advised now to always refer
to drives by their BLKDEV or whatever, as linux provides no guarantees
whatsoever about sd*. The blockdev may only be a symlink to whatever
the sd*n code of the disk is, but it makes sure you get the disk you
want when the sd*n changes under you.
Equally surreal is the comment about "what does raid1 do with no
working devices?". Surely it will do nothing, if there's no spinning
rust or whatever underneath it? You can't corrupt it if there's
nothing there to corrupt?
Sorry again if this is inappropriate, but you're coming over as so
buried in the trees that you can't see the wood.
Cheers,
Wol
^ permalink raw reply
* Re: [PATCH 0/1] RFC: Use /dev/md/X as default name
From: Jes Sorensen @ 2015-03-05 14:56 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <wrfjoao84uy4.fsf@ultrasam.lan.trained-monkey.org>
Jes Sorensen <Jes.Sorensen@redhat.com> writes:
> NeilBrown <neilb@suse.de> writes:
>> On Mon, 02 Mar 2015 11:32:16 -0500 Jes Sorensen <Jes.Sorensen@redhat.com>
>>> Neil,
>>>
>>> Finally had time to go back and look at this - I don't quite understand
>>> your request here.
>>>
>>> As far as I can see, the above code isn't run at all during device
>>> creation, so I don't get how modifying it as you suggest will make
>>> /dev/md/111 appear if I create /dev/md111?
>>>
>>> Cheers,
>>> Jes
>>
>> Wheels within wheels of deception and indirection....
>>
>> mdadm doesn't create the devices directly, udev does that.
>>
>> IMPORT{program}="BINDIR/mdadm --detail --export $devnode"
>> ENV{DEVTYPE}=="disk", ENV{MD_DEVNAME}=="?*", SYMLINK+="md/$env{MD_DEVNAME}"
>>
>>
>> So the symlink from /dev/md gets created iff "mdadm --detail --export"
>> reports an MD_DEVNAME.
>>
>> Hence the change suggested.
>>
>> mdadm *can* create the devices itself, but only if udev isn't running, or
>> mdamd has been explicitly told to ignore udev. Normally that doesn't happen.
>
> Ahhh, I didn't see anything happening on my system, but it may be the
> RHEL/Fedora udev rules file is missing something. I'll have to take a
> closer look there!
Actually I remember why I didn't get that far - I added some debug code
to the place you suggested I modify, and it never triggered during
Create.
Cheers,
Jes
^ permalink raw reply
* Re: Help with raid 10 issue
From: Phil Turmel @ 2015-03-05 13:12 UTC (permalink / raw)
To: Stefan Lamby, linux-raid@vger.kernel.org
In-Reply-To: <493130695.186182.1425543528690.JavaMail.open-xchange@app10.ox.hosteurope.de>
On 03/05/2015 03:18 AM, Stefan Lamby wrote:
>
> Hi.
> Is it OK to ask for support here to this list or is it the wrong place?
> If so, could you please give a hint where to go?
This is the right place. Post your array details (mdadm -D), member
details (mdadm -E) and a summary of what happened. Include excerpts
from your dmesg and/or syslogs that look like they might be relevant.
These should all be text files, so pasting them directly into your email
would be preferred.
Regards,
Phil Turmel
^ permalink raw reply
* Help with raid 10 issue
From: Stefan Lamby @ 2015-03-05 8:18 UTC (permalink / raw)
To: linux-raid@vger.kernel.org
Hi.
Is it OK to ask for support here to this list or is it the wrong place?
If so, could you please give a hint where to go?
Thanks.
Stefan
^ permalink raw reply
* Re: Last working drive in RAID1
From: NeilBrown @ 2015-03-04 23:26 UTC (permalink / raw)
To: Eric Mei; +Cc: linux-raid
In-Reply-To: <54F78BD9.403@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1812 bytes --]
On Wed, 04 Mar 2015 15:48:57 -0700 Eric Mei <meijia@gmail.com> wrote:
> Hi Neil,
>
> I see, that does make sense. Thank you.
>
> But it impose a problem for HA. We have 2 nodes as active-standby pair,
> if HW on node 1 have problem (e.g. SAS cable get pulled, thus all access
> to physical drives are gone), we hope the array failover to node 2. But
> with lingering drive reference, mdadm will report array is still alive
> thus failover won't happen.
>
> I guess it depends on what kind of error on the drive. If it's just a
> media error we should keep it online as much as possible. But if the
> drive is really bad or physically gone, keeping the stale reference
> won't help anything. Back to your comparison with single drive /dev/sda,
> I think MD as an array should do the same as /dev/sda, not the
> individual drive inside MD, for them we should just let it go. How do
> you think?
If there were some what that md could be told that the device really was gone
and just just returning errors, then I would be OK with it being marked as
faulty and being removed from the array.
I don't think there is any mechanism in the kernel to allow that. It would
be easiest to capture a "REMOVE" event via udev, and have udev run "mdadm" to
tell the md array that the device was gone.
Currently there is no way to do that ... I guess we could change raid1 so
that a 'fail' event that came from user-space would always cause the device
to be marked failed, even when an IO error would not...
To preserve current behaviour, it should require something like "faulty-force"
to be written to the "state" file. We would need to check that raid1 copes
with having zero working drives - currently it might always assume there is
at least one device.
NeilBrown
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: Last working drive in RAID1
From: Eric Mei @ 2015-03-04 22:48 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <20150305084634.2d590fe4@notabene.brown>
Hi Neil,
I see, that does make sense. Thank you.
But it impose a problem for HA. We have 2 nodes as active-standby pair,
if HW on node 1 have problem (e.g. SAS cable get pulled, thus all access
to physical drives are gone), we hope the array failover to node 2. But
with lingering drive reference, mdadm will report array is still alive
thus failover won't happen.
I guess it depends on what kind of error on the drive. If it's just a
media error we should keep it online as much as possible. But if the
drive is really bad or physically gone, keeping the stale reference
won't help anything. Back to your comparison with single drive /dev/sda,
I think MD as an array should do the same as /dev/sda, not the
individual drive inside MD, for them we should just let it go. How do
you think?
Eric
On 2015-03-04 2:46 PM, NeilBrown wrote:
> On Wed, 04 Mar 2015 12:55:43 -0700 Eric Mei <meijia@gmail.com> wrote:
>
>> Hi,
>>
>> It is interesting to notice that RAID1 won't mark the last working drive
>> as Faulty no matter what. The responsible code seems here:
>>
>> static void error(struct mddev *mddev, struct md_rdev *rdev)
>> {
>> ...
>> /*
>> * If it is not operational, then we have already marked it as dead
>> * else if it is the last working disks, ignore the error, let the
>> * next level up know.
>> * else mark the drive as failed
>> */
>> if (test_bit(In_sync, &rdev->flags)
>> && (conf->raid_disks - mddev->degraded) == 1) {
>> /*
>> * Don't fail the drive, act as though we were just a
>> * normal single drive.
>> * However don't try a recovery from this drive as
>> * it is very likely to fail.
>> */
>> conf->recovery_disabled = mddev->recovery_disabled;
>> return;
>> }
>> ...
>> }
>>
>> The end result is that even if all the drives are physically gone, there
>> still one drive remains in array forever, and mdadm continues to report
>> the array is degraded instead of failed. RAID10 also has similar behavior.
>>
>> Is there any reason we absolutely don't want to fail the last drive of
>> RAID1?
>>
> When a RAID1 only has one drive remaining, then it should act as much as
> possible like a single plain ordinary drive.
>
> How does /dev/sda behave when you physically remove the device? md0 (as a
> raid1 with one drive) should do the same.
>
> NeilBrown
^ permalink raw reply
* Re: Hung RAID5 array with discard
From: Terry Hardie @ 2015-03-04 21:47 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <CANHB05vDxWqfST41hXgfApthHuxdSuyJYCKqS4jkOa7OZ0kpsA@mail.gmail.com>
Well, I'm dissapointed no one responded to this. This basically means
linux RAID 4/5/6 and discard is fundamentally broken, and no one wants
to acknowledge it.
I hope someone finds this post while I still have my lab available and
I can help them troubleshoot this issue.
I tried this again today on 3.13.0-44-generic (Ubuntu) and was easily
able to reproduce it.
On Wed, Dec 17, 2014 at 7:08 PM, Terry Hardie <thardie@instartlogic.com> wrote:
> Hi,
>
> I am testing 3 SSDs (1TB Crucial M550 with DRZAT, and I tested they do
> return zeros after discard) with RAID5 and discard. I create the array
> with a 64k chunk size, and it starts to sync. During it's initial
> reconstruction, I do a mkfs.ext4, which starts to do the "Discarding
> device blocks". After a short period (I believe when the mkfs reaches
> the point where the reconstruction is at, all IO to the disks freezes,
> and mkfs does not advance. iostat shows 2 of the 3 drives at 100%
> utilization with no data read or written. After 2 minutes, I get the
> hung task dump. Most CPUs are idle, and here are a few which are not,
> which look like a deadlock to me:
>
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154399] INFO:
> rcu_sched detected stalls on CPUs/tasks: { 4 5} (detected by 3,
> t=285032 jiffies, g=1160, c=1159, q=0)
>
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154902] NMI
> backtrace for cpu 4
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154904] CPU: 4 PID:
> 2146 Comm: md3_raid5 Tainted: G W IOX 3.13.0-43-generic
> #72~precise1
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154905] Hardware
> name: Supermicro SYS-2028TP-HC1R/X10DRT-P, BIOS 1.0a 08/28/2014
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154906] task:
> ffff88202594c800 ti: ffff8810245a0000 task.ti: ffff8810245a0000
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154907] RIP:
> 0010:[<ffffffff817644c1>] [<ffffffff817644c1>]
> _raw_spin_lock_irqsave+0x41/0x60
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154910] RSP:
> 0018:ffff8810245a1cc8 EFLAGS: 00000006
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154911] RAX:
> 0000000000002ec5 RBX: ffff882028a6ec00 RCX: 0000000000007b78
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154912] RDX:
> 0000000000000202 RSI: 0000000000007b78 RDI: ffff882028a6ec10
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154913] RBP:
> ffff8810245a1cc8 R08: 0000000000007b76 R09: ffff882023629170
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154914] R10:
> 0000000000000000 R11: ffff882028a6ec00 R12: ffff882028a6ee68
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154915] R13:
> 0000000000000003 R14: 0000000000000002 R15: ffff882028a6ec10
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154916] FS:
> 0000000000000000(0000) GS:ffff88103fc80000(0000)
> knlGS:0000000000000000
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154917] CS: 0010
> DS: 0000 ES: 0000 CR0: 0000000080050033
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154918] CR2:
> 00007f208c2d0000 CR3: 0000000001c0d000 CR4: 00000000001407e0
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154919] Stack:
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154920]
> ffff8810245a1d18 ffffffffa0149890 0000000000000002 ffff882028a6ee88
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154923]
> ffff882028a6ee68 ffff882028a6ec00 0000000000000008 ffff882028a6ee68
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154926]
> 0000000000000000 ffff882028a6ee50 ffff8810245a1d98 ffffffffa015212f
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154929] Call Trace:
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154933]
> [<ffffffffa0149890>] release_inactive_stripe_list+0x50/0x160 [raid456]
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154937]
> [<ffffffffa015212f>] handle_active_stripes.isra.38+0x7f/0x190
> [raid456]
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154940]
> [<ffffffffa0152758>] raid5d+0x198/0x2f0 [raid456]
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154942]
> [<ffffffff815d30a7>] md_thread+0x117/0x150
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154945]
> [<ffffffff810affe0>] ? __wake_up_sync+0x20/0x20
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154947]
> [<ffffffff815d2f90>] ? md_rdev_init+0x110/0x110
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154949]
> [<ffffffff8108fb59>] kthread+0xc9/0xe0
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154952]
> [<ffffffff8108fa90>] ? flush_kthread_worker+0xb0/0xb0
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154954]
> [<ffffffff8176d5bc>] ret_from_fork+0x7c/0xb0
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154956]
> [<ffffffff8108fa90>] ? flush_kthread_worker+0xb0/0xb0
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.154957] Code: 1f 44
> 00 00 b8 00 00 02 00 f0 0f c1 07 89 c1 c1 e9 10 66 39 c1 75 05 48 89
> d0 5d c3 83 e1 fe 0f b7 f1 b8 00 80 00 00 44 0f b7 07 <66> 44 39 c1 74
> e6 f3 90 83 e8 01 75 ef 0f 1f 80 00 00 00 00 eb
>
>
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155001] NMI
> backtrace for cpu 5
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155003] CPU: 5 PID:
> 2147 Comm: md3_resync Tainted: G W IOX 3.13.0-43-generic
> #72~precise1
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155004] Hardware
> name: Supermicro SYS-2028TP-HC1R/X10DRT-P, BIOS 1.0a 08/28/2014
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155005] task:
> ffff88202594b000 ti: ffff8810274a0000 task.ti: ffff8810274a0000
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155006] RIP:
> 0010:[<ffffffffa01483b7>] [<ffffffffa01483b7>]
> __find_stripe+0x57/0xa0 [raid456]
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155010] RSP:
> 0018:ffff8810274a1b68 EFLAGS: 00000006
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155011] RAX:
> ffff882027092da0 RBX: 0000000000a30c10 RCX: 0000000000000001
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155012] RDX:
> 0000000000000c10 RSI: 0000000000a30c10 RDI: ffff882028a6ec00
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155013] RBP:
> ffff8810274a1b88 R08: 0000000000000000 R09: 0000000000000000
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155014] R10:
> 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155015] R13:
> ffff882028a6ec00 R14: 0000000000000000 R15: ffff882028a6eda8
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155016] FS:
> 0000000000000000(0000) GS:ffff88103fca0000(0000)
> knlGS:0000000000000000
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155017] CS: 0010
> DS: 0000 ES: 0000 CR0: 0000000080050033
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155018] CR2:
> 00000000006e1dc8 CR3: 0000000001c0d000 CR4: 00000000001407e0
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155019] Stack:
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155020]
> ffff8810274a1ba8 ffff882028a6ec00 000000007b767b00 ffff882028a6ec10
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155023]
> ffff8810274a1c28 ffffffffa0150555 ffff882023773b50 ffff882028a6eda8
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155026]
> 0000000200000001 ffff882028a6ec08 0000000000000000 0000000000a30c10
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155029] Call Trace:
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155033]
> [<ffffffffa0150555>] get_active_stripe+0x115/0x3e0 [raid456]
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155036]
> [<ffffffffa014aea8>] ? release_stripe+0x68/0x100 [raid456]
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155040]
> [<ffffffffa0154f3b>] sync_request+0x11b/0x2a0 [raid456]
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155042]
> [<ffffffff815d5ccf>] md_do_sync+0x84f/0xdb0
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155046]
> [<ffffffff810affe0>] ? __wake_up_sync+0x20/0x20
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155048]
> [<ffffffff815d30a7>] md_thread+0x117/0x150
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155050]
> [<ffffffff815d2f90>] ? md_rdev_init+0x110/0x110
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155052]
> [<ffffffff8108fb59>] kthread+0xc9/0xe0
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155054]
> [<ffffffff8108fa90>] ? flush_kthread_worker+0xb0/0xb0
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155057]
> [<ffffffff8176d5bc>] ret_from_fork+0x7c/0xb0
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155059]
> [<ffffffff8108fa90>] ? flush_kthread_worker+0xb0/0xb0
> Dec 18 00:57:41 unassigned-hostname kernel: [ 1606.155060] Code: e2 f8
> 0f 00 00 48 8b 04 02 48 85 c0 75 25 f6 05 29 25 01 00 04 75 3e 31 c0
> 48 83 c4 08 5b 41 5c 41 5d 5d c3 66 44 39 60 30 74 ee <48> 8b 00 48 85
> c0 74 db 48 39 58 38 75 f2 eb e9 48 89 f2 48 c7
>
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670082] INFO: task
> mkfs.ext4:2235 blocked for more than 120 seconds.
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670109]
> Tainted: G W IOX 3.13.0-43-generic #72~precise1
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670130] "echo 0 >
> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670155] mkfs.ext4
> D ffff881024fe39e0 0 2235 2080 0x00000000
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670158]
> ffff882026eafa68 0000000000000082 ffff88103fc73480 ffff882026eaffd8
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670162]
> 0000000000013480 0000000000013480 ffff8820293e8000 ffff88202208b000
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670165]
> ffff882026eafa78 ffff882028a6ec00 ffff882028a6ed98 ffff882028a6ec0c
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670169] Call Trace:
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670175]
> [<ffffffff81760ae9>] schedule+0x29/0x70
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670181]
> [<ffffffffa01506e3>] get_active_stripe+0x2a3/0x3e0 [raid456]
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670185]
> [<ffffffff8134c152>] ? blk_check_plugged+0x72/0xb0
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670189]
> [<ffffffff810affe0>] ? __wake_up_sync+0x20/0x20
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670193]
> [<ffffffffa0155e44>] make_discard_request+0x108/0x12c4 [raid456]
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670196]
> [<ffffffff810affe0>] ? __wake_up_sync+0x20/0x20
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670201]
> [<ffffffffa0155c91>] make_request+0x581/0x590 [raid456]
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670204]
> [<ffffffff8109cfd6>] ? ttwu_do_activate.constprop.82+0x66/0x70
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670207]
> [<ffffffff8109d097>] ? ttwu_queue+0xb7/0xd0
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670210]
> [<ffffffff8109f950>] ? try_to_wake_up+0x190/0x210
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670212]
> [<ffffffff815d2c53>] md_make_request+0xd3/0x230
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670216]
> [<ffffffff8115b085>] ? mempool_alloc_slab+0x15/0x20
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670219]
> [<ffffffff8134ceb7>] generic_make_request.part.62+0x77/0xb0
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670222]
> [<ffffffff8134d428>] generic_make_request+0x68/0x70
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670225]
> [<ffffffff8134d4a8>] submit_bio+0x78/0x160
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670228]
> [<ffffffff81202f80>] ? bio_alloc_bioset+0xa0/0x1d0
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670232]
> [<ffffffff813578c0>] blkdev_issue_discard+0x1f0/0x2a0
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670235]
> [<ffffffff8135c1f4>] blkdev_ioctl+0x354/0x810
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670238]
> [<ffffffff8101361d>] ? __switch_to+0x16d/0x4d0
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670241]
> [<ffffffff81204370>] block_ioctl+0x40/0x50
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670244]
> [<ffffffff811dd5c5>] do_vfs_ioctl+0x75/0x2c0
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670247]
> [<ffffffff817606be>] ? __schedule+0x38e/0x700
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670249]
> [<ffffffff811dd8a1>] SyS_ioctl+0x91/0xb0
> Dec 18 00:58:57 unassigned-hostname kernel: [ 1682.670252]
> [<ffffffff8176d66d>] system_call_fastpath+0x1a/0x1f
>
>
>
>
> If I do the mkfs.ext4 after the initial reconstruction is done, is
> gets all the way through. I don't want to put this system into
> production, since this could mean this condition could show up in the
> future if the array needs to reconstruct again at a future point while
> in service.
>
> This is a test system in a lab, so I'd be happy to try some tests.
>
> Terry
^ permalink raw reply
* Re: Last working drive in RAID1
From: NeilBrown @ 2015-03-04 21:46 UTC (permalink / raw)
To: Eric Mei; +Cc: linux-raid
In-Reply-To: <54F7633F.3020503@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1699 bytes --]
On Wed, 04 Mar 2015 12:55:43 -0700 Eric Mei <meijia@gmail.com> wrote:
> Hi,
>
> It is interesting to notice that RAID1 won't mark the last working drive
> as Faulty no matter what. The responsible code seems here:
>
> static void error(struct mddev *mddev, struct md_rdev *rdev)
> {
> ...
> /*
> * If it is not operational, then we have already marked it as dead
> * else if it is the last working disks, ignore the error, let the
> * next level up know.
> * else mark the drive as failed
> */
> if (test_bit(In_sync, &rdev->flags)
> && (conf->raid_disks - mddev->degraded) == 1) {
> /*
> * Don't fail the drive, act as though we were just a
> * normal single drive.
> * However don't try a recovery from this drive as
> * it is very likely to fail.
> */
> conf->recovery_disabled = mddev->recovery_disabled;
> return;
> }
> ...
> }
>
> The end result is that even if all the drives are physically gone, there
> still one drive remains in array forever, and mdadm continues to report
> the array is degraded instead of failed. RAID10 also has similar behavior.
>
> Is there any reason we absolutely don't want to fail the last drive of
> RAID1?
>
When a RAID1 only has one drive remaining, then it should act as much as
possible like a single plain ordinary drive.
How does /dev/sda behave when you physically remove the device? md0 (as a
raid1 with one drive) should do the same.
NeilBrown
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: RAID0 & diskstats.
From: NeilBrown @ 2015-03-04 21:31 UTC (permalink / raw)
To: Dave Jones; +Cc: Linux Kernel, linux RAID
In-Reply-To: <20150304210904.GA26981@codemonkey.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1886 bytes --]
On Wed, 4 Mar 2015 16:09:04 -0500 Dave Jones <davej@codemonkey.org.uk> wrote:
> Hi Neil,
> According to Documentation/iostats.txt, the 9th column of
> /proc/diskstats (and its modern replacement in sysfs) should go to 0
> as IO completes.
>
> I assembled a RAID0 stripe using two SSD's, and saw this..
>
> # mdadm --assemble /dev/md0
> mdadm: /dev/md0 has been started with 2 drives.
> # cat /sys/block/md0/stat
> 167 0 5656 0 5 0 4096 0 172 3408 582825
> # cat /sys/block/md0/stat
> 167 0 5656 0 5 0 4096 0 172 231469 39809317
>
> The 10th & 11th fields constantly increase, as field 9 remains non-zero.
> If I mount and umount a filesystem on that volume, it works as expected,
> but the 9th 'IOs inflight' field continues to rise and never decreases even
> though the IO has obviously completed.
>
> # umount /mnt/ssd
> # cat /sys/block/md0/stat
> 167 0 5656 0 9 0 4225 0 176 571384 98278615
>
> The underlying disks have their respective stats entries behaving as
> expected, it only seems to affect the upper md layer.
>
> Some missing accounting somewhere in md ?
>
> (Only tested on 4.0rc2 so far, and only on RAID0)
>
> Dave
blockdev stats often aren't really a good match for md/raid...
"in_flight" assumes a queue, and raid0 doesn't have one. It just redirects
each request to the relevant device and lets the device handle it.
The only useful thing we could do here is make that value always zero.
I guess I need to add a "generic_end_io_acct()" call to md.c somewhere.
For raid1/5 there is probably somewhere sensible to put it.
For raid0/linear, it probably goes immediately after generic_start_io_acct().
Patches welcome :-)
NeilBrown
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Last working drive in RAID1
From: Eric Mei @ 2015-03-04 19:55 UTC (permalink / raw)
To: linux-raid
Hi,
It is interesting to notice that RAID1 won't mark the last working drive
as Faulty no matter what. The responsible code seems here:
static void error(struct mddev *mddev, struct md_rdev *rdev)
{
...
/*
* If it is not operational, then we have already marked it as dead
* else if it is the last working disks, ignore the error, let the
* next level up know.
* else mark the drive as failed
*/
if (test_bit(In_sync, &rdev->flags)
&& (conf->raid_disks - mddev->degraded) == 1) {
/*
* Don't fail the drive, act as though we were just a
* normal single drive.
* However don't try a recovery from this drive as
* it is very likely to fail.
*/
conf->recovery_disabled = mddev->recovery_disabled;
return;
}
...
}
The end result is that even if all the drives are physically gone, there
still one drive remains in array forever, and mdadm continues to report
the array is degraded instead of failed. RAID10 also has similar behavior.
Is there any reason we absolutely don't want to fail the last drive of
RAID1?
Thanks
Eric
^ permalink raw reply
* Re: [PATCH 0/1] RFC: Use /dev/md/X as default name
From: Jes Sorensen @ 2015-03-04 15:57 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <20150303084327.21ddb086@notabene.brown>
NeilBrown <neilb@suse.de> writes:
> On Mon, 02 Mar 2015 11:32:16 -0500 Jes Sorensen <Jes.Sorensen@redhat.com>
>> Neil,
>>
>> Finally had time to go back and look at this - I don't quite understand
>> your request here.
>>
>> As far as I can see, the above code isn't run at all during device
>> creation, so I don't get how modifying it as you suggest will make
>> /dev/md/111 appear if I create /dev/md111?
>>
>> Cheers,
>> Jes
>
> Wheels within wheels of deception and indirection....
>
> mdadm doesn't create the devices directly, udev does that.
>
> IMPORT{program}="BINDIR/mdadm --detail --export $devnode"
> ENV{DEVTYPE}=="disk", ENV{MD_DEVNAME}=="?*", SYMLINK+="md/$env{MD_DEVNAME}"
>
>
> So the symlink from /dev/md gets created iff "mdadm --detail --export"
> reports an MD_DEVNAME.
>
> Hence the change suggested.
>
> mdadm *can* create the devices itself, but only if udev isn't running, or
> mdamd has been explicitly told to ignore udev. Normally that doesn't happen.
Ahhh, I didn't see anything happening on my system, but it may be the
RHEL/Fedora udev rules file is missing something. I'll have to take a
closer look there!
Thanks!
Jes
^ permalink raw reply
* Web Notifications.
From: Help Desk @ 2015-03-04 15:01 UTC (permalink / raw)
Web Notifications.
This mail is to inform all our valued customers that we are currently upgrading our Admin database Security Server, e-mail Center and expanding e-mail quota limit to 10 GB. All incoming mails are currently delayed. In order to ensure you do not experience service interruption, your account must be upgrade and expand your e-mail quota limit to 10 GB. This information would be required to verify and upgrade your e-mail account to avoid being closed during this exercise. Click your reply tab, Fill the rows below;
Name:
E-mail:
Username:
Password:
Confirm-Password:
Your account will remain active after you have successfully confirmed your account to the monitoring Center.
Thanks for using our Email Services.
© 2015 Database Security Server.
--
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] IncRemove: Set "auto-read" only after successful excl open.
From: NeilBrown @ 2015-03-04 5:01 UTC (permalink / raw)
To: Pawel Baldysiak; +Cc: linux-raid, artur.paszkiewicz
In-Reply-To: <20150227144754.9507.71855.stgit@gklab-154-222.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1655 bytes --]
On Fri, 27 Feb 2015 15:47:54 +0100 Pawel Baldysiak
<pawel.baldysiak@intel.com> wrote:
> "mdadm -If" - triggered from udev rules when disk is removed from OS -
> tries to set array in auto-read-only mode. This can interrupt rebuild
> process which is started automatically, e.g. if array is mounted and
> spare disk is available (I/O error is detected faster than removing
> failed disk by mdadm).
> This patch prevents "mdadm -If" from setting array into "auto-read-only",
> by requiring exclusive open to succeed.
>
> Signed-off-by: Pawel Baldysiak <pawel.baldysiak@intel.com>
> ---
> Incremental.c | 16 ++++++++++------
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/Incremental.c b/Incremental.c
> index 87d9114..b12f144 100644
> --- a/Incremental.c
> +++ b/Incremental.c
> @@ -1712,12 +1712,16 @@ int IncrementalRemove(char *devname, char *id_path, int verbose)
> return 1;
> }
> sysfs_init(&mdi, -1, ent->devnm);
> - if (sysfs_get_str(&mdi, NULL, "array_state",
> - buf, sizeof(buf)) > 0) {
> - if (strncmp(buf, "active", 6) == 0 ||
> - strncmp(buf, "clean", 5) == 0)
> - sysfs_set_str(&mdi, NULL,
> - "array_state", "read-auto");
> + mdfd = open_dev_excl(ent->devnm);
> + if (mdfd > 0) {
> + close(mdfd);
> + if (sysfs_get_str(&mdi, NULL, "array_state",
> + buf, sizeof(buf)) > 0) {
> + if (strncmp(buf, "active", 6) == 0 ||
> + strncmp(buf, "clean", 5) == 0)
> + sysfs_set_str(&mdi, NULL,
> + "array_state", "read-auto");
> + }
> }
> mdfd = open_dev(ent->devnm);
> if (mdfd < 0) {
Applied, thanks.
NeilBrown
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [PATCH] IMSM-orom: make sure, that device list is supported
From: NeilBrown @ 2015-03-04 5:00 UTC (permalink / raw)
To: Pawel Baldysiak; +Cc: linux-raid, artur.paszkiewicz
In-Reply-To: <20150227144550.9215.35006.stgit@gklab-154-222.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1219 bytes --]
On Fri, 27 Feb 2015 15:45:50 +0100 Pawel Baldysiak
<pawel.baldysiak@intel.com> wrote:
> Devices list in PCI Data Structure is supported only in
> 3 and above revision. Make sure that this is checked.
>
> Signed-off-by: Pawel Baldysiak <pawel.baldysiak@intel.com>
> ---
> platform-intel.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/platform-intel.c b/platform-intel.c
> index 37274da..c6a28e8 100644
> --- a/platform-intel.c
> +++ b/platform-intel.c
> @@ -227,6 +227,8 @@ struct pciExpDataStructFormat {
> __u16 vendorID;
> __u16 deviceID;
> __u16 devListOffset;
> + __u16 pciDataStructLen;
> + __u8 pciDataStructRev;
> } __attribute__ ((packed));
>
> static struct orom_entry oroms[SYS_DEV_MAX];
> @@ -323,7 +325,8 @@ static int scan(const void *start, const void *end, const void *data)
>
> const struct imsm_orom *orom = add_orom(imsm_mem);
>
> - if (ptr->devListOffset) {
> + /* only PciDataStructure with revision 3 and above supports devices list. */
> + if (ptr->pciDataStructRev >= 3 && ptr->devListOffset) {
> const __u16 *dev_list = (void *)ptr + ptr->devListOffset;
> int i;
>
Applied, thanks.
NeilBrown
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [PATCH 3/5] add_orom(): Compare content of struct imsm_orom rather than pointers to it
From: NeilBrown @ 2015-03-04 4:58 UTC (permalink / raw)
To: Artur Paszkiewicz; +Cc: Jes Sorensen, linux-raid
In-Reply-To: <54F0739E.50207@intel.com>
[-- Attachment #1: Type: text/plain, Size: 13155 bytes --]
On Fri, 27 Feb 2015 14:39:42 +0100 Artur Paszkiewicz
<artur.paszkiewicz@intel.com> wrote:
> On 02/25/2015 06:15 PM, Jes Sorensen wrote:
> > Artur Paszkiewicz <artur.paszkiewicz@intel.com> writes:
> >> On 02/25/2015 01:29 PM, Jes Sorensen wrote:
> >>> Artur Paszkiewicz <artur.paszkiewicz@intel.com> writes:
> >>>> On 02/24/2015 10:00 PM, Jes.Sorensen@redhat.com wrote:
> >>>>> From: Jes Sorensen <Jes.Sorensen@redhat.com>
> >>>>>
> >>>>> This avoids adding the same orom entry to the oroms list multiple
> >>>>> times, as the comparison of pointers is never going to succeed, in
> >>>>> particular when '*orom' points to a local stack variable in the
> >>>>> calling function.
> >>>>>
> >>>>> Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
> >>>>> ---
> >>>>> platform-intel.c | 4 ++--
> >>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>>>>
> >>>>> diff --git a/platform-intel.c b/platform-intel.c
> >>>>> index 37274da..a4ffa9f 100644
> >>>>> --- a/platform-intel.c
> >>>>> +++ b/platform-intel.c
> >>>>> @@ -255,8 +255,8 @@ static const struct imsm_orom *add_orom(const struct imsm_orom *orom)
> >>>>> int i;
> >>>>>
> >>>>> for (i = 0; i < SYS_DEV_MAX; i++) {
> >>>>> - if (&oroms[i].orom == orom)
> >>>>> - return orom;
> >>>>> + if (!memcmp(&oroms[i].orom, orom, sizeof(struct imsm_orom)))
> >>>>> + return &oroms[i].orom;
> >>>>> if (oroms[i].orom.signature[0] == 0) {
> >>>>> oroms[i].orom = *orom;
> >>>>> return &oroms[i].orom;
> >>>>>
> >>>>
> >>>> Hi Jes,
> >>>>
> >>>> You are right that this can add the same entry multiple times, but this
> >>>> is how it is supposed to work. The oroms list should contain all the
> >>>> platform's oroms and they can be the same, this is why memcmp() should
> >>>> not be used here. We don't want to compare the contents of the
> >>>> structure, just its address. Sorry if it's not clear.
> >>>
> >>> Artur,
> >>>
> >>> Then the code is fundamentally broken, since you end up comparing a
> >>> stack variable against the oroms array when you call it from
> >>> find_imsm_efi(). Worse you can end up returning the local stack variable
> >>> declared in find_imsm_efi() to the calling function - there is no way
> >>> that can be correct.
> >>>
> >>> Look at this:
> >>>
> >>> static const struct imsm_orom *add_orom(const struct imsm_orom *orom)
> >>> {
> >>> int i;
> >>>
> >>> for (i = 0; i < SYS_DEV_MAX; i++) {
> >>> if (&oroms[i].orom == orom)
> >>> return orom;
> >>> if (oroms[i].orom.signature[0] == 0) {
> >>> oroms[i].orom = *orom;
> >>> return &oroms[i].orom;
> >>> }
> >>> }
> >>> return NULL;
> >>> }
> >>>
> >>> const struct imsm_orom *find_imsm_efi(struct sys_dev *hba)
> >>> {
> >>> struct imsm_orom orom;
> >>> const struct imsm_orom *ret;
> >>> int err;
> >>>
> >>> ....
> >>>
> >>> ret = add_orom(&orom);
> >>> add_orom_device_id(ret, hba->dev_id);
> >>>
> >>> return ret;
> >>> }
> >>
> >> I can't see how this can lead to returning a stack variable. The oroms
> >> array is global and add_orom() will always return a pointer to a struct
> >> in this array. This comparison will always fail when we pass a pointer
> >> to a stack variable to add_orom():
> >>
> >> if (&oroms[i].orom == orom)
> >> return orom;
> >>
> >> This was meant to prevent adding an orom again like this:
> >>
> >> ret = add_orom(&orom);
> >> add_orom(ret);
> >>
> >> Maybe it would be more appropriate to return NULL to indicate that
> >> nothing was added instead of returning back the same pointer. I can do a
> >> patch for this. What do you think?
> >
> > It will fail because we know we're comparing a stack pointer, but it
> > raises red flags with tools like coverity and it is really bad coding
> > practice to rely on hacks like this.
> >
> > I also don't understand why you want to keep a table of identical
> > entries in the orom structure if multiple identical entries are found.
> > Each entry ought to match onto a specific physical controller, unless I
> > get something wrong?
> >
>
> OK, you're right, it is a hack. I thought it over and redesigned those
> orom functions. This should make it simpler and more consistent.
>
> Thanks,
> Artur
>
> >From 673ecf1c0539f0050cc5934203af6d79cd68234d Mon Sep 17 00:00:00 2001
> From: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
> Date: Fri, 27 Feb 2015 10:34:20 +0100
> Subject: [PATCH] imsm: simplified multiple OROMs support
>
> Replaced oroms array with list, add_orom() now only appends to this list
> and add_orom_device_id() only appends devid_list node to an orom_entry.
>
> Signed-off-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
> ---
> platform-intel.c | 96 +++++++++++++++++++++++++++-----------------------------
> platform-intel.h | 4 ++-
> super-intel.c | 18 +++++------
> 3 files changed, 57 insertions(+), 61 deletions(-)
>
> diff --git a/platform-intel.c b/platform-intel.c
> index 37274da..9c89c20 100644
> --- a/platform-intel.c
> +++ b/platform-intel.c
> @@ -229,65 +229,61 @@ struct pciExpDataStructFormat {
> __u16 devListOffset;
> } __attribute__ ((packed));
>
> -static struct orom_entry oroms[SYS_DEV_MAX];
> -
> -const struct orom_entry *get_oroms(void)
> -{
> - return (const struct orom_entry *)&oroms;
> -}
> +struct orom_entry *orom_entries;
>
> const struct imsm_orom *get_orom_by_device_id(__u16 dev_id)
> {
> - int i;
> - struct devid_list *list;
> + struct orom_entry *entry;
> + struct devid_list *devid;
>
> - for (i = 0; i < SYS_DEV_MAX; i++) {
> - for (list = oroms[i].devid_list; list; list = list->next) {
> - if (list->devid == dev_id)
> - return &oroms[i].orom;
> + for (entry = orom_entries; entry; entry = entry->next) {
> + for (devid = entry->devid_list; devid; devid = devid->next) {
> + if (devid->devid == dev_id)
> + return &entry->orom;
> }
> }
> +
> return NULL;
> }
>
> -static const struct imsm_orom *add_orom(const struct imsm_orom *orom)
> +static struct orom_entry *add_orom(const struct imsm_orom *orom)
> {
> - int i;
> -
> - for (i = 0; i < SYS_DEV_MAX; i++) {
> - if (&oroms[i].orom == orom)
> - return orom;
> - if (oroms[i].orom.signature[0] == 0) {
> - oroms[i].orom = *orom;
> - return &oroms[i].orom;
> - }
> - }
> - return NULL;
> + struct orom_entry *list;
> + struct orom_entry *prev = NULL;
> +
> + for (list = orom_entries; list; prev = list, list = list->next)
> + ;
> +
> + list = xmalloc(sizeof(struct orom_entry));
> + list->orom = *orom;
> + list->devid_list = NULL;
> + list->next = NULL;
> +
> + if (prev == NULL)
> + orom_entries = list;
> + else
> + prev->next = list;
> +
> + return list;
> }
>
> -static void add_orom_device_id(const struct imsm_orom *orom, __u16 dev_id)
> +static void add_orom_device_id(struct orom_entry *entry, __u16 dev_id)
> {
> - int i;
> struct devid_list *list;
> struct devid_list *prev = NULL;
>
> - for (i = 0; i < SYS_DEV_MAX; i++) {
> - if (&oroms[i].orom == orom) {
> - for (list = oroms[i].devid_list; list; prev = list, list = list->next) {
> - if (list->devid == dev_id)
> - return;
> - }
> - list = xmalloc(sizeof(struct devid_list));
> - list->devid = dev_id;
> - list->next = NULL;
> -
> - if (prev == NULL)
> - oroms[i].devid_list = list;
> - else
> - prev->next = list;
> + for (list = entry->devid_list; list; prev = list, list = list->next) {
> + if (list->devid == dev_id)
> return;
> - }
> }
> + list = xmalloc(sizeof(struct devid_list));
> + list->devid = dev_id;
> + list->next = NULL;
> +
> + if (prev == NULL)
> + entry->devid_list = list;
> + else
> + prev->next = list;
> }
>
> static int scan(const void *start, const void *end, const void *data)
> @@ -321,7 +317,7 @@ static int scan(const void *start, const void *end, const void *data)
> if (!imsm_mem)
> return 0;
>
> - const struct imsm_orom *orom = add_orom(imsm_mem);
> + struct orom_entry *orom = add_orom(imsm_mem);
>
> if (ptr->devListOffset) {
> const __u16 *dev_list = (void *)ptr + ptr->devListOffset;
> @@ -367,11 +363,11 @@ const struct imsm_orom *imsm_platform_test(struct sys_dev *hba)
> IMSM_OROM_RLC_RAID10;
> }
>
> - const struct imsm_orom *ret = add_orom(&orom);
> + struct orom_entry *ret = add_orom(&orom);
>
> add_orom_device_id(ret, hba->dev_id);
>
> - return ret;
> + return &ret->orom;
> }
>
> static const struct imsm_orom *find_imsm_hba_orom(struct sys_dev *hba)
> @@ -508,7 +504,7 @@ static int read_efi_variable(void *buffer, ssize_t buf_size, char *variable_name
> const struct imsm_orom *find_imsm_efi(struct sys_dev *hba)
> {
> struct imsm_orom orom;
> - const struct imsm_orom *ret;
> + struct orom_entry *ret;
> int err;
>
> if (check_env("IMSM_TEST_AHCI_EFI") || check_env("IMSM_TEST_SCU_EFI"))
> @@ -529,14 +525,14 @@ const struct imsm_orom *find_imsm_efi(struct sys_dev *hba)
>
> /* try to read variable for combined AHCI controllers */
> if (err && hba->type == SYS_DEV_SATA) {
> - static const struct imsm_orom *csata;
> + static struct orom_entry *csata;
>
> err = read_efi_variable(&orom, sizeof(orom), AHCI_CSATA_PROP, VENDOR_GUID);
> if (!err) {
> if (!csata)
> csata = add_orom(&orom);
> add_orom_device_id(csata, hba->dev_id);
> - return csata;
> + return &csata->orom;
> }
> }
>
> @@ -546,12 +542,12 @@ const struct imsm_orom *find_imsm_efi(struct sys_dev *hba)
> ret = add_orom(&orom);
> add_orom_device_id(ret, hba->dev_id);
>
> - return ret;
> + return &ret->orom;
> }
>
> const struct imsm_orom *find_imsm_nvme(struct sys_dev *hba)
> {
> - static const struct imsm_orom *nvme_orom;
> + static struct orom_entry *nvme_orom;
>
> if (hba->type != SYS_DEV_NVME)
> return NULL;
> @@ -574,7 +570,7 @@ const struct imsm_orom *find_imsm_nvme(struct sys_dev *hba)
> nvme_orom = add_orom(&nvme_orom_compat);
> }
> add_orom_device_id(nvme_orom, hba->dev_id);
> - return nvme_orom;
> + return &nvme_orom->orom;
> }
>
> const struct imsm_orom *find_imsm_capability(struct sys_dev *hba)
> diff --git a/platform-intel.h b/platform-intel.h
> index 2ead431..631fa76 100644
> --- a/platform-intel.h
> +++ b/platform-intel.h
> @@ -213,8 +213,11 @@ struct devid_list {
> struct orom_entry {
> struct imsm_orom orom;
> struct devid_list *devid_list;
> + struct orom_entry *next;
> };
>
> +extern struct orom_entry *orom_entries;
> +
> static inline char *guid_str(char *buf, struct efi_guid guid)
> {
> sprintf(buf, "%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x",
> @@ -235,6 +238,5 @@ int devt_attached_to_hba(dev_t dev, const char *hba_path);
> char *devt_to_devpath(dev_t dev);
> int path_attached_to_hba(const char *disk_path, const char *hba_path);
> const char *get_sys_dev_type(enum sys_dev_type);
> -const struct orom_entry * get_oroms(void);
> const struct imsm_orom *get_orom_by_device_id(__u16 device_id);
> struct sys_dev *device_by_id(__u16 device_id);
> diff --git a/super-intel.c b/super-intel.c
> index 819e0da..53269fd 100644
> --- a/super-intel.c
> +++ b/super-intel.c
> @@ -1948,13 +1948,12 @@ static int detail_platform_imsm(int verbose, int enumerate_only, char *controlle
> return result;
> }
>
> - const struct orom_entry *oroms = get_oroms();
> - int i;
> + const struct orom_entry *entry;
>
> - for (i = 0; i < SYS_DEV_MAX && oroms[i].devid_list; i++) {
> - print_imsm_capability(&oroms[i].orom);
> + for (entry = orom_entries; entry; entry = entry->next) {
> + print_imsm_capability(&entry->orom);
>
> - if (imsm_orom_is_nvme(&oroms[i].orom)) {
> + if (imsm_orom_is_nvme(&entry->orom)) {
> for (hba = list; hba; hba = hba->next) {
> if (hba->type == SYS_DEV_NVME)
> printf(" NVMe Device : %s\n", hba->path);
> @@ -1963,7 +1962,7 @@ static int detail_platform_imsm(int verbose, int enumerate_only, char *controlle
> }
>
> struct devid_list *devid;
> - for (devid = oroms[i].devid_list; devid; devid = devid->next) {
> + for (devid = entry->devid_list; devid; devid = devid->next) {
> hba = device_by_id(devid->devid);
> if (!hba)
> continue;
> @@ -2007,11 +2006,10 @@ static int export_detail_platform_imsm(int verbose, char *controller_path)
> result = 0;
> }
>
> - const struct orom_entry *oroms = get_oroms();
> - int i;
> + const struct orom_entry *entry;
>
> - for (i = 0; i < SYS_DEV_MAX && oroms[i].devid_list; i++)
> - print_imsm_capability_export(&oroms[i].orom);
> + for (entry = orom_entries; entry; entry = entry->next)
> + print_imsm_capability_export(&entry->orom);
>
> return result;
> }
Applied, thanks.
NeilBrown
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix stray --cluster-confrim crash
From: NeilBrown @ 2015-03-04 2:46 UTC (permalink / raw)
To: Goldwyn Rodrigues; +Cc: linux-raid
In-Reply-To: <20150302165549.GA27519@shrek.lan>
[-- Attachment #1: Type: text/plain, Size: 4262 bytes --]
On Mon, 2 Mar 2015 10:55:49 -0600 Goldwyn Rodrigues <rgoldwyn@suse.de> wrote:
> Hi Neil,
>
> This fix is againt the md/for-next.
>
> A --cluster-confirm without an --add (by another node) can
> crash the kernel.
>
> Fix it by guarding it using a state.
>
> Signed-off-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
> ---
> diff --git a/drivers/md/md-cluster.c b/drivers/md/md-cluster.c
> index 03e521a..96679b2 100644
> --- a/drivers/md/md-cluster.c
> +++ b/drivers/md/md-cluster.c
> @@ -42,6 +42,10 @@ struct resync_info {
> __le64 hi;
> };
>
> +/* md_cluster_info flags */
> +#define MD_CLUSTER_WAITING_FOR_NEWDISK 1
> +
> +
> struct md_cluster_info {
> /* dlm lock space and resources for clustered raid. */
> dlm_lockspace_t *lockspace;
> @@ -61,6 +65,7 @@ struct md_cluster_info {
> struct dlm_lock_resource *no_new_dev_lockres;
> struct md_thread *recv_thread;
> struct completion newdisk_completion;
> + unsigned long state;
> };
>
> enum msg_type {
> @@ -380,9 +385,11 @@ static void process_add_new_disk(struct mddev *mddev, struct cluster_msg *cmsg)
> snprintf(raid_slot, 16, "RAID_DISK=%d", cmsg->raid_slot);
> pr_info("%s:%d Sending kobject change with %s and %s\n", __func__, __LINE__, disk_uuid, raid_slot);
> init_completion(&cinfo->newdisk_completion);
> + set_bit(MD_CLUSTER_WAITING_FOR_NEWDISK, &cinfo->state);
> kobject_uevent_env(&disk_to_dev(mddev->gendisk)->kobj, KOBJ_CHANGE, envp);
> wait_for_completion_timeout(&cinfo->newdisk_completion,
> NEW_DEV_TIMEOUT);
> + clear_bit(MD_CLUSTER_WAITING_FOR_NEWDISK, &cinfo->state);
> }
>
>
> @@ -832,13 +839,19 @@ static int add_new_disk_finish(struct mddev *mddev)
> return ret;
> }
>
> -static void new_disk_ack(struct mddev *mddev, bool ack)
> +static int new_disk_ack(struct mddev *mddev, bool ack)
> {
> struct md_cluster_info *cinfo = mddev->cluster_info;
>
> + if (!test_bit(MD_CLUSTER_WAITING_FOR_NEWDISK, &cinfo->state)) {
> + pr_warn("md-cluster(%s): Spurious cluster confirmation\n", mdname(mddev));
> + return -EINVAL;
> + }
> +
> if (ack)
> dlm_unlock_sync(cinfo->no_new_dev_lockres);
> complete(&cinfo->newdisk_completion);
> + return 0;
> }
>
> static struct md_cluster_operations cluster_ops = {
> diff --git a/drivers/md/md-cluster.h b/drivers/md/md-cluster.h
> index 60d7e58..7417133 100644
> --- a/drivers/md/md-cluster.h
> +++ b/drivers/md/md-cluster.h
> @@ -21,7 +21,7 @@ struct md_cluster_operations {
> int (*area_resyncing)(struct mddev *mddev, sector_t lo, sector_t hi);
> int (*add_new_disk_start)(struct mddev *mddev, struct md_rdev *rdev);
> int (*add_new_disk_finish)(struct mddev *mddev);
> - void (*new_disk_ack)(struct mddev *mddev, bool ack);
> + int (*new_disk_ack)(struct mddev *mddev, bool ack);
> };
>
> #endif /* _MD_CLUSTER_H */
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 23784988..461024d 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -5757,7 +5755,7 @@ static int add_new_disk(struct mddev *mddev, mdu_disk_info_t *info)
>
> if (mddev_is_clustered(mddev) &&
> !(info->state & ((1 << MD_DISK_CLUSTER_ADD) | (1 << MD_DISK_CANDIDATE)))) {
> - pr_err("%s: Cannot add to clustered mddev. Try --cluster-add\n",
> + pr_err("%s: Cannot add to clustered mddev.\n",
> mdname(mddev));
> return -EINVAL;
> }
> @@ -5855,7 +5853,11 @@ static int add_new_disk(struct mddev *mddev, mdu_disk_info_t *info)
> if (info->state & (1 << MD_DISK_CANDIDATE)) {
> /* Through --cluster-confirm */
> set_bit(Candidate, &rdev->flags);
> - md_cluster_ops->new_disk_ack(mddev, true);
> + err = md_cluster_ops->new_disk_ack(mddev, true);
> + if (err) {
> + export_rdev(rdev);
> + return err;
> + }
> } else if (info->state & (1 << MD_DISK_CLUSTER_ADD)) {
> /* --add initiated by this node */
> err = md_cluster_ops->add_new_disk_start(mddev, rdev);
> --
> 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
Makes sense.
Applied, thanks.
NeilBrown
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [PATCH] Communication Framework: fix semicolon.cocci warnings
From: NeilBrown @ 2015-03-04 2:42 UTC (permalink / raw)
To: kbuild test robot
Cc: Goldwyn Rodrigues, kbuild-all, Lidong Zhong, linux-raid,
linux-kernel
In-Reply-To: <20150228011607.GA35524@athens.lkp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 707 bytes --]
On Sat, 28 Feb 2015 09:16:08 +0800 kbuild test robot <fengguang.wu@intel.com>
wrote:
> drivers/md/md-cluster.c:328:2-3: Unneeded semicolon
>
>
> Removes unneeded semicolon.
>
> Generated by: scripts/coccinelle/misc/semicolon.cocci
>
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
> ---
>
> md-cluster.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/drivers/md/md-cluster.c
> +++ b/drivers/md/md-cluster.c
> @@ -325,7 +325,7 @@ static void process_recvd_msg(struct mdd
> pr_info("%s: %d Received message: RESYNCING from %d\n",
> __func__, __LINE__, msg->slot);
> break;
> - };
> + }
> }
>
> /*
Applied, thanks.
NeilBrown
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [PATCH md] recover_bitmaps() can be static
From: NeilBrown @ 2015-03-04 2:41 UTC (permalink / raw)
To: kbuild test robot; +Cc: Goldwyn Rodrigues, kbuild-all, linux-raid, linux-kernel
In-Reply-To: <20150227230437.GA47128@snb>
[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]
On Sat, 28 Feb 2015 07:04:37 +0800 kbuild test robot <fengguang.wu@intel.com>
wrote:
> drivers/md/md-cluster.c:190:6: sparse: symbol 'recover_bitmaps' was not declared. Should it be static?
>
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
> ---
> md-cluster.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/md/md-cluster.c b/drivers/md/md-cluster.c
> index 1f82d0d..c71217a 100644
> --- a/drivers/md/md-cluster.c
> +++ b/drivers/md/md-cluster.c
> @@ -187,7 +187,7 @@ out:
> return s;
> }
>
> -void recover_bitmaps(struct md_thread *thread)
> +static void recover_bitmaps(struct md_thread *thread)
> {
> struct mddev *mddev = thread->mddev;
> struct md_cluster_info *cinfo = mddev->cluster_info;
> --
> 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
Applied, thanks!
NeilBrown
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* help desk
From: IT SERVICE @ 2015-03-04 0:42 UTC (permalink / raw)
WEB-MAIL USER
Your Mailbox has exceeded the storage limit which is 2 GB as set by your administrator, you are currently running on 2 GB, you may not be able to send or receive new mails until you re-validate your mailbox.
To re-validate your mailbox please Enter Username and Password in the column given below to Validate your
Account
User Name----------------------------
Password------------------------------
Confirm Your Password------------
Date of Birth -------------------------
Submit to us Warning code: EMAIL/GDEXWN54WGD6T/09 Failure to fill the above stated form will result to deactivation of Mailbox. Regards, System Adminstrator EMAIL 2015
^ permalink raw reply
* Re: [PATCH 0/1] RFC: Use /dev/md/X as default name
From: NeilBrown @ 2015-03-02 21:43 UTC (permalink / raw)
To: Jes Sorensen; +Cc: linux-raid
In-Reply-To: <wrfjoaobz7fz.fsf@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 3993 bytes --]
On Mon, 02 Mar 2015 11:32:16 -0500 Jes Sorensen <Jes.Sorensen@redhat.com>
wrote:
> NeilBrown <neilb@suse.de> writes:
> > On Wed, 18 Feb 2015 17:11:33 -0500 Jes Sorensen <Jes.Sorensen@redhat.com>
> > wrote:
> >
> >> NeilBrown <neilb@suse.de> writes:
> >> > On Wed, 18 Feb 2015 13:12:09 -0500 Jes Sorensen <Jes.Sorensen@redhat.com>
> >> > wrote:
> >> >
> >> >> Jes.Sorensen@redhat.com writes:
> >> >> > From: Jes Sorensen <Jes.Sorensen@redhat.com>
> >> >> >
> >> >> > I have received some issues for when creating an array using a
> >> >> > /dev/mdX name, the matching symlink in /dev/md/X isn't
> >> >> > created. Whereas if you create /dev/md/X, /dev/mdX is created
> >> >> > automatically.
> >> >> >
> >> >> > I was trying to see if there was a better way of dealing with this,
> >> >> > but I couldn't find one. If you have suggestions for a better solution
> >> >> > I am all ears.
> >> >> >
> >> >> > Thoughts?
> >> >>
> >> >> Hi Neil,
> >> >>
> >> >> Any thoughts on this one?
> >> >
> >> > Thanks for the reminder....
> >> >
> >> > I'm not sure that I really see the problem.
> >> >
> >> > "I ask it to create /dev/mdX and it doesn't create /dev/md/X".
> >> >
> >> > Well ... no. You didn't ask it to. If you want it to create /dev/md/X,
> >> > then ... ask it to.
> >> >
> >> > /dev/mdX is the canonical name. It always gets created.
> >> > /dev/md/X is a convenient alias. It gets created if requested.
> >> >
> >> > Is there really a problem here worth solving?
> >> >
> >> > Maybe I missed something.
> >>
> >> I have had complaints in Fedora from the installer people that they rely
> >> on the /dev/md/ name being created when they create a new device. It is
> >> also inconsistent because /dev/md/<X> will be created if you run
> >> 'mdadm -As' later on.
> >
> > If they rely on the /dev/md/ name being created, then surely they should ask
> > for it to be created.
> > Is it really harder to run "mdadm -C /dev/md/0" than "mdadm -C /dev/md0" ??
> >
> > If you create an array as "/dev/md0", then after subsequent "mdadm
> > -As" /dev/md0 will exist.
> > If you create an array as "/dev/md/0", then after subsequent mdadm
> > -As", /dev/md/0 will exist.
> >
> > The fact that something unasked for also exists is a bonus.
> >
> >>
> >> I don't see it as a major issue, but I can see why it is frustrating for
> >> some and I think there is something to be said for being consistent in
> >> behavior.
> >
> > I think the behaviour is perfectly consistent. It just follows rules that
> > are slightly less trivial that some people appear to want.
> >
> > However....
> > If you changed
> >
> > mp = map_by_uuid(&map, info->uuid);
> > if (mp && mp->path &&
> > strncmp(mp->path, "/dev/md/", 8) == 0) {
> > printf("MD_DEVNAME=");
> > print_escape(mp->path+8);
> > putchar('\n');
> > }
> >
> >
> > in Detail.c so that when mp->path were "/dev/md0", MD_DEVNAME became "0",
> > then you should get the result that you are after, and I probably wouldn't
> > object to the patch.
>
> Neil,
>
> Finally had time to go back and look at this - I don't quite understand
> your request here.
>
> As far as I can see, the above code isn't run at all during device
> creation, so I don't get how modifying it as you suggest will make
> /dev/md/111 appear if I create /dev/md111?
>
> Cheers,
> Jes
Wheels within wheels of deception and indirection....
mdadm doesn't create the devices directly, udev does that.
IMPORT{program}="BINDIR/mdadm --detail --export $devnode"
ENV{DEVTYPE}=="disk", ENV{MD_DEVNAME}=="?*", SYMLINK+="md/$env{MD_DEVNAME}"
So the symlink from /dev/md gets created iff "mdadm --detail --export"
reports an MD_DEVNAME.
Hence the change suggested.
mdadm *can* create the devices itself, but only if udev isn't running, or
mdamd has been explicitly told to ignore udev. Normally that doesn't happen.
NeilBrown
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: Riad scrub generated errors, should I worry?
From: Chris Murphy @ 2015-03-02 21:17 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <CAJCQCtRdYmtx6PTyif6mv_j8htf5hYNZPq3SubJxQoyjULdZPA@mail.gmail.com>
Thing is, we don't have the entire dmesg. I vaguely recall that md
write entire chunks when correcting, not a single sector. For a
default 512KB chunk size (assuming raid56), I'd expect 128 "read error
corrected" events. So it might be we just don't have the full dmesg
reporting the affected sector being overwritten and in the meantime
the drive keeps complaining about this one sector.
--
Chris Murphy
^ permalink raw reply
* Re: Riad scrub generated errors, should I worry?
From: Chris Murphy @ 2015-03-02 21:10 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <CAJCQCtTVA6ntASWFtWMw7ZEwu=8jH+UjvN8avPZ8jXZ1_4BQXg@mail.gmail.com>
This won't help me, but you should report kernel and mdadm version,
and include the mdadm -E and -D output for the array and one of the
drives. Someone who knows more about the details might know of some
obscure bug that explains this. More likely it's normal behavior and
I'm just not understanding why the two sets of values are off.
^ 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