* Re: Fwd: I will pay money for the correct RAID recovery instructions
From: John Stoffel @ 2014-10-17 16:14 UTC (permalink / raw)
To: Another Sillyname; +Cc: linux-raid
In-Reply-To: <CAOS+5GEbNPAWfBL_uPDOuhMb4LtN+_fJ07MD7igOQmVi04mWpA@mail.gmail.com>
Another> Sorry to state the obvious but...... To restore the degraded
Another> array would (based on the info you've posted) likely take
Another> longer then temporarily moving the data to a different set of
Another> drives.
How do you figure this? He hasn't posted any useful data on his array
at all. We know it's six 3Tb disks in RAID10, so that's at most 9Tb
of data. Moving 3Tb (bad disk ddrescue'd onto new disk) is only 3Tb
to move. Then the resync will of course take time.
But if he doesn't have the spare disk space, it's probably the only way.
Another> As time seems to be a major consideration here (likely/possible
Another> failure of sde) then surely the optimal strategy has to be to get the
Another> data off first, then look at the rebuilding the degraded array?
Another> Just my 2c
Another> On 17 October 2014 15:05, John Stoffel <john@stoffel.org> wrote:
>>
>>
>> Ian,
>>
>> It would also help if you posted the details of your setup using:
>>
>> cat /proc/partitions
>> cat /proc/mdstat
>>
>> mdadm -D /dev/md#
>> - for each of the devices above.
>>
>> mdadm -E /dev/sd<drive><#>
>> - for each disk or partition in the array from above.
>>
>>
>>
>> But the suggestions to ddrescue the going bad drive onto a new disk is
>> a good one. On my debian system, I would do the following:
>>
>> sudo apt-get install gddrescue
>> ddrescue /dev/sde /dev/sdf /var/tmp/ddrecue-sde.log
>>
>> and see how that goes.
>>
>> Good luck,
>> John
>> --
>> 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
Another> --
Another> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
Another> the body of a message to majordomo@vger.kernel.org
Another> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: migrate to bad block list
From: Piergiorgio Sartor @ 2014-10-17 17:06 UTC (permalink / raw)
To: NeilBrown; +Cc: Michael Ryan, linux-raid@vger.kernel.org
In-Reply-To: <20141016175414.01334582@notabene.brown>
Hi Neil,
On Thu, Oct 16, 2014 at 05:54:14PM +1100, NeilBrown wrote:
> On Wed, 15 Oct 2014 17:18:19 +0000 Michael Ryan <mryan@lenovoemc.com> wrote:
>
> >
> > Is there any way to migrate an existing array created with mdadm v3.2.5 and using 1.1 metadata to use a bad block list? I'm assuming not as there wouldn't be space reserved for the list, but I need to ask.
> >
> > Thanks for your response!
>
> mdadm tends to leave a fair bit of unused space on devices so that things
> like a bad block list can easily be added.
> If you can stop the array, then do that and re-assemble with
> --update=bbl
>
> and you should get a bbl added to each device.
>
> If you cannot stop the array, but it has a bitmap, then
> you can, for each device:
>
> mdadm /dev/mdX --fail /dev/adevice
> mdadm /dev/mdX --remove /dev/adevice
> mdadm /dev/mdX --re-add --update=bbl /dev/adevice
>
> I think that should work. The "bblk" is a feature of the device, not of the
> whole array. So you can add it to each device.
is there any technical reason why it is not
possible to enable/disable the bbl like the
write intent bitmap?
Something like:
mdadm --grow /dev/<md> --bbl=[internal|none]
Thanks,
bye,
pg
> I haven't actually tested the above I think, so it might be safest to make an
> array with loop-back devices and experiment.
>
> NeilBrown
--
piergiorgio
--
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
* Multiple drive failure after stupid mistake. Help needed
From: Per-Ola Stenborg @ 2014-10-19 9:45 UTC (permalink / raw)
To: linux-raid
Hi all,
I have done something very stupid. After getting SMART warnings from one
of my disks in a 4-disk RAID5 array I decided to be proactive and change
the disk.
The array consists of /dev/sd[bcde]. The failing disk is /dev/sdc.
I ran fail and remove on the WRONG disk!
mdadm --manage /dev/md0 --fail /dev/sdb
/proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdb[0](F) sde[4] sdd[2] sdc[1]
5860538880 blocks super 1.2 level 5, 512k chunk, algorithm 2
[4/3] [_UUU]
mdadm --manage /dev/md0 --remove /dev/sdb
I exchanged the physical disk, the failing/right one, /dev/sdc.
When booting my server I noticed my error when the array did not come up.
I thought it was not a problem as the original /dev/sdc was readable so I
shut the server down and put the original disk back and re-added /dev/sdb
/proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdc[1] sde[4] sdd[2]
5860538880 blocks super 1.2 level 5, 512k chunk, algorithm 2
[4/3] [_UUU]
mdadm --manage /dev/md0 --add /dev/sdb
All seemed fine and the array was rebuilding. But when almost done
/dev/sdc failed.
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdb[0] sdc[1](F) sde[4] sdd[2]
5860538880 blocks super 1.2 level 5, 512k chunk, algorithm 2
[4/2] [__UU]
[===================>.] recovery = 95.3% (1862844416/1953512960)
finish=49.5min speed=30502K/sec
A few hours late I got:
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdb[0](S) sdc[1](F) sde[4] sdd[2]
5860538880 blocks super 1.2 level 5, 512k chunk, algorithm 2
[4/2] [__UU]
After reboot I now have
/proc/mdstat
Personalities :
md0 : inactive sdd[2](S) sdb[0](S) sde[4](S) sdc[1](S)
7814054240 blocks super 1.2
unused devices: <none>
/dev/sdb:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : e3394a2b:77411a7d:a6f03a01:19f9b943
Name : backuppc:0 (local to host backuppc)
Creation Time : Mon Dec 19 17:43:44 2011
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 3907027120 (1863.02 GiB 2000.40 GB)
Array Size : 11721077760 (5589.05 GiB 6001.19 GB)
Used Dev Size : 3907025920 (1863.02 GiB 2000.40 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : ed574f2e:b80a509b:b8a5e5a6:3d711e05
Update Time : Fri Oct 17 01:00:05 2014
Checksum : 4fe90596 - correct
Events : 5072
Layout : left-symmetric
Chunk Size : 512K
Device Role : spare
Array State : ..AA ('A' == active, '.' == missing)
/dev/sdc:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : e3394a2b:77411a7d:a6f03a01:19f9b943
Name : backuppc:0 (local to host backuppc)
Creation Time : Mon Dec 19 17:43:44 2011
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 3907027120 (1863.02 GiB 2000.40 GB)
Array Size : 11721077760 (5589.05 GiB 6001.19 GB)
Used Dev Size : 3907025920 (1863.02 GiB 2000.40 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 4ebf1b3b:6821832c:1b520e0e:d363aa4d
Update Time : Fri Oct 17 00:04:20 2014
Checksum : 9d9f1587 - correct
Events : 5064
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AAAA ('A' == active, '.' == missing)
/dev/sdd:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : e3394a2b:77411a7d:a6f03a01:19f9b943
Name : backuppc:0 (local to host backuppc)
Creation Time : Mon Dec 19 17:43:44 2011
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 3907027120 (1863.02 GiB 2000.40 GB)
Array Size : 11721077760 (5589.05 GiB 6001.19 GB)
Used Dev Size : 3907025920 (1863.02 GiB 2000.40 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : ffe21a6e:3256c3d5:8cb68394:1172eb5d
Update Time : Fri Oct 17 01:00:05 2014
Checksum : 1092edcd - correct
Events : 5072
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 2
Array State : ..AA ('A' == active, '.' == missing)
/dev/sde:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : e3394a2b:77411a7d:a6f03a01:19f9b943
Name : backuppc:0 (local to host backuppc)
Creation Time : Mon Dec 19 17:43:44 2011
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 3907027120 (1863.02 GiB 2000.40 GB)
Array Size : 11721077760 (5589.05 GiB 6001.19 GB)
Used Dev Size : 3907025920 (1863.02 GiB 2000.40 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 5ca79fb0:09f51c20:f5c8a851:310f5c2a
Update Time : Fri Oct 17 01:00:05 2014
Checksum : 2707008b - correct
Events : 5072
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 3
Array State : ..AA ('A' == active, '.' == missing)
The /dev/sdc disk is tested with spinrite, and is verified readable.
I've tried forcing an assembly without luck. Did I do it right? What
should i do now?
*** PLEASE advice ***
And off cause I have valuable data on the array without backup...
Best regards
Per-Ola
---
^ permalink raw reply
* Re: Multiple drive failure after stupid mistake. Help needed
From: Mikael Abrahamsson @ 2014-10-19 10:56 UTC (permalink / raw)
To: Per-Ola Stenborg; +Cc: linux-raid
In-Reply-To: <54438839.9080309@stenborg.me>
On Sun, 19 Oct 2014, Per-Ola Stenborg wrote:
> *** PLEASE advice ***
Please post dmesg output from when you do --assemble --force, and also
please post your mdadm and kernel versions.
As a first step, compile mdadm from source and use that version, it often
helps as distributions don't generally ship with the latest mdadm.
--
Mikael Abrahamsson email: swmike@swm.pp.se
^ permalink raw reply
* Re: Multiple drive failure after stupid mistake. Help needed
From: Per-Ola Stenborg @ 2014-10-19 12:58 UTC (permalink / raw)
To: Mikael Abrahamsson; +Cc: linux-raid
In-Reply-To: <alpine.DEB.2.02.1410191253010.30853@uplift.swm.pp.se>
Hi, thanks for your answer. (Tack!)
My debian mdadm is ver v3.1.4 - 31st August 2010
mdadm --assemble --force /dev/md0 /dev/sd[bcde]
outputs
mdadm: cannot open device /dev/sdb: Device or resource busy
mdadm: /dev/sdb has no superblock - assembly aborted
I compiled the latest mdadm v3.3.2 - 21st August 2014
running
mdadm --assemble --force /dev/md0 /dev/sd[bcde]
outputs
mdadm: /dev/sdb is busy - skipping
mdadm: /dev/sdc is busy - skipping
mdadm: /dev/sdd is busy - skipping
mdadm: /dev/sde is busy - skipping
Strange. What does this mean? Is it flaged as in use in the kernel? The
devices are readable, I tried to read data with
dd if=/dev/sdb of=dump bs=1024 count=1024
and it works, so the device is accressible.
dmesg shows nothing
/proc/mdstat
Personalities :
md0 : inactive sdd[2](S) sdb[0](S) sde[4](S) sdc[1](S)
7814054240 blocks super 1.2
uname -a
Linux backuppc 2.6.32-5-686 #1 SMP Sat Jul 12 22:59:16 UTC 2014 i686
GNU/Linux
System is Debian squeeze-lts
Best regards
´
Per-Ola Stenborg
Mikael Abrahamsson skrev 2014-10-19 12:56:
> On Sun, 19 Oct 2014, Per-Ola Stenborg wrote:
>
>> *** PLEASE advice ***
>
> Please post dmesg output from when you do --assemble --force, and also
> please post your mdadm and kernel versions.
>
> As a first step, compile mdadm from source and use that version, it
> often helps as distributions don't generally ship with the latest mdadm.
>
--
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: Multiple drive failure after stupid mistake. Help needed
From: Per-Ola Stenborg @ 2014-10-19 15:56 UTC (permalink / raw)
To: Weedy; +Cc: linux-raid, Mikael Abrahamsson
In-Reply-To: <CAFE24U0GKPhkYe1faCBWohimJYL4O_PBYOJ+aLa_mSMKQCGGhw@mail.gmail.com>
Weedy skrev 2014-10-19 15:41:
>
> Is sdb in another array when you try to assemble?
> Is /proc/mdstat empty while you're trying this?
>
No, here is the output
cat /proc/mdstat
Personalities :
md0 : inactive sdd[2](S) sdb[0](S) sde[4](S) sdc[1](S)
7814054240 blocks super 1.2
unused devices: <none>
there is only one array in this machine.
/Per-Ola
^ permalink raw reply
* Re: Multiple drive failure after stupid mistake. Help needed
From: Mikael Abrahamsson @ 2014-10-19 17:06 UTC (permalink / raw)
To: Per-Ola Stenborg; +Cc: linux-raid
In-Reply-To: <5443B55C.7000208@stenborg.me>
On Sun, 19 Oct 2014, Per-Ola Stenborg wrote:
> I compiled the latest mdadm v3.3.2 - 21st August 2014
> running
> mdadm --assemble --force /dev/md0 /dev/sd[bcde]
> outputs
> mdadm: /dev/sdb is busy - skipping
> mdadm: /dev/sdc is busy - skipping
> mdadm: /dev/sdd is busy - skipping
> mdadm: /dev/sde is busy - skipping
>
> Strange. What does this mean? Is it flaged as in use in the kernel? The
Stop the array before you try to start it again.
Also consider upgrading to a newer kernel if there is a backports one
(there should be for debian squeeze), a lot of things have happened since
2.6.32.
--
Mikael Abrahamsson email: swmike@swm.pp.se
^ permalink raw reply
* Re: Multiple drive failure after stupid mistake. Help needed
From: Per-Ola Stenborg @ 2014-10-19 19:00 UTC (permalink / raw)
To: Mikael Abrahamsson; +Cc: linux-raid
In-Reply-To: <alpine.DEB.2.02.1410191905190.30853@uplift.swm.pp.se>
Yes! It works! Thanks so much. Lets hope the sdc drive survives the
rebuild this time.
At least I got the opportunity to backup the 24GB important (not backed
up data).
The Linux raid usually works so well that you never have to worry. And
when things go wrong
you therefor never have the experience to help fix the problem.
Thanks again!
Best regards
Per-Ola Stenborg
Mikael Abrahamsson skrev 2014-10-19 19:06:
> On Sun, 19 Oct 2014, Per-Ola Stenborg wrote:
>
>> I compiled the latest mdadm v3.3.2 - 21st August 2014
>> running
>> mdadm --assemble --force /dev/md0 /dev/sd[bcde]
>> outputs
>> mdadm: /dev/sdb is busy - skipping
>> mdadm: /dev/sdc is busy - skipping
>> mdadm: /dev/sdd is busy - skipping
>> mdadm: /dev/sde is busy - skipping
>>
>> Strange. What does this mean? Is it flaged as in use in the kernel? The
>
> Stop the array before you try to start it again.
>
> Also consider upgrading to a newer kernel if there is a backports one
> (there should be for debian squeeze), a lot of things have happened
> since 2.6.32.
>
^ permalink raw reply
* How do I set 'write-behind' on existing array?
From: Hans Kraus @ 2014-10-20 12:33 UTC (permalink / raw)
To: linux-raid
Hi,
I want to expand an existing root array with an SSD. For that purpose I
try to set firstly 'write-behind' on that array. Afterwards I will add
the SSD, remove the HDs and re-add them with 'write-mostly'. On that
array is the root filesystem, therefore stopping is no option. In
>/home/kraush/work/mdadm/mdadm< is the latest mdadm version from git.
I tried:
-----------------------------------------------------------------------
root@elefant:/home/kraush/work/mdadm/mdadm# ./mdadm --manage
--write-behind=4096 /dev/md4
mdadm: :option --write-behind not valid in manage mode
root@elefant:/home/kraush/work/mdadm/mdadm# ./mdadm --grow
--write-behind=4096 /dev/md4
mdadm: no changes to --grow
-----------------------------------------------------------------------
What is the correct syntax?
Regards, Hans
^ permalink raw reply
* Kernel says there is not a valid superblock, but there is
From: Phillip Susi @ 2014-10-20 15:09 UTC (permalink / raw)
To: Linux RAID
When trying to assemble, the kernel complains:
md: md1 stopped.
md: sda2 does not have a valid v1.2 superblock, not importing!
md: md_import_device returned -22
md: sdb2 does not have a valid v1.2 superblock, not importing!
md: md_import_device returned -22
Yet the superblock looks perfectly fine according to mdadm -E:
/dev/sda2:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 34e89993:37821273:5498dc63:07233b2c
Name : devserv2:1
Creation Time : Mon Jun 16 11:24:00 2014
Raid Level : raid1
Raid Devices : 2
Avail Dev Size : 3900907520 (1860.10 GiB 1997.26 GB)
Array Size : 158334976 (151.00 GiB 162.14 GB)
Used Dev Size : 316669952 (151.00 GiB 162.14 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 40c38a87:88807f78:5bf71f34:4c9b2215
Update Time : Mon Oct 20 09:56:25 2014
Checksum : d2369656 - correct
Events : 303
Device Role : Active device 0
Array State : AA ('A' == active, '.' == missing)
/dev/sdb2:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 34e89993:37821273:5498dc63:07233b2c
Name : devserv2:1
Creation Time : Mon Jun 16 11:24:00 2014
Raid Level : raid1
Raid Devices : 2
Avail Dev Size : 3900907520 (1860.10 GiB 1997.26 GB)
Array Size : 158334976 (151.00 GiB 162.14 GB)
Used Dev Size : 316669952 (151.00 GiB 162.14 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 0fb85e8f:e697a9a0:7bd6eac4:03b8851d
Update Time : Mon Oct 20 10:08:35 2014
Checksum : 9b63a13c - correct
Events : 311
Device Role : Active device 1
Array State : .A ('A' == active, '.' == missing)
^ permalink raw reply
* question about MD raid rebuild performance degradation even with speed_limit_min/speed_limit_max set.
From: Jason Keltz @ 2014-10-20 16:19 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <5445332B.9060009@cse.yorku.ca>
Hi.
I'm creating a 22 x 2 TB SATA disk MD RAID10 on a new RHEL6 system. I've
experimented with setting "speed_limit_min" and "speed_limit_max" kernel
variables so that I get the best balance of performance during a RAID
rebuild of one of the RAID1 pairs. If, for example, I set
speed_limit_min AND speed_limit_max to 80000 then fail a disk when there
is no other disk activity, then I do get a rebuild rate of around 80
MB/s. However, if I then start up a write intensive operation on the MD
array (eg. a dd, or a mkfs on an LVM logical volume that is created on
that MD), then, my write operation seems to get "full power", and my
rebuild drops to around 25 MB/s. This means that the rebuild of my
RAID10 disk is going to take a huge amount of time (>12 hours!!!). When
I set speed_limit_min and speed_limit_max to the same value, am I not
guaranteeing the rebuild speed? Is this a bug that I should be reporting
to Red Hat, or a "feature"?
Thanks in advance for any help that you can provide...
Jason.
^ permalink raw reply
* Re: question about MD raid rebuild performance degradation even with speed_limit_min/speed_limit_max set.
From: Jason Keltz @ 2014-10-20 21:07 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <5445361E.3010503@cse.yorku.ca>
On 10/20/2014 12:19 PM, Jason Keltz wrote:
> Hi.
>
> I'm creating a 22 x 2 TB SATA disk MD RAID10 on a new RHEL6 system.
> I've experimented with setting "speed_limit_min" and "speed_limit_max"
> kernel variables so that I get the best balance of performance during
> a RAID rebuild of one of the RAID1 pairs. If, for example, I set
> speed_limit_min AND speed_limit_max to 80000 then fail a disk when
> there is no other disk activity, then I do get a rebuild rate of
> around 80 MB/s. However, if I then start up a write intensive
> operation on the MD array (eg. a dd, or a mkfs on an LVM logical
> volume that is created on that MD), then, my write operation seems to
> get "full power", and my rebuild drops to around 25 MB/s. This means
> that the rebuild of my RAID10 disk is going to take a huge amount of
> time (>12 hours!!!). When I set speed_limit_min and speed_limit_max to
> the same value, am I not guaranteeing the rebuild speed? Is this a bug
> that I should be reporting to Red Hat, or a "feature"?
>
> Thanks in advance for any help that you can provide...
>
> Jason.
I would like to add that I downloaded the latest version of Ubuntu, and
am running it on the same server with the same MD.
When I set speed_limit_min and speed_limit_max to 80000, I was able to
start two large dds on the md array, and the rebuild stuck at around 71
MB/s, which is close enough. This leads me to believe that the problem
above is probably a RHEL6 issue. However, after I stopped the two dd
operations, and raised both speed_limit_min and speed_limit_max to
120000, the rebuild stayed between 71-73 Mb/s for more than 10 minutes
.. now it seems to be at 100 MB/s... but doesn't seem to get any higher
(even though I had 120 MB/s and above on the RHEL system without any
load)... Hmm.
Jason.
^ permalink raw reply
* Re: Kernel says there is not a valid superblock, but there is
From: NeilBrown @ 2014-10-20 21:09 UTC (permalink / raw)
To: Phillip Susi; +Cc: Linux RAID
In-Reply-To: <544525C7.7000803@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2361 bytes --]
On Mon, 20 Oct 2014 11:09:59 -0400 Phillip Susi <phillsusi@gmail.com> wrote:
> When trying to assemble, the kernel complains:
Which kernel?
uname -a
and may as well add
mdadm -V
as well.
NeilBrown
>
> md: md1 stopped.
> md: sda2 does not have a valid v1.2 superblock, not importing!
> md: md_import_device returned -22
> md: sdb2 does not have a valid v1.2 superblock, not importing!
> md: md_import_device returned -22
>
> Yet the superblock looks perfectly fine according to mdadm -E:
>
> /dev/sda2:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x0
> Array UUID : 34e89993:37821273:5498dc63:07233b2c
> Name : devserv2:1
> Creation Time : Mon Jun 16 11:24:00 2014
> Raid Level : raid1
> Raid Devices : 2
>
> Avail Dev Size : 3900907520 (1860.10 GiB 1997.26 GB)
> Array Size : 158334976 (151.00 GiB 162.14 GB)
> Used Dev Size : 316669952 (151.00 GiB 162.14 GB)
> Data Offset : 262144 sectors
> Super Offset : 8 sectors
> State : clean
> Device UUID : 40c38a87:88807f78:5bf71f34:4c9b2215
>
> Update Time : Mon Oct 20 09:56:25 2014
> Checksum : d2369656 - correct
> Events : 303
>
>
> Device Role : Active device 0
> Array State : AA ('A' == active, '.' == missing)
>
> /dev/sdb2:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x0
> Array UUID : 34e89993:37821273:5498dc63:07233b2c
> Name : devserv2:1
> Creation Time : Mon Jun 16 11:24:00 2014
> Raid Level : raid1
> Raid Devices : 2
>
> Avail Dev Size : 3900907520 (1860.10 GiB 1997.26 GB)
> Array Size : 158334976 (151.00 GiB 162.14 GB)
> Used Dev Size : 316669952 (151.00 GiB 162.14 GB)
> Data Offset : 262144 sectors
> Super Offset : 8 sectors
> State : clean
> Device UUID : 0fb85e8f:e697a9a0:7bd6eac4:03b8851d
>
> Update Time : Mon Oct 20 10:08:35 2014
> Checksum : 9b63a13c - correct
> Events : 311
>
>
> Device Role : Active device 1
> Array State : .A ('A' == active, '.' == missing)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: How do I set 'write-behind' on existing array?
From: NeilBrown @ 2014-10-20 21:14 UTC (permalink / raw)
To: Hans Kraus; +Cc: linux-raid
In-Reply-To: <5445011B.8040008@hanswkraus.com>
[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]
On Mon, 20 Oct 2014 14:33:31 +0200 Hans Kraus <hans@hanswkraus.com> wrote:
> Hi,
>
> I want to expand an existing root array with an SSD. For that purpose I
> try to set firstly 'write-behind' on that array. Afterwards I will add
> the SSD, remove the HDs and re-add them with 'write-mostly'. On that
> array is the root filesystem, therefore stopping is no option. In
> >/home/kraush/work/mdadm/mdadm< is the latest mdadm version from git.
> I tried:
> -----------------------------------------------------------------------
> root@elefant:/home/kraush/work/mdadm/mdadm# ./mdadm --manage
> --write-behind=4096 /dev/md4
> mdadm: :option --write-behind not valid in manage mode
> root@elefant:/home/kraush/work/mdadm/mdadm# ./mdadm --grow
> --write-behind=4096 /dev/md4
> mdadm: no changes to --grow
> -----------------------------------------------------------------------
> What is the correct syntax?
>
Not quite.
"write-behind" is a property of the bitmap.
To enable write-behind on an array you first need to remove the bitmap if
there is one
mdadm /dev/md4 --grow --bitmap=none
then add a new bitmap with the required property
mdadm /dev/md4 --grow --bitmap=internal --write-behind=4096
NeilBrown
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [patch] dm raid: pointer math issue in super_sync()
From: Dan Carpenter @ 2014-10-21 12:43 UTC (permalink / raw)
To: Alasdair Kergon
Cc: Mike Snitzer, dm-devel, Neil Brown, linux-raid, kernel-janitors
"sb" is a dm_raid_superblock struct pointer so the pointer math doesn't
work and we will end up corrupting memory.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/md/dm-raid.c b/drivers/md/dm-raid.c
index b802644..a7cb9dd 100644
--- a/drivers/md/dm-raid.c
+++ b/drivers/md/dm-raid.c
@@ -826,7 +826,7 @@ static void super_sync(struct mddev *mddev, struct md_rdev *rdev)
test_bit(Faulty, &(rs->dev[i].rdev.flags)))
failed_devices |= (1ULL << i);
- memset(sb + sizeof(*sb), 0, rdev->sb_size - sizeof(*sb));
+ memset(sb + 1, 0, rdev->sb_size - sizeof(*sb));
sb->magic = cpu_to_le32(DM_RAID_MAGIC);
sb->features = cpu_to_le32(0); /* No features yet */
^ permalink raw reply related
* Re: [patch] DM RAID: fix a couple integer overflows
From: Dan Carpenter @ 2014-10-21 12:43 UTC (permalink / raw)
To: Alasdair Kergon
Cc: Mike Snitzer, dm-devel, Neil Brown, linux-raid, kernel-janitors
In-Reply-To: <20140529082323.GA9209@mwanda>
These array overflows are still there in linux-next.
regards,
dan carpenter
On Thu, May 29, 2014 at 11:23:23AM +0300, Dan Carpenter wrote:
> My static checker complains that if "num_raid_params" is UINT_MAX then
> the "if (num_raid_params + 1 > argc) {" check doesn't work as intended.
>
> The other change is that I moved the "if (argc != (num_raid_devs * 2))"
> condition forward a few lines so it was before the call to
> context_alloc(). If we had an integer overflow inside that function
> then it would lead to an immediate crash.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> Static checker stuff. Not tested.
>
> diff --git a/drivers/md/dm-raid.c b/drivers/md/dm-raid.c
> index 4880b69..e0d53fe 100644
> --- a/drivers/md/dm-raid.c
> +++ b/drivers/md/dm-raid.c
> @@ -1189,7 +1189,7 @@ static int raid_ctr(struct dm_target *ti, unsigned argc, char **argv)
> argv++;
>
> /* Skip over RAID params for now and find out # of devices */
> - if (num_raid_params + 1 > argc) {
> + if (num_raid_params >= argc) {
> ti->error = "Arguments do not agree with counts given";
> return -EINVAL;
> }
> @@ -1200,6 +1200,12 @@ static int raid_ctr(struct dm_target *ti, unsigned argc, char **argv)
> return -EINVAL;
> }
>
> + argc -= num_raid_params + 1; /* +1: we already have num_raid_devs */
> + if (argc != (num_raid_devs * 2)) {
> + ti->error = "Supplied RAID devices does not match the count given";
> + return -EINVAL;
> + }
> +
> rs = context_alloc(ti, rt, (unsigned)num_raid_devs);
> if (IS_ERR(rs))
> return PTR_ERR(rs);
> @@ -1208,16 +1214,8 @@ static int raid_ctr(struct dm_target *ti, unsigned argc, char **argv)
> if (ret)
> goto bad;
>
> - ret = -EINVAL;
> -
> - argc -= num_raid_params + 1; /* +1: we already have num_raid_devs */
> argv += num_raid_params + 1;
>
> - if (argc != (num_raid_devs * 2)) {
> - ti->error = "Supplied RAID devices does not match the count given";
> - goto bad;
> - }
> -
> ret = dev_parms(rs, argv);
> if (ret)
> goto bad;
^ permalink raw reply
* Re: dm raid: pointer math issue in super_sync()
From: Mike Snitzer @ 2014-10-21 12:48 UTC (permalink / raw)
To: Dan Carpenter
Cc: Alasdair Kergon, dm-devel, Neil Brown, linux-raid,
kernel-janitors, Heinz Mauelshagen
In-Reply-To: <20141021124336.GA20791@mwanda>
On Tue, Oct 21 2014 at 8:43am -0400,
Dan Carpenter <dan.carpenter@oracle.com> wrote:
> "sb" is a dm_raid_superblock struct pointer so the pointer math doesn't
> work and we will end up corrupting memory.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/md/dm-raid.c b/drivers/md/dm-raid.c
> index b802644..a7cb9dd 100644
> --- a/drivers/md/dm-raid.c
> +++ b/drivers/md/dm-raid.c
> @@ -826,7 +826,7 @@ static void super_sync(struct mddev *mddev, struct md_rdev *rdev)
> test_bit(Faulty, &(rs->dev[i].rdev.flags)))
> failed_devices |= (1ULL << i);
>
> - memset(sb + sizeof(*sb), 0, rdev->sb_size - sizeof(*sb));
> + memset(sb + 1, 0, rdev->sb_size - sizeof(*sb));
>
> sb->magic = cpu_to_le32(DM_RAID_MAGIC);
> sb->features = cpu_to_le32(0); /* No features yet */
Not following... sizeof(*sb) != sizeof(sb). So I'm not seeing a
problem.
Nor am I seeing how you think sb + 1 is equivalent to what Heinz
intended (zero the memory following the sizeof(struct dm_raid_superblock)).
^ permalink raw reply
* Re: dm raid: pointer math issue in super_sync()
From: Dan Carpenter @ 2014-10-21 12:57 UTC (permalink / raw)
To: Mike Snitzer
Cc: Alasdair Kergon, dm-devel, Neil Brown, linux-raid,
kernel-janitors, Heinz Mauelshagen
In-Reply-To: <20141021124826.GC20625@redhat.com>
On Tue, Oct 21, 2014 at 08:48:26AM -0400, Mike Snitzer wrote:
> > - memset(sb + sizeof(*sb), 0, rdev->sb_size - sizeof(*sb));
> > + memset(sb + 1, 0, rdev->sb_size - sizeof(*sb));
> >
> > sb->magic = cpu_to_le32(DM_RAID_MAGIC);
> > sb->features = cpu_to_le32(0); /* No features yet */
>
> Not following... sizeof(*sb) != sizeof(sb). So I'm not seeing a
> problem.
>
> Nor am I seeing how you think sb + 1 is equivalent to what Heinz
> intended (zero the memory following the sizeof(struct dm_raid_superblock)).
It's pointer math.
sizeof(*sb) is 512.
"sb + sizeof(*sb)" is the same as (void *)sb + 512 * 512.
"sb + 1" is the same as (void *)sb + 512.
regards,
dan carpenter
^ permalink raw reply
* Re: dm raid: pointer math issue in super_sync()
From: Mike Snitzer @ 2014-10-21 13:25 UTC (permalink / raw)
To: Dan Carpenter
Cc: Heinz Mauelshagen, kernel-janitors, linux-raid, dm-devel,
Alasdair Kergon
In-Reply-To: <20141021125729.GC26918@mwanda>
On Tue, Oct 21 2014 at 8:57am -0400,
Dan Carpenter <dan.carpenter@oracle.com> wrote:
> On Tue, Oct 21, 2014 at 08:48:26AM -0400, Mike Snitzer wrote:
> > > - memset(sb + sizeof(*sb), 0, rdev->sb_size - sizeof(*sb));
> > > + memset(sb + 1, 0, rdev->sb_size - sizeof(*sb));
> > >
> > > sb->magic = cpu_to_le32(DM_RAID_MAGIC);
> > > sb->features = cpu_to_le32(0); /* No features yet */
> >
> > Not following... sizeof(*sb) != sizeof(sb). So I'm not seeing a
> > problem.
> >
> > Nor am I seeing how you think sb + 1 is equivalent to what Heinz
> > intended (zero the memory following the sizeof(struct dm_raid_superblock)).
>
> It's pointer math.
Yes, I see that now..
> sizeof(*sb) is 512.
>
> "sb + sizeof(*sb)" is the same as (void *)sb + 512 * 512.
> "sb + 1" is the same as (void *)sb + 512.
Actually, Heinz removed the 452 bytes of padding from struct
dm_raid_superblock, so it is more like:
sizeof(*sb) == sizeof(struct dm_raid_super_block) == 60
"sb + sizeof(*sb)" is the same as (void *)sb + 60 * 60
"sb + 1" is the same as (void *)sb + 60.
But regardless, your broader point on the math stands. I'll get this
fixed up, thanks!
Mike
^ permalink raw reply
* Re: Kernel says there is not a valid superblock, but there is
From: Phillip Susi @ 2014-10-21 14:07 UTC (permalink / raw)
To: NeilBrown; +Cc: Linux RAID
In-Reply-To: <20141021080937.69aaf214@notabene.brown>
On 10/20/2014 5:09 PM, NeilBrown wrote:
> On Mon, 20 Oct 2014 11:09:59 -0400 Phillip Susi <phillsusi@gmail.com> wrote:
>
>> When trying to assemble, the kernel complains:
>
> Which kernel?
> uname -a
> and may as well add
> mdadm -V
>
> as well.
uname -a
Linux hyper1 3.13.0-35-generic #62-Ubuntu SMP Fri Aug 15 01:58:42 UTC
2014 x86_64 x86_64 x86_64 GNU/Linux
mdadm -V
mdadm - v3.2.5 - 18th May 2012
I managed to hack around with dmsetup to create a linear mapping to the
correct data offset that mdadm -E listed and recover my data and blow
away and recreate the array. I saved a dump of the superblock if you
want them for debugging.
^ permalink raw reply
* Problem with a dgaded array (not related to my last question)
From: Hans Kraus @ 2014-10-21 20:22 UTC (permalink / raw)
To: linux-raid
Hi,
At first: thanks Neil for your answer about tbe bitmap question.
I have another problem: I tried to rebuild an array, raid 6,
with two drives missing of five. Adding a fourth drive worked
well. But not adding a fith drive. I got following messages:
----------------------------------------------------------------
root@nashorn:/home/kraush/work/mdadm# ./mdadm --stop /dev/md126
mdadm: stopped /dev/md126
root@nashorn:/home/kraush/work/mdadm# ./mdadm --assemble --update=bbl
/dev/md126
mdadm: /dev/md126 has been started with 4 drives (out of 5).
root@nashorn:/home/kraush/work/mdadm# mdadm --add /dev/md126 /dev/sdj1
mdadm: add new device failed for /dev/sdj1 as 7: Invalid argument
root@nashorn:/home/kraush/work/mdadm# ./mdadm --stop /dev/md126
mdadm: stopped /dev/md126
root@nashorn:/home/kraush/work/mdadm# ./mdadm --assemble --update=bbl
/dev/md126
mdadm: superblock on /dev/sdj1 doesn't match others - assembly aborted
root@nashorn:/home/kraush/work/mdadm# ./mdadm --assemble --update=bbl
/dev/md126
mdadm: superblock on /dev/sdj1 doesn't match others - assembly aborted
root@nashorn:/home/kraush/work/mdadm# ./mdadm --assemble /dev/md126
mdadm: superblock on /dev/sdj1 doesn't match others - assembly aborted
root@nashorn:/home/kraush/work/mdadm# ./mdadm --detail /dev/sdh4
mdadm: /dev/sdh4 does not appear to be an md device
root@nashorn:/home/kraush/work/mdadm# mdadm --assemble /dev/md126
mdadm: superblock on /dev/sdj1 doesn't match others - assembly aborted
----------------------------------------------------------------
How do I get my array back up and the fith drive added? The size of the
drive partition sdj1 should be sufficient for the array.
Thanks in advance, Hans
PS: I do know the names of the other partitions in the array but not
their position.
^ permalink raw reply
* Re: "bitmap file is out of date, doing full recovery"
From: Alexander Lyakas @ 2014-10-23 16:04 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <20141013092426.5ea1288d@notabene.brown>
Hi Neil,
I found at least one way of this happening. The problem is that in
md_update_sb() we allow to decrease the event count:
/* If this is just a dirty<->clean transition, and the array is clean
* and 'events' is odd, we can roll back to the previous clean state */
if (nospares
&& (mddev->in_sync && mddev->recovery_cp == MaxSector)
&& mddev->can_decrease_events
&& mddev->events != 1) {
mddev->events--;
mddev->can_decrease_events = 0;
Then we call bitmap_update_sb(). If we crash after we update (the
first or all of) bitmap superblocks, then after reboot, we will see
that bitmap event count is less than MD superblock event count. Then
we decide to do full resync.
This can be easily reproduced by hacking bitmap_update_sb() to call
BUG(), after it calls write_page() in case event count was decreased.
Why we are decreasing the event count??? Can we always increase it?
u64 is a lot to increase...
Some other doubt that I have is that bitmap_unplug() and
bitmap_daemon_work() call write_page() on page index=0. This page
contains both the superblock and also some dirty bits (could not we
waste 4KB on bitmap superblock???). I am not sure, but I wonder
whether this call can race with md_update_sb (which explicitly calls
bitmap_update_sb), and somehow write the outdated superblock, after
bitmap_update_sb has completed writing it.
Yet another suspect is when loading the bitmap we basically load it
from the first up-to-date drive. Maybe we should have scanned all the
bitmap superblocks, and selected one that has the higher event count
(although as we saw "higher" does not necessarily mean "more
up-to-date").
Anyways, back to decrementing the event count. Do you see any issue
with not doing this and always incrementing?
Thanks,
Alex.
On Mon, Oct 13, 2014 at 1:24 AM, NeilBrown <neilb@suse.de> wrote:
> On Sun, 12 Oct 2014 21:03:57 +0300 Alexander Lyakas <alex.bolshoy@gmail.com>
> wrote:
>
>> Hi Neil,
>> after a 2-drive raid1 unclean shutdown (crash actually), after reboot, we had:
>>
>> md/raid1:md24: not clean -- starting background reconstruction
>> md/raid1:md24: active with 2 out of 2 mirrors
>> md24: bitmap file is out of date (41 < 42) -- forcing full recovery
>> created bitmap (22 pages) for device md24
>> md24: bitmap file is out of date, doing full recovery
>> md24: bitmap initialized from disk: read 2 pages, set 44667 of 44667 bits
>>
>> The superblock of both drives had event count = 42:
>> (this is a custom mdadm with some added prints):
>> mdadm: looking for devices for /dev/md24
>> mdadm: [/dev/md24] /dev/dm-205: slot=0, events=42,
>> recovery_offset=N/A, resync_offset=0, comp_size=5854539776
>> mdadm: [/dev/md24] /dev/dm-206: slot=1, events=42,
>> recovery_offset=N/A, resync_offset=0, comp_size=5854539776
>>
>> But the bitmap superblock had lower event count, which resulted in a
>> full resync. Is this an expected scenario in case of a crash?
>
> No.
>
>>
>> For example in md_update_sb, first we call
>> bitmap_update_sb(mddev->bitmap), which synchronously updates the
>> bitmap, and only afterwards we go ahead and update our superblocks. So
>> in this case, the bitmap should not have a lower event count. Is there
>> some other valid scenario, in which the bitmap can remain with a lower
>> event count?
>
> Not that I can think of.
>
>
> NeilBrown
>
>>
>> Thanks,
>> Alex.
>
^ permalink raw reply
* Help with raid1 to raid5 reshape after crash
From: shane-kernel @ 2014-10-24 23:38 UTC (permalink / raw)
To: linux-raid
Hello all,
I was converting from a 2 disk raid1 array to a 4 disk raid5 (3+1s) in preparation to convert to a four disk raid6. I added the two additional component devices and did a:
Mdadm --grow /dev/md1 --level 5 --raid-devices 3
And off it went. I had a power failure a good ways in and now when the system boots, it runs the array, attempts to restart the reshape then disk IO locks up hard.
I figure it is disk IO rather than a complete system lockup as I have about 10 seconds of interactive shell before it locks. If I enter a dmesg command then that command will succeed. After the lockup, subsequent dmesg commands succeed (dmesg is in cache) but another command such as ls will lock up. Cat /proc/mdstat shows the reshape in progress but it doesn't actually progress beyond the point at which the system locks.
Booting from a USB stick, I tried:
Mdadm --assemble --readonly
But that too hangs the system.
Do I have any recourse beyond just recreating the array and restoring from backup? Kernel is 3.16.
Thanks,
Shane
Mdadm -D
^ permalink raw reply
* [PATCH] Grow: fix resize of array component size to > 32bits
From: Justin Maggard @ 2014-10-25 0:55 UTC (permalink / raw)
To: linux-raid; +Cc: Justin Maggard
If the request --size to --grow an array to is larger
than 32bits, then mdadm may make the wrong choice and
use ioctl instead of setting component_size via sysfs
and the change is ignored.
Instead of using casts to check for a 32-bit overflow,
just check for set bits outside of INT32_MAX.
---
Grow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Grow.c b/Grow.c
index a9c8589..a614102 100644
--- a/Grow.c
+++ b/Grow.c
@@ -1818,7 +1818,7 @@ int Grow_reshape(char *devname, int fd,
if (s->size == MAX_SIZE)
s->size = 0;
array.size = s->size;
- if (array.size != (signed)s->size) {
+ if (s->size & ~INT32_MAX) {
/* got truncated to 32bit, write to
* component_size instead
*/
--
1.9.1
^ permalink raw reply related
* storage with "very high Average Read/Write Request Time"
From: Peter Grandi @ 2014-10-25 14:47 UTC (permalink / raw)
To: Linux RAID; +Cc: quanjun hu, Stan Hoeppner
In-Reply-To: <54442A48.6050503@hardwarefreak.com>
I am copying here (without endorsement or comment) some extracts by
different people from a thread in the XFS mailing list that seems mostly
about RAID tuning:
http://article.gmane.org/gmane.comp.file-systems.xfs.general/65029
>>> Hi, I am using xfs on a raid 5 (~100TB) and put log on external ssd
>>> device, the mount information is: /dev/sdc on
>>> /data/fhgfs/fhgfs_storage type xfs
>>> (rw,relatime,attr2,delaylog,logdev=/dev/sdb1,sunit=512,swidth=15872,noquota).
>>> when doing only reading / only writing , the speed is very
>>> fast(~1.5G), but when do both the speed is very slow (100M), and
>>> high r_await(160) and w_await(200000).
>>> 1. how can I reduce average request time?
>>> 2. can I use ssd as write/read cache for xfs?
http://article.gmane.org/gmane.comp.file-systems.xfs.general/65034
>> There is a ratio of 31 (thirty one) between 'swidth' and 'sunit' and
>> assuming that this reflects the geometry of the RAID5 set and given
>> commonly available disk sizes it can be guessed that with amazing
>> "bravery" someone has configured a RAID5 out of 32 (thirty two) high
>> capacity/low IOPS 3TB drives, or something similar. It is even
>> "braver" than that: if the device name "/data/fhgfs/fhgfs_storage" is
>> dedscriptive, this "brave" RAID5 set is supposed to hold the object
>> storage layer of a BeeFS highly parallel filesystem, and therefore
>> will likely have mostly-random accesses. This issue should be moved
>> to the 'linux-raid' mailing list as from the reported information it
>> has nothing to do with XFS.
http://article.gmane.org/gmane.comp.file-systems.xfs.general/65036
> You apparently have 31 effective SATA 7.2k RPM spindles with 256 KiB
> chunk, 7.75 MiB stripe width, in RAID5. That should yield 3-4.6 GiB/s
> of streaming throughput assuming no cable, expander, nor HBA
> limitations. You're achieving only 1/3rd to 1/2 of this. Which
> hardware RAID controller is this? What are the specs? Cache RAM,
> host and back end cable count and type?
> When you say read or write is fast individually, but read+write is
> slow, what types of files are you reading and writing, and how many in
> parallel? This combined pattern is likely the cause of the slowdown
> due to excessive seeking in the drives. As others mentioned this isn't
> an XFS problem.
> The problem is that your RAID geometry doesn't match your workload.
> Your very wide parity stripe is apparently causing excessive seeking
> with your read+write workload due to read-modify-write operations. To
> mitigate this, and to increase resiliency, you should switch to RAID6
> with a smaller chunk. If you need maximum capacity make a single
> RAID6 array with 16 KiB chunk size. This will yield a 496 KiB stripe
> width, increasing the odds that all writes are a full stripe, and
> hopefully eliminating much of the RMW problem.
> A better option might be making three 10 drive RAID6 arrays (two
> spares) with 32 KiB chunk, 256 KiB stripe width, and concatenating
> the 3 arrays with mdadm --linear. You'd have 24 spindles of capacity
> and throughput instead of 31, but no more RMW operations, or at least
> very few. You'd format the linear md device with
> mkfs.xfs -d su=32k,sw=8 /dev/mdX
> As long as your file accesses are spread fairly evenly across at
> least 3 directories you should achieve excellent parallel throughput,
> though single file streaming throughput will peak at 800-1200 MiB/s,
> that of 8 drives. With a little understanding of how this setup
> works, you can write two streaming files and read a third without any
> of the 3 competing with one another for disk seeks/bandwidth--which
> is your current problem. Or you could do one read and one write to
> each of 3 directories, and no pair of two would interfere with the
> other pairs. Scale up from here.
> Basically what we're doing is isolating each RAID LUN into a set of
> directories. When you write to one of those directories the file
> goes into only one of the 3 RAID arrays. Doing this isolates RMWs
> for a given write to only a subset of your disks, and minimizes the
> amount of seeks generated by parallel accesses.
^ 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