* Re: check which disk is a problem
From: John Robinson @ 2011-05-19 11:47 UTC (permalink / raw)
To: Pol Hallen; +Cc: linux-raid
In-Reply-To: <201105191234.39391.raid1@fuckaround.org>
On 19/05/2011 11:34, Pol Hallen wrote:
> Hi folks :-)
>
> I've a raid6 sw on debian stable and a problem (!):
>
> cat /proc/mdstat
>
> Personalities : [raid6] [raid5] [raid4]
> md0 : active raid6 sdc1[0] sdf1[5] sdg1[4] sdh1[3] sdd1[1]
> 5860543744 blocks level 6, 64k chunk, algorithm 2 [6/5] [UU_UUU]
>
> so, I think /dev/sde is corrupted disk
>
> How identify this disk?
>
> blkid:
>
> /dev/sdc1: UUID="9bd6372e-e2ea-b1d5-d2bd-c3cbad12f41d"
> TYPE="linux_raid_member"
> /dev/sdd1: UUID="9bd6372e-e2ea-b1d5-d2bd-c3cbad12f41d"
> TYPE="linux_raid_member"
> /dev/sde1: UUID="9bd6372e-e2ea-b1d5-d2bd-c3cbad12f41d"
> TYPE="linux_raid_member"
> /dev/sdf1: UUID="9bd6372e-e2ea-b1d5-d2bd-c3cbad12f41d"
> TYPE="linux_raid_member"
> /dev/sdg1: UUID="9bd6372e-e2ea-b1d5-d2bd-c3cbad12f41d"
> TYPE="linux_raid_member"
> /dev/sdh1: UUID="9bd6372e-e2ea-b1d5-d2bd-c3cbad12f41d"
> TYPE="linux_raid_member"
>
> has same uuid, why?
>
> and now how can I resolve?
You can find out which discs/partitions are meant to be in the array with
mdadm -D /dev/md0
and if as it appears there's one missing you can see what state it's in with
mdadm -E /dev/sde1
(or similar).
You should look through your logs to see if you can see what happened to
it. You should also check its SMART status with e.g.
smartctl -a /dev/sde
If it's not dead or dying, you may be able to re-add it with
mdadm /dev/md0 --add /dev/sde1
Hope this helps!
Cheers,
John.
^ permalink raw reply
* HBA Adaptor advice
From: Ed W @ 2011-05-19 12:26 UTC (permalink / raw)
To: linux-raid
Hi, following on from a recent thread, can folks with decent multi-port
HBA adaptors please chime in with some model numbers of known decent
adaptors please?
The required use is to grow from currently 8 ish drives to perhaps 12-24
drives per machine. (It partitions out as: one or more RAID6 arrays for
data, plus a couple of backup drives)
Ideally I would like a controller with writeback cache and BBU since
whilst this office machine is likely quite underused, for any sensible
amount of IO (some of the other machines we might upgrade) this seems to
give a 10-100x increase in IOPs? For the moment it's just a nice to
have though
I only intend to use linux software raid, so any onboard raid
functionality is just a liability. Budget is either low £100 ish for
multi-port HBAs without cache, up to £1000 ish for 16-24 port high
performance cache controllers:
So far I saw recommendations for:
- LSI 1068E (SuperMicro 3081E) (8 port 3Gb)
- LSI 9211-8i (8 port 6Gb)
And to avoid:
- Marvel controllers?
- Areca with marvel controllers?
- AOC-SASLP-MV8
these any good?
- LSI MegaRAID 9280-24i4e
- Areca ARC-1880ix-24
I'm completely ignorant of the current state of adaptors today:
- Are there any bargains to be had in the lower end 8-24 port category
(ie come up frequently as ebay specials and aren't locked to special
DELL-only disks, etc?)
- Cable management. Are there any backplanes for retro fitting into
desktop chassis (5 1/4 bays say?) which take single (8087?) connectors?
At the moment I just need to refresh our office server (10-12 disks
including back drives) and we need something compact and quiet so
looking for compact tower chassis options. I'm also looking at adding
more storage into our datacenter racks though, so interested in a
shopping list of reliable higher performance options?
Please add suggestions for good value, reliable controllers known to
work well with linux
Thanks
Ed W
--
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: HBA Adaptor advice
From: Roman Mamedov @ 2011-05-19 12:36 UTC (permalink / raw)
To: Ed W; +Cc: linux-raid
In-Reply-To: <4DD50C89.8060006@wildgooses.com>
[-- Attachment #1: Type: text/plain, Size: 577 bytes --]
On Thu, 19 May 2011 13:26:49 +0100
Ed W <lists@wildgooses.com> wrote:
> Hi, following on from a recent thread, can folks with decent multi-port
> HBA adaptors please chime in with some model numbers of known decent
> adaptors please?
Here is a useful link for you: http://blog.zorinaq.com/?e=10
> And to avoid:
> - Marvel controllers?
There are two kinds (families?) of Marvell SATA chips, and those using the
"sata_mv" module do work fine. It seems like all the complaints are directed
at the other kind, supported via "mvsas".
--
With respect,
Roman
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: HBA Adaptor advice
From: Mathias Burén @ 2011-05-19 12:43 UTC (permalink / raw)
To: Roman Mamedov; +Cc: Ed W, linux-raid
In-Reply-To: <20110519183608.2c377538@natsu>
On 19 May 2011 13:36, Roman Mamedov <rm@romanrm.ru> wrote:
> On Thu, 19 May 2011 13:26:49 +0100
> Ed W <lists@wildgooses.com> wrote:
>
>> Hi, following on from a recent thread, can folks with decent multi-port
>> HBA adaptors please chime in with some model numbers of known decent
>> adaptors please?
>
> Here is a useful link for you: http://blog.zorinaq.com/?e=10
>
>> And to avoid:
>> - Marvel controllers?
>
> There are two kinds (families?) of Marvell SATA chips, and those using the
> "sata_mv" module do work fine. It seems like all the complaints are directed
> at the other kind, supported via "mvsas".
>
> --
> With respect,
> Roman
>
I have to chime in; I do have this one:
05:00.0 SCSI storage controller: HighPoint Technologies, Inc.
RocketRAID 230x 4 Port SATA-II Controller (rev 02)
Which uses the sata_mv module. From dmesg:
[ 1.062151] sata_mv: Highpoint RocketRAID BIOS CORRUPTS DATA on all
attached drives, regardless of if/how they are configured. BEWARE!
[ 1.062156] sata_mv: For data safety, do not use sectors 8-9 on
"Legacy" drives, and avoid the final two gigabytes on all RocketRAID
BIOS initialized drives.
So stay away from RocketRAID :-) (I only use it as a HBA)
Cheers,
/M
^ permalink raw reply
* Re: HBA Adaptor advice
From: Michael Sallaway @ 2011-05-19 14:06 UTC (permalink / raw)
To: Ed W; +Cc: linux-raid
In-Reply-To: <4DD50C89.8060006@wildgooses.com>
On 19/05/2011 10:26 PM, Ed W wrote:
> So far I saw recommendations for:
>
> - LSI 1068E (SuperMicro 3081E) (8 port 3Gb)
I'm using one of these, and it's working great. It's a Supermicro
AOC-USASLP-L8i. I'm using all 8 ports, and another 4 drives on the
onboard controller.
Note, however, that I was first running a slightly older kernel, and it
didn't work (bus errors, lots of weird stuff happening), so I
temporarily gave up on it -- I believe it was either 2.6.31 or 2.6.32
(Ubuntu 10.04 LTS). However, due to a need for something else, I
upgraded to a 2.6.35 kernel, and it started working fine with that
kernel. Been using it for ~9 months perfectly fine.
Cheers,
Michael
^ permalink raw reply
* Re: check which disk is a problem
From: Pol Hallen @ 2011-05-19 14:17 UTC (permalink / raw)
To: John Robinson; +Cc: linux-raid
In-Reply-To: <4DD50356.50403@anonymous.org.uk>
> You should look through your logs to see if you can see what happened to
> it. You should also check its SMART status with e.g.
> smartctl -a /dev/sde
ok thanks :-)
My fear is also this:
May 19 11:02:47 lorna kernel: [220141.636031] ata9: SATA link up 1.5 Gbps
(SStatus 113 SControl 310)
May 19 11:02:47 lorna kernel: [220141.708820] ata9.00: configured for UDMA/33
May 19 11:02:47 lorna kernel: [220141.710840] ata9: EH complete
May 19 11:03:13 lorna kernel: [220167.526518] ata9: exception Emask 0x10 SAct
0x0 SErr 0x10000 action 0xe frozen
May 19 11:03:13 lorna kernel: [220167.528619] ata9: irq_stat 0x00400000, PHY
RDY changed
May 19 11:03:13 lorna kernel: [220167.530664] ata9: SError: { PHYRdyChg }
May 19 11:03:13 lorna kernel: [220167.532735] ata9: hard resetting link
May 19 11:03:14 lorna kernel: [220168.263086] EXT4-fs error (device md0):
ext4_ext_search_right: bad header/extent i
n inode #260441748: invalid extent entries - magic f30a, entries 125, max 340
(340), depth 0(0)
May 19 11:03:14 lorna kernel: [220168.464708] EXT4-fs (md0): delayed block
allocation failed for inode 260441748 at
logical offset 130984 with max blocks 1 with error -5
May 19 11:03:14 lorna kernel: [220168.467005] This should not happen!! Data
will be lost
this shouldn't happen or no? On raid6 I've only a disk with problem.. or is it
a ext4 problem?
I use default debian kernel 2.6.32-5-686-bigmem with debian stable.
Thanks!
Pol
^ permalink raw reply
* Re: HBA Adaptor advice
From: Thomas Harold @ 2011-05-19 19:10 UTC (permalink / raw)
To: Ed W; +Cc: linux-raid
In-Reply-To: <4DD50C89.8060006@wildgooses.com>
On 5/19/2011 8:26 AM, Ed W wrote:
> Hi, following on from a recent thread, can folks with decent
> multi-port HBA adaptors please chime in with some model numbers of
> known decent adaptors please?
>
> The required use is to grow from currently 8 ish drives to perhaps
> 12-24 drives per machine. (It partitions out as: one or more RAID6
> arrays for data, plus a couple of backup drives)
>
> Ideally I would like a controller with writeback cache and BBU since
> whilst this office machine is likely quite underused, for any
> sensible amount of IO (some of the other machines we might upgrade)
> this seems to give a 10-100x increase in IOPs? For the moment it's
> just a nice to have though
>
> I only intend to use linux software raid, so any onboard raid
> functionality is just a liability. Budget is either low £100 ish for
> multi-port HBAs without cache, up to £1000 ish for 16-24 port high
> performance cache controllers:
I've been using a SuperMicro AOC-SASLP-MV8 (which is on your avoid
list), which reports itself as:
class: SCSI
bus: PCI
detached: 0
driver: mvsas
desc: "Marvell Technology Group Ltd. MV64460/64461/64462 System
Controller, Revision B"
vendorId: 11ab
deviceId: 6485
subVendorId: 15d9
subDeviceId: 0500
I've had it about 6 months at this point with SATA drives hooked up to
it. The issues that I've had with it dropping disks from the 6-disk
RAID-10 array on CentOS 5.5 / 5.6 can probably be traced to:
Not using enterprise grade SATA disks (as the consumer brand takes too
long to timeout on a bad seek, and mdadm dropped it from the array).
Possibly combined with using a really inexpensive set of removable drive
trays. There were a lot of times after the weekly resync where the
entire array went offline due to multiple drives being dropped.
Under normal operation it reads/writes to the disks fine and works fine
as a controller. Since this is my own personal server, I have not
tested it with good SAS disks or enterprise SATAs and good drive
enclosures. I've since switched over to just hooking up a pair of RAID1
arrays to it with a direct connect from the card to the drives (no
removable trays), but I don't have enough time on the new setup to say
that the problem is permanently fixed yet.
The card is inexpensive, which is a plus. It's a PCIe x4 card. I don't
know whether it would be better behaved with a better class of disks /
enclosures.
--
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: HBA Adaptor advice
From: Brad Campbell @ 2011-05-19 21:07 UTC (permalink / raw)
To: RAID Linux
In-Reply-To: <4DD50C89.8060006@wildgooses.com>
On 19/05/11 20:26, Ed W wrote:
> Please add suggestions for good value, reliable controllers known to
> work well with linux
I have three of these :
http://www.startech.com/product/PEXSATA24E-2-Port-eSATA-4-Port-SATA-PCI-Express-x4-SATA-Controller-Adapter-Card-PCIe
and 4 of these :
http://www.ebay.com.au/itm/IBM-M1015-46M0861-ServeRAID-M1015-SAS-SATA-Controller-/280655527117?pt=AU_Server_Accessories_Parts&hash=item41585f7ccd
All of which I can't recommend highly enough.
I got the Startech ones cheap from a dodgy shop about 4 years ago. They cost me about $30 each.
I got the IBM (really LSI) ones cheap from ebay at about $110 each at Christmas.
The Startech cards use the sata_mv driver and are solid, the LSI cards use the megaraid_sas driver
and are solid. As a bonus of having SAS ports, I picked up 4 Seagate Cheetah 15k.5 SAS drives for a
wicked fast RAID10 array.
Regards,
Brad
^ permalink raw reply
* Re: HBA Adaptor advice
From: Rudy Zijlstra @ 2011-05-19 21:12 UTC (permalink / raw)
To: Thomas Harold; +Cc: Ed W, linux-raid
In-Reply-To: <4DD56B08.6020707@nybeta.com>
On Thu, 2011-05-19 at 15:10 -0400, Thomas Harold wrote:
> On 5/19/2011 8:26 AM, Ed W wrote:
> > Hi, following on from a recent thread, can folks with decent
> > multi-port HBA adaptors please chime in with some model numbers of
> > known decent adaptors please?
> >
> > The required use is to grow from currently 8 ish drives to perhaps
> > 12-24 drives per machine. (It partitions out as: one or more RAID6
> > arrays for data, plus a couple of backup drives)
> >
> > Ideally I would like a controller with writeback cache and BBU since
> > whilst this office machine is likely quite underused, for any
> > sensible amount of IO (some of the other machines we might upgrade)
> > this seems to give a 10-100x increase in IOPs? For the moment it's
> > just a nice to have though
> >
> > I only intend to use linux software raid, so any onboard raid
> > functionality is just a liability. Budget is either low £100 ish for
> > multi-port HBAs without cache, up to £1000 ish for 16-24 port high
> > performance cache controllers:
>
> I've been using a SuperMicro AOC-SASLP-MV8 (which is on your avoid
> list), which reports itself as:
>
> class: SCSI
> bus: PCI
> detached: 0
> driver: mvsas
> desc: "Marvell Technology Group Ltd. MV64460/64461/64462 System
> Controller, Revision B"
> vendorId: 11ab
> deviceId: 6485
> subVendorId: 15d9
> subDeviceId: 0500
>
> I've had it about 6 months at this point with SATA drives hooked up to
> it. The issues that I've had with it dropping disks from the 6-disk
> RAID-10 array on CentOS 5.5 / 5.6 can probably be traced to:
>
> Not using enterprise grade SATA disks (as the consumer brand takes too
> long to timeout on a bad seek, and mdadm dropped it from the array).
> Possibly combined with using a really inexpensive set of removable drive
> trays. There were a lot of times after the weekly resync where the
> entire array went offline due to multiple drives being dropped.
>
> Under normal operation it reads/writes to the disks fine and works fine
> as a controller. Since this is my own personal server, I have not
> tested it with good SAS disks or enterprise SATAs and good drive
> enclosures. I've since switched over to just hooking up a pair of RAID1
> arrays to it with a direct connect from the card to the drives (no
> removable trays), but I don't have enough time on the new setup to say
> that the problem is permanently fixed yet.
>
> The card is inexpensive, which is a plus. It's a PCIe x4 card. I don't
> know whether it would be better behaved with a better class of disks /
> enclosures.
Its inexpensive and unfortunately you are describing symptoms that
belong to the chipset.
It is remains firmly on my avoidance list, and i have one...
Rudy
--
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: Mdadm re-add fails
From: NeilBrown @ 2011-05-19 23:51 UTC (permalink / raw)
To: Schmidt, Annemarie; +Cc: linux-raid
In-Reply-To: <5AA430FFE4486C448003201AC83BC85E01B03522@EXHQ.corp.stratus.com>
On Wed, 18 May 2011 10:43:47 -0400 "Schmidt, Annemarie"
<Annemarie.Schmidt@stratus.com> wrote:
> Hi!
>
> I have a 2 disk raid1 data array. As a result of other testing, the device info
> in the superblock for one of the partners, /dev/sdc2, ended up being in slot 3
> of the device info array:
>
> [root@typhon ~]# mdadm --detail /dev/md21
> /dev/md21:
> Version : 1.2
> Creation Time : Mon May 9 11:19:43 2011
> Raid Level : raid1
> Array Size : 5241844 (5.00 GiB 5.37 GB)
> Used Dev Size : 5241844 (5.00 GiB 5.37 GB)
> Raid Devices : 2
> Total Devices : 2
> Persistence : Superblock is persistent
>
> Intent Bitmap : Internal
>
> Update Time : Thu May 12 15:51:50 2011
> State : active
> Active Devices : 2
> Working Devices : 2
> Failed Devices : 0
> Spare Devices : 0
>
> Name : typhon.mno.stratus.com:21 (local to host typhon.mno.stratus.com)
> UUID : 996d993f:baac367a:8b154ba9:43e56cff
> Events : 687
>
> Number Major Minor RaidDevice State
> --> 3 65 34 0 active sync /dev/sdc2
> 2 65 82 1 active sync /dev/sdk2
>
> When I remove /dev/sdk2 and then a re-add it back in, the re-add fails:
>
> >> [root@typhon ~]# mdadm /dev/md21 -f /dev/sdk2 -r /dev/sdk2
> mdadm: set /dev/sdk2 faulty in /dev/md21
> mdadm: hot removed /dev/sdk2 from /dev/md21
>
> >> [root@typhon ~]# mdadm /dev/md21 -a /dev/sdk2
> mdadm: /dev/sdk2 reports being an active member for /dev/md21, but a --re-add
> fails.
> mdadm: not performing --add as that would convert /dev/sdk2 in to a spare.
> mdadm: To make this a spare, use "mdadm --zero-superblock /dev/sdk2" first.
>
> I believe the re-add fails because the enough_fd function (util.c) is not searching deep enough into the
> dev_info array with this line of code:
> for (i=0; i<array.raid_disks + array.nr_disks; i++)
>
> array.raids_disk = 2 and array/nr_disks = 1, and so for this particular md device, it is only looking at slots 0-2.
> I believe the code needs to be changed to look at all possible dev_info array slots, taking into account the
> version of the superblock (like the Detail function does (Detail.c).
>
> Do folks agree?
>
I do - largely. I think there might be a better more general way to control
the loop though.
Could you try this please?
Thanks,
NeilBrown
diff --git a/util.c b/util.c
index 1056ae4..d005e0a 100644
--- a/util.c
+++ b/util.c
@@ -370,10 +370,14 @@ int enough_fd(int fd)
array.raid_disks <= 0)
return 0;
avail = calloc(array.raid_disks, 1);
- for (i=0; i<array.raid_disks + array.nr_disks; i++) {
+ for (i=0; i < 1024 && array.raid_disks > 0; i++) {
disk.number = i;
if (ioctl(fd, GET_DISK_INFO, &disk) != 0)
continue;
+ if (disk.major == 0 && disk.minor == 0)
+ continue;
+ array.raid_disks--;
+
if (! (disk.state & (1<<MD_DISK_SYNC)))
continue;
if (disk.raid_disk < 0 || disk.raid_disk >= array.raid_disks)
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: HBA Adaptor advice
From: Andy Smith @ 2011-05-20 2:08 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <4DD50C89.8060006@wildgooses.com>
Hi Ed,
On Thu, May 19, 2011 at 01:26:49PM +0100, Ed W wrote:
> Ideally I would like a controller with writeback cache and BBU since
> whilst this office machine is likely quite underused, for any sensible
> amount of IO (some of the other machines we might upgrade) this seems to
> give a 10-100x increase in IOPs? For the moment it's just a nice to
> have though
Are there actually any HBAs that have BBU without using their RAID
features?
I'd like to stop using hardware RAID but I can't give up the BBU and
write cache.
Cheers,
Andy
^ permalink raw reply
* Did I make a mistake?
From: Leslie Rhorer @ 2011-05-20 2:45 UTC (permalink / raw)
To: linux-raid
OK, I may have made an error, and I want to make sure before this
goes any further. Yesterday I created a RAID6 volume with eight 3TB
members, on the same machine containing an older RAID6 array built of
fourteen 1G members. Based upon my reading here and some level of
experience with larger stripe sizes, I decided to create the array with a
chunk size of 4096K. The array from which I am copying all the data to this
new array was created with a chunk size of 256K. It has decent performance.
I also created an array for the backup server with a 1024K chunk. It seems
to perform even better, especially for writes. Given this, I decided to
create the new array with a 4096K chunk. All three arrays are formatted
with XFS, but when I formatted the new array, mkfs.xfs complained that the
stripe size of 4096K was too large, the maximum it supports is 256K, and it
was adjusting the stripe size to 32K. That doesn't sound too good. I don't
recall a response like that when I formatted the other arrays.
When I formatted the array, of course mdadm started syncing the
array. In the past, this process has been slow, so I really wasn't
concerned about the array only reading about 20Mbps for the sync from each
drive. I started copying the data over from the old array, and I was
expecting that process to run more quickly, but it, too is really slow. I
can read from the new array at more than 240MBps - far more than the 1G link
to the LAN can handle, so I have no fears in that respect, but the copy from
the old array is dragging along at only around 15 MBps. Of course I expect
the sync process to slow down the writes considerably, but by that much?? I
would think even with the sync going on, the machine should be able to write
more than 100MBps. An FTP copy from the backup server does a little better,
but not much, at around 17MBps. When I do this, the local copy and the sync
process both seem to slow to a crawl.
At this rate, the copy is going to take about 11 days to complete.
That in and of itself does not bother me, but I don't want to get to the end
of the 11 days and find I need to start all over again. Should I expect the
write performance to increase dramatically when the sync is done? Would I
be well served to start over now and go with a smaller chunk size? The man
page does not say the chink size cannot be changed with a --grow command,
but it doesn't explicitly say it can, either. I seem to recall there is a
way to change the stripe size on XFS, as well, but if my memory serves, it
requires a special parameter be passed to the mount command every time the
volume is mounted.
^ permalink raw reply
* RE: Best way to create RAID-6 for swap partition - existing one failed
From: Leslie Rhorer @ 2011-05-20 3:32 UTC (permalink / raw)
To: 'Stan Hoeppner', 'Gavin Flower'; +Cc: linux-raid, neilb, mb
In-Reply-To: <4DD47FD3.2000909@hardwarefreak.com>
> -----Original Message-----
> From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
> owner@vger.kernel.org] On Behalf Of Stan Hoeppner
> Sent: Wednesday, May 18, 2011 9:26 PM
> To: Gavin Flower
> Cc: linux-raid@vger.kernel.org; neilb@suse.de; mb@gem.win.co.nz
> Subject: Re: Best way to create RAID-6 for swap partition - existing one
> failed
>
> On 5/18/2011 7:11 PM, Gavin Flower wrote:
>
> We're getting pretty OT here...
>
> > What obvious thing have I done, or not done, here?
> >
> > What should I do now?
> >
> > (I am not panicking, because I can always revert back...)
> >
> > I tried to implement you suggestion,
> >
> > # swapoff -a
> > # dd if=/dev/zero of=/swapfile1 bs=1K count=16M
> > 16777216+0 records in
> > 16777216+0 records out
> > 17179869184 bytes (17 GB) copied, 119.642 s, 144 MB/s
> > # mkswap /swapfile1
> > Setting up swapspace version 1, size = 16777212 KiB
> > no label, UUID=9afbf206-9a79-45b8-ad4b-148f71c440d7
>
> 17GB is a bit ridiculous for swap, especially on a single user machine.
I once encountered an fsck that required more than 400G. I had to
kill the process, slot a new 500G drive, and enable swap on the new drive.
^ permalink raw reply
* Re: Did I make a mistake?
From: Roman Mamedov @ 2011-05-20 4:16 UTC (permalink / raw)
To: lrhorer; +Cc: linux-raid
In-Reply-To: <D8.84.03893.CB5D5DD4@cdptpa-omtalb.mail.rr.com>
[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]
On Thu, 19 May 2011 21:45:23 -0500
"Leslie Rhorer" <lrhorer@satx.rr.com> wrote:
> OK, I may have made an error, and I want to make sure before this
> goes any further. Yesterday I created a RAID6 volume with eight 3TB
> members, on the same machine containing an older RAID6 array built of
> fourteen 1G members. Based upon my reading here and some level of
> experience with larger stripe sizes, I decided to create the array with a
> chunk size of 4096K.
4096K is an absurdly large chunk for such RAID5/RAID6 array, I wanted to refer
some benchmarks, but couldn't even find any that would test such a huge chunk,
largest they test is 1024 or 2048, where the write performance already drops
off very sharply, e.g. see:
http://blog.jamponi.net/2008/07/raid56-and-10-benchmarks-on-26255_10.html
http://louwrentius.blogspot.com/2010/05/raid-level-and-chunk-size-benchmarks.html
While the read performance does seem to not suffer or even increase at
higher chunk size, the best read/write combination performance seems to be
achieved at 64...256K chunk for RAID5/6.
If you decide to persist with the current configuration, make sure you
increase stripe_cache_size by a lot (and btw raising it if you have the
RAM to spare is a good idea in any case).
--
With respect,
Roman
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: HBA Adaptor advice
From: Stan Hoeppner @ 2011-05-20 5:30 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <20110520020853.GC4759@bitfolk.com>
On 5/19/2011 9:08 PM, Andy Smith wrote:
> Hi Ed,
>
> On Thu, May 19, 2011 at 01:26:49PM +0100, Ed W wrote:
>> Ideally I would like a controller with writeback cache and BBU since
>> whilst this office machine is likely quite underused, for any sensible
>> amount of IO (some of the other machines we might upgrade) this seems to
>> give a 10-100x increase in IOPs? For the moment it's just a nice to
>> have though
>
> Are there actually any HBAs that have BBU without using their RAID
> features?
AFAIK the LSI real RAID cards allow this. To get them into a JBOD mode
you have to create a single drive RAID 0 of each disk and export it. By
doing so the RAID firmware is actually active, though not really doing
anything, so you get the cache and BBU benefit of the controller. One
of the XFS developers, Dave Chinner, posted this to the XFS list quite
some time ago when we discussed hardware vs software RAID setups.
--
Stan
^ permalink raw reply
* Software raid, booting and bios
From: Paul van der Vlis @ 2011-05-20 6:54 UTC (permalink / raw)
To: linux-raid
Hello,
I use software raid (mdadm). The main problem for me is that when the
drive with the MBR fails, it can become a problem to boot.
When the bios would use another drive to boot when the first drive
failes, this problem would be gone. But I don't know rackservers who do
that. Do you?
Or is there maybe some kind of fake-raid card what uses mdadm to solve
this problem?
Another way would be to use e.g. an USB device to boot to solve this
problem. Any experiences with that?
(hmm, I realize that netboot is an option too).
With regards,
Paul van der Vlis.
--
http://www.vandervlis.nl
^ permalink raw reply
* Re: Software raid, booting and bios
From: Simon Mcnair @ 2011-05-20 7:03 UTC (permalink / raw)
To: Paul van der Vlis; +Cc: linux-raid@vger.kernel.org
In-Reply-To: <ir536c$9jv$1@dough.gmane.org>
Please can you further define what you mean by 'it can become a
problem to boot' ?
Generally this is resolved by having a mbr and boot partition on each
of your mirrored drives so that whichever you use to boot has the
pertinent information to boot the kernel and construct the raid array.
If you have raid 5 with 3 disks you'd have a 3 drive mirror partition
on each disk and a raid 5 set across all three too.
I'm not a guru on this and can't provide much knowledge past the
theory and high level ;-)
Simon
On 20 May 2011, at 07:55, Paul van der Vlis <paul@vandervlis.nl> wrote:
> Hello,
>
> I use software raid (mdadm). The main problem for me is that when the
> drive with the MBR fails, it can become a problem to boot.
>
> When the bios would use another drive to boot when the first drive
> failes, this problem would be gone. But I don't know rackservers who do
> that. Do you?
>
> Or is there maybe some kind of fake-raid card what uses mdadm to solve
> this problem?
>
> Another way would be to use e.g. an USB device to boot to solve this
> problem. Any experiences with that?
>
> (hmm, I realize that netboot is an option too).
>
> With regards,
> Paul van der Vlis.
>
>
> --
> http://www.vandervlis.nl
>
> --
> 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: Software raid, booting and bios
From: Paul van der Vlis @ 2011-05-20 7:14 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <6123979024523080515@unknownmsgid>
Op 20-05-11 09:03, Simon Mcnair schreef:
> Please can you further define what you mean by 'it can become a
> problem to boot' ?
> Generally this is resolved by having a mbr and boot partition on each
> of your mirrored drives so that whichever you use to boot has the
> pertinent information to boot the kernel and construct the raid array.
> If you have raid 5 with 3 disks you'd have a 3 drive mirror partition
> on each disk and a raid 5 set across all three too.
In the bios from my machines (Supermicro, Dell) I can select only one
drive to boot. Wenn the drive fails, no other disk is tried.
I can go into the bios and change the drive when it fails, or I can
exchange the disks. But I would like it, when the machine would simple
boot even when the first disk is corrupt.
With regards,
Paul van der Vlis.
> I'm not a guru on this and can't provide much knowledge past the
> theory and high level ;-)
> Simon
>
> On 20 May 2011, at 07:55, Paul van der Vlis <paul@vandervlis.nl> wrote:
>
>> Hello,
>>
>> I use software raid (mdadm). The main problem for me is that when the
>> drive with the MBR fails, it can become a problem to boot.
>>
>> When the bios would use another drive to boot when the first drive
>> failes, this problem would be gone. But I don't know rackservers who do
>> that. Do you?
>>
>> Or is there maybe some kind of fake-raid card what uses mdadm to solve
>> this problem?
>>
>> Another way would be to use e.g. an USB device to boot to solve this
>> problem. Any experiences with that?
>>
>> (hmm, I realize that netboot is an option too).
>>
>> With regards,
>> Paul van der Vlis.
>>
>>
>> --
>> http://www.vandervlis.nl
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Software raid, booting and bios
From: Simon Mcnair @ 2011-05-20 7:19 UTC (permalink / raw)
To: Paul van der Vlis; +Cc: linux-raid@vger.kernel.org
I have not come across a pc which does not allow you to boot a
secondary drive before... Please can you read the manual and triple
check this ? The only possible reason I can think this would happen
Is that you're using an add on board and you would configure this from
a secondary bios. My Dell, Asus, and all other motherboards I've had
over the past 10 years all allow a second device.
Cheers
Simon
On 20 May 2011, at 08:15, Paul van der Vlis <paul@vandervlis.nl> wrote:
> Op 20-05-11 09:03, Simon Mcnair schreef:
>> Please can you further define what you mean by 'it can become a
>> problem to boot' ?
>> Generally this is resolved by having a mbr and boot partition on each
>> of your mirrored drives so that whichever you use to boot has the
>> pertinent information to boot the kernel and construct the raid array.
>> If you have raid 5 with 3 disks you'd have a 3 drive mirror partition
>> on each disk and a raid 5 set across all three too.
>
> In the bios from my machines (Supermicro, Dell) I can select only one
> drive to boot. Wenn the drive fails, no other disk is tried.
>
> I can go into the bios and change the drive when it fails, or I can
> exchange the disks. But I would like it, when the machine would simple
> boot even when the first disk is corrupt.
>
> With regards,
> Paul van der Vlis.
>
>
>> I'm not a guru on this and can't provide much knowledge past the
>> theory and high level ;-)
>> Simon
>>
>> On 20 May 2011, at 07:55, Paul van der Vlis <paul@vandervlis.nl> wrote:
>>
>>> Hello,
>>>
>>> I use software raid (mdadm). The main problem for me is that when the
>>> drive with the MBR fails, it can become a problem to boot.
>>>
>>> When the bios would use another drive to boot when the first drive
>>> failes, this problem would be gone. But I don't know rackservers who do
>>> that. Do you?
>>>
>>> Or is there maybe some kind of fake-raid card what uses mdadm to solve
>>> this problem?
>>>
>>> Another way would be to use e.g. an USB device to boot to solve this
>>> problem. Any experiences with that?
>>>
>>> (hmm, I realize that netboot is an option too).
>>>
>>> With regards,
>>> Paul van der Vlis.
>>>
>>>
>>> --
>>> http://www.vandervlis.nl
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
> --
> 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: HBA Adaptor advice
From: Ed W @ 2011-05-20 7:33 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <20110520020853.GC4759@bitfolk.com>
On 20/05/2011 03:08, Andy Smith wrote:
> Are there actually any HBAs that have BBU without using their RAID
> features?
>
> I'd like to stop using hardware RAID but I can't give up the BBU and
> write cache.
This is a very interesting question. Does anyone know if say the Areca
ARC-1880ix-24 can be used in the same way, ie battery backed JBOD type mode?
I received a recommendation offlist that the various 3Ware SAS 9750-xx
cards can be used easily as a bunch of single drives, however, comparing
the photos of these with the LSI MegaRAID 9280-xx they seem identical?
(Presumed to be identical?). Anyone know why LSI sell an identical card
under the 3ware brand (still)? Curiously I see the LSI generally
selling a little cheaper than the 3ware in the uk... (wierd)
Are there any cards to avoid because they *can't* be used in this way?
eg Dell PERC6 seem to come up cheaply on ebay - can these be used as BBU
backed single JBOD controllers?
I guess the limitation is that some of these cards can only create a
small number of arrays and/or they don't use their writeback cache
efficiently in the case of multiple arrays?
Thanks for any education here. (I found a cheap Areca on ebay, plus
been eyeing up the various cheap Dell PERC cards...)
Ed W
^ permalink raw reply
* Re: Software raid, booting and bios
From: Paul van der Vlis @ 2011-05-20 8:33 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <9067914580344941270@unknownmsgid>
Op 20-05-11 09:19, Simon Mcnair schreef:
> I have not come across a pc which does not allow you to boot a
> secondary drive before... Please can you read the manual and triple
> check this ? The only possible reason I can think this would happen
> Is that you're using an add on board and you would configure this from
> a secondary bios. My Dell, Asus, and all other motherboards I've had
> over the past 10 years all allow a second device.
You can select the "boot device priority" where you can choose about
devices types (DVD, harddisk, USB, network) but you can choose only one
SATA disk. Study it, and you will see I am right. I've asked it to my
rackserver-vendor, they say: "that's always the case".
But I think I have had systems in the past, what could do it. An
interesting question is then: how well is it tested? What when e.g. a
disk boots, and then gives an I/O error? I am looking for a well-tested
way to solve this, and I am willing to pay for it or choose another
hardware vendor for it.
With regards,
Paul van der Vlis.
> Cheers
> Simon
>
> On 20 May 2011, at 08:15, Paul van der Vlis <paul@vandervlis.nl> wrote:
>
>> Op 20-05-11 09:03, Simon Mcnair schreef:
>>> Please can you further define what you mean by 'it can become a
>>> problem to boot' ?
>>> Generally this is resolved by having a mbr and boot partition on each
>>> of your mirrored drives so that whichever you use to boot has the
>>> pertinent information to boot the kernel and construct the raid array.
>>> If you have raid 5 with 3 disks you'd have a 3 drive mirror partition
>>> on each disk and a raid 5 set across all three too.
>>
>> In the bios from my machines (Supermicro, Dell) I can select only one
>> drive to boot. Wenn the drive fails, no other disk is tried.
>>
>> I can go into the bios and change the drive when it fails, or I can
>> exchange the disks. But I would like it, when the machine would simple
>> boot even when the first disk is corrupt.
>>
>> With regards,
>> Paul van der Vlis.
>>
>>
>>> I'm not a guru on this and can't provide much knowledge past the
>>> theory and high level ;-)
>>> Simon
>>>
>>> On 20 May 2011, at 07:55, Paul van der Vlis <paul@vandervlis.nl> wrote:
>>>
>>>> Hello,
>>>>
>>>> I use software raid (mdadm). The main problem for me is that when the
>>>> drive with the MBR fails, it can become a problem to boot.
>>>>
>>>> When the bios would use another drive to boot when the first drive
>>>> failes, this problem would be gone. But I don't know rackservers who do
>>>> that. Do you?
>>>>
>>>> Or is there maybe some kind of fake-raid card what uses mdadm to solve
>>>> this problem?
>>>>
>>>> Another way would be to use e.g. an USB device to boot to solve this
>>>> problem. Any experiences with that?
>>>>
>>>> (hmm, I realize that netboot is an option too).
>>>>
>>>> With regards,
>>>> Paul van der Vlis.
>>>>
>>>>
>>>> --
>>>> http://www.vandervlis.nl
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Software raid, booting and bios
From: Roman Mamedov @ 2011-05-20 8:56 UTC (permalink / raw)
To: Paul van der Vlis; +Cc: linux-raid
In-Reply-To: <ir58vs$9qp$1@dough.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1293 bytes --]
On Fri, 20 May 2011 10:33:00 +0200
Paul van der Vlis <paul@vandervlis.nl> wrote:
> You can select the "boot device priority" where you can choose about
> devices types (DVD, harddisk, USB, network) but you can choose only one
> SATA disk. Study it, and you will see I am right. I've asked it to my
> rackserver-vendor, they say: "that's always the case".
How about just not buying crappy hardware from this lying vendor anymore.
http://ompldr.org/vOHB6Zw/bios4.jpg <- this is present in majority of
motherboard BIOSes since forever.
> But I think I have had systems in the past, what could do it. An
> interesting question is then: how well is it tested? What when e.g. a
> disk boots, and then gives an I/O error? I am looking for a well-tested
> way to solve this, and I am willing to pay for it or choose another
> hardware vendor for it.
Yes, I think it is conceivable that if a disk fails in a 'bad' way, i.e. by
locking up on reads, or reading the first sector but not the next ones it can
prevent the system from booting even with this priority system. I don't know
if chances of that are high, considering that quite often disks fail by also
ceasing to be detectable in BIOS, in which case your boot-up would proceed
normally.
--
With respect,
Roman
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Software raid, booting and bios
From: Paul van der Vlis @ 2011-05-20 9:33 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <20110520145623.749b4781@natsu>
Op 20-05-11 10:56, Roman Mamedov schreef:
> On Fri, 20 May 2011 10:33:00 +0200
> Paul van der Vlis <paul@vandervlis.nl> wrote:
>
>> You can select the "boot device priority" where you can choose about
>> devices types (DVD, harddisk, USB, network) but you can choose only one
>> SATA disk. Study it, and you will see I am right. I've asked it to my
>> rackserver-vendor, they say: "that's always the case".
>
> How about just not buying crappy hardware from this lying vendor anymore.
> http://ompldr.org/vOHB6Zw/bios4.jpg <- this is present in majority of
> motherboard BIOSes since forever.
Interesting. From what brand server is this?
>> But I think I have had systems in the past, what could do it. An
>> interesting question is then: how well is it tested? What when e.g. a
>> disk boots, and then gives an I/O error? I am looking for a well-tested
>> way to solve this, and I am willing to pay for it or choose another
>> hardware vendor for it.
>
> Yes, I think it is conceivable that if a disk fails in a 'bad' way, i.e. by
> locking up on reads, or reading the first sector but not the next ones it can
> prevent the system from booting even with this priority system. I don't know
> if chances of that are high, considering that quite often disks fail by also
> ceasing to be detectable in BIOS, in which case your boot-up would proceed
> normally.
The problem is about detected disks with a defect in the MBR.
With regards,
Paul van der Vlis.
^ permalink raw reply
* Re: Software raid, booting and bios
From: Simon McNair @ 2011-05-20 10:00 UTC (permalink / raw)
To: Paul van der Vlis; +Cc: linux-raid
In-Reply-To: <ir5ci1$uc6$1@dough.gmane.org>
Paul,
Please can you get some digital camera shots (resize them, low res and
compress them) of the bios screen (or screen grabs if it's via a LOM).
I'm especially interested in knowing if in the device listing there are
two or more hard disks in the first place (as if there is only one disk
I'd not be surprised at getting only one set of options).
Can you ask you rack space vendor the specific question 'how do I set up
a secondary boot device ?".
Simon
On 20/05/2011 10:33, Paul van der Vlis wrote:
> Op 20-05-11 10:56, Roman Mamedov schreef:
>> On Fri, 20 May 2011 10:33:00 +0200
>> Paul van der Vlis<paul@vandervlis.nl> wrote:
>>
>>> You can select the "boot device priority" where you can choose about
>>> devices types (DVD, harddisk, USB, network) but you can choose only one
>>> SATA disk. Study it, and you will see I am right. I've asked it to my
>>> rackserver-vendor, they say: "that's always the case".
>> How about just not buying crappy hardware from this lying vendor anymore.
>> http://ompldr.org/vOHB6Zw/bios4.jpg<- this is present in majority of
>> motherboard BIOSes since forever.
> Interesting. From what brand server is this?
>
>>> But I think I have had systems in the past, what could do it. An
>>> interesting question is then: how well is it tested? What when e.g. a
>>> disk boots, and then gives an I/O error? I am looking for a well-tested
>>> way to solve this, and I am willing to pay for it or choose another
>>> hardware vendor for it.
>> Yes, I think it is conceivable that if a disk fails in a 'bad' way, i.e. by
>> locking up on reads, or reading the first sector but not the next ones it can
>> prevent the system from booting even with this priority system. I don't know
>> if chances of that are high, considering that quite often disks fail by also
>> ceasing to be detectable in BIOS, in which case your boot-up would proceed
>> normally.
> The problem is about detected disks with a defect in the MBR.
>
> With regards,
> Paul van der Vlis.
>
>
> --
> 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: Software raid, booting and bios
From: CoolCold @ 2011-05-20 10:04 UTC (permalink / raw)
To: Paul van der Vlis; +Cc: linux-raid
In-Reply-To: <ir58vs$9qp$1@dough.gmane.org>
Здравствуйте, Paul.
Вы писали 20 мая 2011 г., 12:33:00:
> Op 20-05-11 09:19, Simon Mcnair schreef:
>> I have not come across a pc which does not allow you to boot a
>> secondary drive before... Please can you read the manual and triple
>> check this ? The only possible reason I can think this would happen
>> Is that you're using an add on board and you would configure this from
>> a secondary bios. My Dell, Asus, and all other motherboards I've had
>> over the past 10 years all allow a second device.
> You can select the "boot device priority" where you can choose about
> devices types (DVD, harddisk, USB, network) but you can choose only one
> SATA disk. Study it, and you will see I am right. I've asked it to my
> rackserver-vendor, they say: "that's always the case".
I've seen supermicro servers with bios allowing to set several drives
as boot disks and without such option (like in your case).
One of those which could do this was
http://www.supermicro.com/products/motherboard/Xeon1333/5000P/X7DB3.cfm
if i remember things right.
> But I think I have had systems in the past, what could do it. An
> interesting question is then: how well is it tested? What when e.g. a
> disk boots, and then gives an I/O error? I am looking for a well-tested
> way to solve this, and I am willing to pay for it or choose another
> hardware vendor for it.
> With regards,
> Paul van der Vlis.
>> Cheers
>> Simon
>>
>> On 20 May 2011, at 08:15, Paul van der Vlis <paul@vandervlis.nl> wrote:
>>
>>> Op 20-05-11 09:03, Simon Mcnair schreef:
>>>> Please can you further define what you mean by 'it can become a
>>>> problem to boot' ?
>>>> Generally this is resolved by having a mbr and boot partition on each
>>>> of your mirrored drives so that whichever you use to boot has the
>>>> pertinent information to boot the kernel and construct the raid array.
>>>> If you have raid 5 with 3 disks you'd have a 3 drive mirror partition
>>>> on each disk and a raid 5 set across all three too.
>>>
>>> In the bios from my machines (Supermicro, Dell) I can select only one
>>> drive to boot. Wenn the drive fails, no other disk is tried.
>>>
>>> I can go into the bios and change the drive when it fails, or I can
>>> exchange the disks. But I would like it, when the machine would simple
>>> boot even when the first disk is corrupt.
>>>
>>> With regards,
>>> Paul van der Vlis.
>>>
>>>
>>>> I'm not a guru on this and can't provide much knowledge past the
>>>> theory and high level ;-)
>>>> Simon
>>>>
>>>> On 20 May 2011, at 07:55, Paul van der Vlis <paul@vandervlis.nl> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I use software raid (mdadm). The main problem for me is that when the
>>>>> drive with the MBR fails, it can become a problem to boot.
>>>>>
>>>>> When the bios would use another drive to boot when the first drive
>>>>> failes, this problem would be gone. But I don't know rackservers who do
>>>>> that. Do you?
>>>>>
>>>>> Or is there maybe some kind of fake-raid card what uses mdadm to solve
>>>>> this problem?
>>>>>
>>>>> Another way would be to use e.g. an USB device to boot to solve this
>>>>> problem. Any experiences with that?
>>>>>
>>>>> (hmm, I realize that netboot is an option too).
>>>>>
>>>>> With regards,
>>>>> Paul van der Vlis.
>>>>>
>>>>>
>>>>> --
>>>>> http://www.vandervlis.nl
>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
> --
> 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
--
Best regards,
[COOLCOLD-RIPN]
--
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
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