* Re: Performarce raid6 degraded
From: Pol Hallen @ 2011-05-22 12:57 UTC (permalink / raw)
To: Linux-RAID
> What was it when the array was not degraded?
ehm.. I never didn't wrote the results :-O
I discover another bad disk.. problems problems..
thanks :-)
Pol
^ permalink raw reply
* Re: HBA Adaptor advice
From: Brad Campbell @ 2011-05-22 10:09 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <4DD8D1A7.1090803@hardwarefreak.com>
On 22/05/11 17:04, Stan Hoeppner wrote:
> WD's Green drives have a 5400 rpm 'variable' spindle speed. The Seagate
> 2.5" SAS drive has a 7.2k spindle speed.
Actually, I'm pretty sure the WD drives have a 5400 rpm spindle speed
period. I've got 15 of them here and I have no evidence of any form of
spindle speed variation. They say the drives have spindle speed :
"intellipower" which is marketspeak for slow enough to save a few watts,
but fast enough to do the job.
> It's difficult to align partitions properly on the Green drives due to
> native 4K sectors translated by drive firmware to 512B sectors. The
> Seagate SAS drive has native 512B sectors.
Actually it's not difficult at all. You just make sure all your
partitions start on an even multiple of 8 sectors. No magic in it. Just
the same as all my SSD partitions start on 512k boundaries.
> The Green drives have aggressive power saving firmware not suitable for
> business use as the heads are auto parked every 8 seconds or so. IIRC
> the drive goes into sleep mode after a short period of inactivity on the
> host interface. In short, these drives are designed optimally for the
> "is not running" case rather than the "running" case. Hence the name
> "Green". How do you save power? Turn off the drive. And that's
> exactly what these drives are designed to do.
You can turn off the aggressive head parking with a little DOS utility,
and they don't go to sleep at all unless you tell them to. They will
happily keep spinning just the same as any other disk.
I'm running them in a couple of large(ish) RAID arrays. I'm not saying
it's a good idea, it's just been my experience with ultra-cheap drives
that if you burn in the drives to weed out the early failures, and you
keep them running 24/7 in a nice environment they tend to last long
enough to do the job. I tend to replace my drives at around ~30,000
hours, so these have a long way to go yet.
On the other hand, I have my company data on Seagate Cheetah SAS drives
in RAID-10, but I back up to the large WD Green arrays.
^ permalink raw reply
* Re: HBA Adaptor advice
From: Rudy Zijlstra @ 2011-05-22 10:03 UTC (permalink / raw)
To: Stan Hoeppner; +Cc: linux-raid
In-Reply-To: <4DD8DA31.7030608@hardwarefreak.com>
On 05/22/2011 11:41 AM, Stan Hoeppner wrote:
> On 5/21/2011 6:54 AM, Ed W wrote:
>
>
>> In fact if you go back to my question, the *entire* point is that I
>> don't want the choice of card to be a point of failure, ie it's my
>> specific point to purchase a card such that it can be swapped out for
>> near any other card in the event of failure.
>>
> You're given about 3 or 4 conflicting requirement now WRT your 'perfect'
> HBA.
>
> What HBAs are you currently using? How many of your stated requirements
> over the past few days do your current HBAs fulfill?
>
> Do you have a tape or D2D backup system in place?
>
> There is no guarantee that you can swap one dead HBA for another brand
> with a different chipset on board and have it work without issue. If
> you are that concerned you need to buy two identical cheap HBAs so you
> have a spare. But wait! You must have hardware write cache for md RAID
> as well. But if you do that, you're locked into that vendor's cards.
> And on, and on...
>
> I've never seen nor heard of a real SA in a business environment
> vacillate like this over a simple RAID/HBA acquisition, as if the
> company's entire 1st quarter net profit was being wrapped up in this HBA
> purchase. And I've never head of an SA being concerned about cable
> tripping of all damn things taking down a server.
>
> Something in this whole thread just doesn't jibe...
>
>
The amount of money that his time has cost discussing this & thinking
about it, is most likely already noticeably more then the cost of a
mid-range RAID card.
My approach (and i have my own small company):
- use HW RAID on the system disks (RAID5) (and have a spare controller
of same type ready)
- use MD RAID on big storage with cheap disks (and have spare disks
lying ready)
- have a nightly automated backup to different system, with versioning
and ability to recover state of half year ago
That other system is in different building.
As i do not upgrade the servers that often, this ensures:
- i do not need to spend a long time on getting the system back up, if a
system disk goes bye-bye
- no need to think long on how grub/lilo was supposed to be working for
multiple disks
- no need to remember to re-install bootloader on all related disks (so
i safe-guard against my own mistakes. Takes some money, yes, but i am
willing to pay that part of insurance quit willingly. I am aware i make
mistakes, especially when time pressure is high)
- backup in place for the usual stupid mistaken deletes.
yes, i keep spare controllers. Do i need them? not really... so far i
have had only 1 raid card die on me... in 10+ years i am using them.
I've had many disks go to bit hell, and some mobo. Not raid cards though.
My main issues with this discussion, is that it assumes:
- no time pressure when the shit hits the fan
- the system maintainer does not make mistakes
Both of them fail in real-life, especially with the small businesses
where this discussion is relevant for cost reasons. Thus my stated
feeling of "penny wise, pound foolish". Murphy being what it is, things
usually fail when you need to have your attention on something else.
That means there is great opportunity at such a time to make mistakes.
Thus the setup of such systems needs to take the human aspect into
account. As far as i can see the setup he is defining is simply too
complex for the situation.
I've had things fail on me when i needed to leave in 2 hour, as i had a
flight to catch. I also needed that server to be running...
Cheers,
Rudy
^ permalink raw reply
* Re: HBA Adaptor advice
From: Stan Hoeppner @ 2011-05-22 9:41 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <4DD7A80C.8050808@wildgooses.com>
On 5/21/2011 6:54 AM, Ed W wrote:
> In fact if you go back to my question, the *entire* point is that I
> don't want the choice of card to be a point of failure, ie it's my
> specific point to purchase a card such that it can be swapped out for
> near any other card in the event of failure.
You're given about 3 or 4 conflicting requirement now WRT your 'perfect'
HBA.
What HBAs are you currently using? How many of your stated requirements
over the past few days do your current HBAs fulfill?
Do you have a tape or D2D backup system in place?
There is no guarantee that you can swap one dead HBA for another brand
with a different chipset on board and have it work without issue. If
you are that concerned you need to buy two identical cheap HBAs so you
have a spare. But wait! You must have hardware write cache for md RAID
as well. But if you do that, you're locked into that vendor's cards.
And on, and on...
I've never seen nor heard of a real SA in a business environment
vacillate like this over a simple RAID/HBA acquisition, as if the
company's entire 1st quarter net profit was being wrapped up in this HBA
purchase. And I've never head of an SA being concerned about cable
tripping of all damn things taking down a server.
Something in this whole thread just doesn't jibe...
--
Stan
^ permalink raw reply
* Re: HBA Adaptor advice
From: Stan Hoeppner @ 2011-05-22 9:04 UTC (permalink / raw)
To: Ed W; +Cc: linux-raid
In-Reply-To: <4DD79F4E.7000509@wildgooses.com>
On 5/21/2011 6:17 AM, Ed W wrote:
> Hi Stan
>
> Thanks for the time in composing your reply
Heh, I'm TheHardwareFreak, whaddya expect? ;) Note the domain in my
email addy.
>> I'm curious why you are convinced that you need BBWC, or even simply WC,
>> on an HBA used for md RAID.
>
> In the past I have used battery backed cards and where the write speed
> is "fsync constrained" the writeback cache makes the app performance fly
> at perhaps 10-100x the speed
Ok, now that makes more sense. This is usually the case with a hardware
RAID card or SAN controller, though depends on the
vendor/implementation. I've never run one in 'JBOD' mode but with write
cache enabled, so I can't say if fsync behavior will be the same using
md RAID or not. Maybe someone else has tested this.
> Only for a single reason: Its a small office server and I want the
> flexibility to move the drives to a different card (eg failed server,
> failed card or something else). Buying a spare card changes the
> dynamics quite a bit when the whole server (sans raid card) only costs
> £1,000 ish?
If adding a real hardware RAID card and enterprise drives to a 'base'
server, the storage will nearly always cost more than the server,
especially with HP Proliant 1U quad core rack servers going for well
less than $1000 USD. This has been reality for a few years now.
> You may be
>> interested to know:
>>
>> 1. When BBWC is enabled, all internal drive caches must be disabled.
>> Otherwise you eliminate the design benefit of the BBU, and may as
>> well not have one.
>
> Yes, I hadn't thought of that. Good point!
>
>> 2. w/md RAID on an HBA, if you have a good UPS and don't suffer
>> kernel panics, crashes, etc, you can disable barrier support in
>> your FS and you can use the drive caches.
>
> I don't buy this...
Well, take into consideration that the vast majority of people running
md RAID arrays, including most, if not all, on this list, aren't using
hardware writeback cache. They using plain Jane SAS/SATA HBAs. Some
are using hybrid hardware arrays stitched together with md RAID striping
or concatenation. But in those cases we're talking multiple tens of
thousands of dollars per system.
> In my limited experience hardware is pretty reliable and goes bad
> rarely. However, my estimate is that powercables fall out, PSUs fail
> and UPSs go bad at least as often as the power fails?
*Quality* hardware today is very reliable.
Power cords *never* come lose in my experience, I don't allow it.
PSUs and UPSes fail at about the same rate as RAID cards, IME--*rarely*
Apparently Britain has a far better power grid than the States.
> Obviously it's application dependent, some may tolerate small dataloss
> in the event of powerdown, but I should think most people want a
> guarantee that the system is "recoverable" in the event of sudden
> powerdown.
There is always a tradeoff here between performance, resilience,
flexibility, and cost. You currently have conflicting criteria in this
regard. If you can afford all that you want, pick that which is most
important to eliminate the conflicts. Then implement it.
> I think disabling barriers might not be the best way to avoid fsync
> delays, compared with the incremental cost of adding BBU writeback
> cache? (basically the same thing, but smaller chance of failure)
On the type of small office server you described, it's difficult to
grasp how performance is so critical. You sound like a candidate for a
mixed SSD + SAS/SATA RAID setup. Put things that require low latency,
such as the Postfix spool, Dovecot indexes, and MySQL tables on SSD, and
put user data, such as IMAP mail directories, home directory files, etc,
on spinning RAID. This way you get high performance and low cost.
> It depends on the application, but I claim that there is a fairly
> significant chance of hard unexpected powerdown even with a good UPS.
> You still are at risk from cables getting pulled, UPSs failing, etc
If cables getting yanked is a concern, you have human issues that must
be solved long before the technical aspects of system resiliency. I've
not built/installed/used/serviced a pedestal server in over a decade.
> I think in a properly setup datacenter (racked) environment then it's
> easier to control these accidents.
We don't have "accidents" in our datacenters, not the homo sapien
initiated type you refer to.
> Cables can be tied in, layers of
> power backup can be managed, it becomes efficient to add quality
> surge/lightning protection, etc. However, there is a large proportion
> of the market that have a few machines in an office and now it's much
> harder to stop the cleaner tripping over the UPS, or hiding it under
> boxes of paper until it melts due to overheating...
Again, these types of problems can't be solved with technological means.
> I want BB writeback cache purely to get the performance of effectively
> disabling fsync, but without the loss of protection which occurs if you
> do so.
You can have it with some cards. But, you will lose your ability to
swap the drives to a different make/model of HBA in the future.
> Everything is about optimisation of cost vs performance vs reliability.
Yep.
> Like everything else, my question is really about the tradeoff of a
> small incremental spend, which in turn might generate a substantial
> performance increase for certain classes of application. Largely I'm
> thinking about performance tradeoffs for small office servers priced in
> the £500-3,000 kind of range (not "proper" high end storage devices)
'Proper' need not be 'high end' nor expensive.
> I think at that kind of level it makes sense to look for bargains,
> especially if you are adding servers in small quantities, eg singles or
> pairs.
Again, that's exactly what the parts I posted gives you.
>> Buy 12:
>> http://www.seagate.com/ww/v/index.jsp?name=st91000640ss-constellation2-6gbs-sas-1-tb-hd&vgnextoid=ff13c5b2933d9210VgnVCM1000001a48090aRCRD&vgnextchannel=f424072516d8c010VgnVCM100000dd04090aRCRD&locale=en-US&reqPage=Support#tTabContentSpecifications
>
> Out of curiosity I check the power consumption and reliability numbers
> of the 3.5" "Green" drives and it's not so clear cut that the 2.5"
> drives outperform?
WD's Green drives have a 5400 rpm 'variable' spindle speed. The Seagate
2.5" SAS drive has a 7.2k spindle speed.
It's difficult to align partitions properly on the Green drives due to
native 4K sectors translated by drive firmware to 512B sectors. The
Seagate SAS drive has native 512B sectors.
The Green drives have aggressive power saving firmware not suitable for
business use as the heads are auto parked every 8 seconds or so. IIRC
the drive goes into sleep mode after a short period of inactivity on the
host interface. In short, these drives are designed optimally for the
"is not running" case rather than the "running" case. Hence the name
"Green". How do you save power? Turn off the drive. And that's
exactly what these drives are designed to do.
The Seagate 2.5" SAS drive has TLER support, the Green doesn't. If you
go hardware RAID, you need TLER. It's good to have for md RAID as well
but not a requirement.
Check the warranty difference between the Seagate SAS drive and the WD
Green. Also note WD's 'RAID use' policy.
> Thanks for your thoughts - I think this thread has been very
> constructive - still very interested to hear good/bad reports of
> specific cards - perhaps someone might archive it into some kind of list?
I see RAID card shootouts now and then. Google should find you
something. Thought you won't see anyone testing Linux md RAID on a
hardware RAID card in JBOD mode.
--
Stan
--
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: Stan Hoeppner @ 2011-05-22 8:13 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <4DD7A100.2010807@wildgooses.com>
On 5/21/2011 6:24 AM, Ed W wrote:
> On 20/05/2011 21:58, Stan Hoeppner wrote:
>
>> As always, a good data persistence strategy starts with a good UPS.
>
> I'm sure you are going to tell me that my APCs aren't good UPSs, but I
In my experience APC are good UPS. Interestingly, I have an APC
SU1400RMNET manufactured in *1997*, powering my home office rack. I've
replaced the batteries 4 times, but the UPS itself is like the Energizer
Bunny. 14 years and still going strong.
> have something like 5 APCs and 4 have failed in odd ways due to the
> battery dying, inside of around 2 years from new. Sure you replace the
Then I'd guess you're not performing proper UPS maintenance. Once
yearly you need to perform a deep cycle self test which can notify you
of marginal batteries at a much earlier stage. Your APC manual has
instructions for performing this test, or you can download the manual
from there site if it's been lost.
All APCs inform you when the battery needs to be replaced, via front
panel LED and via software or network notification (Email/SNMP). But
you don't want to wait for that. Do the deep self test.
> battery, but failure modes each time caused a sudden power failure. In
> nearly all cases the UPS failed before I would have had a sudden power
> loss for other reasons...
Yep. Lack of proper UPS maintenance and monitoring.
> So, I'm not convinced that UPSs dramatically raise the uptime, and where
Without a UPS in Missouri USA, your servers will go down from power loss
at *minimum* 50-100 times per year due to electrical storms, high winds,
power line maintenance, brown outs and sags caused by all manner of
things, truck hitting power pole, etc, etc.
> they do it's in well designed, racked, datacenter environments where
> "accidents" don't dominate the downtime risk?
Doesn't matter if it's a corporate datacenter, your rack in the
basement, or an office pedestal server. What counts is proper design
and installation. It's is trivially simple in an office environment to
route all cables in a manner that they won't be tripped over. I'm truly
shocked that cable tripping could be an issue for anyone in 2011, let
alone 1999. Get a rack cabinet and stick it in a corner. Here, get this:
http://cgi.ebay.co.uk/COMPAQ-42U-SERVER-RACK-CABINET-ENCLOSURE-/150608001643?pt=UK_Computing_Networking_SM&hash=item2310efba6b
and 2 or 3 of these, since all your servers are non-rack boxes:
http://cgi.ebay.co.uk/StarTech-Adjustable-Depth-Fixed-Server-Rack-Cabinet-She-/320618338412?pt=UK_Computing_ComputerComponents_Monitors&hash=item4aa657986c
Problem solved.
--
Stan
^ permalink raw reply
* Re: Software raid, booting and bios
From: Simon McNair @ 2011-05-22 6:31 UTC (permalink / raw)
To: paul; +Cc: 'Brad Campbell', linux-raid, lrhorer
In-Reply-To: <9A.9E.03893.C8577DD4@cdptpa-omtalb.mail.rr.com>
I think you might want to investigate a SATA DOM (Disk on module). My
Thecus 5200 uses on and it seems a neat solution.
eg
http://www.innodisk.com/flashstorage-list.jsp?items_name=satadom
Simon
On 21/05/2011 09:19, Leslie Rhorer wrote:
>> -----Original Message-----
>> From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
>> owner@vger.kernel.org] On Behalf Of Brad Campbell
>> Sent: Friday, May 20, 2011 4:52 PM
>> To: linux-raid@vger.kernel.org
>> Subject: Re: Software raid, booting and bios
>>
>> On 21/05/11 03:32, Phil Turmel wrote:
>>
>>> the big deal is the lack of moving parts: No spindle bearing, no head
>> positioner gear train.
>>
>> Sorry, this just tickled me. "gear train" ? Which decade are we talking
>> about? The last drive I saw
>> that had any form of mechanical power transfer mechanism for head
>> positioning was a 60MB RLL Seagate
>> clunker.
> Yeah, the number of moving parts in a hard drive is minimal. OTOH,
> it's not zero.
>
>> Now, to add some form of use to the thread I've been using commodity CF
>> cards in home-brew CF to ATA
>> adaptors in embedded systems for 10 years. Flash is _the_ way to go for
>> high reliability systems
>> that don't have lots of write cycles.
>>
>> My TV box that has no on-board PXE has been booting from a 10MB USB stick
>> using loadlinux since
>> 2003. Dead reliable after ~69,000 hours power on time. I've not had a hard
>> disk last that long since
>> my old 200MB WD IDE drive (which is still running with over 100,000 hours
>> on it).
> Oh, we have quite a number of embedded controllers with SCSI hard
> drives that have been spinning continuously since 1992.
>
> --
> 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: Ed W @ 2011-05-21 19:57 UTC (permalink / raw)
To: Paul van der Vlis; +Cc: linux-raid
In-Reply-To: <4DD7EF40.1030506@vandervlis.nl>
Hi
>> The only other option that I think the big hosting guys use is to have a
>> netboot setup which boots everything and can also offer rescue images,
>> etc. Beyond my skills to setup for my meagre number of servers, but if
>> you have more than a couple of machines this could be a very good solution?
>
> I don't have much machines, but I have my own IPv4 range.
> So it is possible.
You don't actually need any range to make netboot work (kind of). Bear
in mind I have never done this... But you arrange for netboot to boot
from some internal server and in fact try and use your firewall to stop
the machines being visible to the outside world during this process
(think about various ways you can netboot to say some 192.168.x.y range
and if required say bounce ssh off some other machine to your server in
rescue mode (I just use the IPMI port so I don't need the machine to
have any working network access at all)
>> For my needs the USB stick option is perfect
>
> I will think about it. A little disadvantage is that it's not so easy to
> have access to the USB stick maybe (you have to open the machine).
Why would you ever need to access the USB stick?
As several other people already said - NOT being able to access it is a
bonus.. I would recommend superglue/cable-ties if you can't put the
stick inside the machine...
>> Sysrescuecd suits me because all my servers are gentoo based - clearly
>> it will work for other distros also, but you might want to evaluate
>> other rescue distros before choosing one?
>
> I use Debian, so I think I would choose a Debian-based rescue system.
Sure - but don't get too bogged down in the source distro. Sysrescuecd
will have a bang up to date set of binaries, likely far newer than those
on your live debian machine. It's really a question of whether that's a
benefit or liability...
For any work on the machine you simply chroot into the live machine and
then you are using all identical binaries (in fact the live machine) and
so really all you need is a boot environment which will support your
chosen raid/lvm/cpu architecture
>
> What still a question is for me:
> Is it better to put /boot on such an usb-stick or only the MBR?
Why pick only one?
I use a small raid 1 partition for /boot which mirrors across all 4
disks in my 1U servers. I try and install boot sectors on all drives so
I could in theory boot off any disk
Then I customise my sysrescuecd bootloader menu to
- boot the USB stick,
- rebuild the grub bootsector
- Boot drive 1
- Boot drive 2
- ...
For icing you could backup the /boot from the disks onto the USB stick,
but I haven't done that since it can be easily rebuilt (it's just the
kernel, grub boot files and grub.conf)
> Grub2 can boot from lvm/raid, and when I would have /boot on disk I can
I don't see any reason to deviate from the "small raid 1 boot partition"
idea. Needs only grub1 and no special handling?
> have an MBR on disks too (for the case the usb stick would fail).
I would suggest you boot from the disks first and set your USB stick as
the failover boot drive, and make sure it's boot menu picks to boot from
say disk2 as the default option? This covers you for the case that
someone pinches disk1 and reboots the machine, but your normal process
of maintaining the boot partition on the local disks holds
The USB drive then remains read-only, so no chance to bugger it up
accidently and you can churn out dozens for a tiny budget and re-use
them for quite some years
I can think of few downsides assuming you figure out how to make the
blasted things boot (not always easy) and can fit them inside the server
or similar?
> But difficult for me to understand that things like the initrd comes
> from a software raid....
Just don't make the boot process complicated...
I'm a ludite, I build my kernel with everything needed to boot builtin,
therefore no initrd needed (unless you want root on an md partition
that's not 0.90 format?). I can't cope with rebuilding initrds and all
that jazz... Now you can just update bzImage to update, plus you can
boot from any disk without treating it as raid at all (it's read only,
so with a 0.90 raid format you can use disks individually with GRUB -
mount them as a raid1 to modify them and they all stay in sync)
Easy peasy
> Another way would be make a /boot on a raid1 with 3 devices: the
> harddisks and the USB stick.
I just don't see that /boot is that precious? You probably have the
same info on every single other server you own (assuming you build same
kernels on all). Raid1 it across all your drives, then all you need is
the "boot sector" to be copied to more than one place and you do that by
copying it to all drives, plus having a bootable USB drive.
Remember a bootable disk (say USB) can then boot the /boot partition
from any other disk. All you are trying to do is get to the point that
grub (etc) is running and shows you some menu of choices (and picks
sensible default choices) - the rest is easy
I think you are probably not seeing how simple this really is? Have a
read through the above again if you still think you need custom USB
sticks or some complex raid1 scenario? It should just work very simply
and even with limited bios options, as long as you can boot from one
disk and one USB stick then you have a failover
Good luck
Ed W
^ permalink raw reply
* RE: HBA Adaptor advice
From: Leslie Rhorer @ 2011-05-21 17:37 UTC (permalink / raw)
To: 'Ed W', 'Rudy Zijlstra'
Cc: 'Stan Hoeppner', linux-raid
In-Reply-To: <4DD7A80C.8050808@wildgooses.com>
> -----Original Message-----
> From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
> owner@vger.kernel.org] On Behalf Of Ed W
> Sent: Saturday, May 21, 2011 6:55 AM
> To: Rudy Zijlstra
> Cc: Stan Hoeppner; linux-raid@vger.kernel.org
> Subject: Re: HBA Adaptor advice
>
> Hi
>
> > I understand your thinking. There is one big cost not mentioned in this
> > calculation though:
> > - what is the cost if the data is lost/corrupt?
>
> I think it's fair to say that the loss of all your business data is the
> loss of your entire business?!
If a single device failure results in the loss of all one's business
data, then one has done a completely incompetent job of building a data
system. In a properly designed system, the question is how much time and
effort will be spent over the life of the system in recovering data, or more
properly the cost of those resources, vs. the capital outlay for more
expensive hardware. If any loss of productivity for the company as a whole
is involved with a hardware failure, then that should be taken into account,
as well.
> That said if you are Skype you don't spend 8.5 billion on raid cards,
> instead you choose a layered approach to availability which normally
> trades speed of restore time vs cost.
>
> Eg one might specify raid 6, dual mirrored servers, backed up to some
> spare disks, blueray and some offsite storage service. This would give
> resilliance to various types of disaster without spending the entire
> budget on a fancy raid card?
>
> In fact if you go back to my question, the *entire* point is that I
> don't want the choice of card to be a point of failure, ie it's my
> specific point to purchase a card such that it can be swapped out for
> near any other card in the event of failure.
>
> > compared to that cost, how relevant is the cost of a proper card?
>
> See point above. I don't get a strong feeling that a "proper card" is
> any more reliable and resiliant than a well chosen cheap card? If that
> theory is correct then the ability to swap in another cheap card in the
> event of disaster is valuable and eliminates a point of failure for
> little cost?
Well, yes, and no. First of all, a "bad" card is often the result
of random factors unmitigated by any process. The most expensive card on
Earth may have accidentally been exposed to ESD at some point in its
existence, for example. OTOH, an inexpensive card may not necessarily be of
poor quality or design. That said, I think there is a reasonable
expectation that a higher cost card should be the result of careful
engineering, high quality production methods, and extensive QC procedures,
all of which may be somewhat less likely of a lower cost card.
I think on average one may expect lower failure rates on higher cost
devices. The thing is, a statistical average has nothing to do with any
given failure. A customer does not care if he is the only client who has
ever lost any data out of hundreds of clients. He only cares that he has
lost his data.
> > I am getting the feeling of "penny wise, pound foolish"
>
> I don't see that your logic leads here?
>
> There is a clear definition of good/bad here. The only acceptable
> performance is that all reads/writes are accurate and completed. No
> data should be lost or corrupted. Assuming that the market can be
> partitioned into good/bad cards based on the definition above, then if
> we select from only "good" cards, then price appears to only buy me
> performance, nothing else?
I would say there are exceptions, but in general, yes. More to the
point - and I think this is your point - relying upon quality hardware to
prevent failures is a much poorer approach than developing a strategy that
mitigates the impact of failures. Put more simply, a proper backup strategy
is a must.
> So my question is how to choose from all the "good" cards, the best bang
> for buck. I don't see any reason not to buy a cheaper card that
> performs well, subject to it being reliable and doesn't loose data.
>
> Does someone have a claim that dataloss is actually on a curve and that
> more expensive cards corrupt less data and cheaper cards corrupt more
> data... That doesn't seem to fit with expectation... (I expect either
> working cards that loose nothing, or bad cards that loose some data.
> Black and white)
Well, yes, but there is a (fairly minor, I think) statistical
correlation between cost and failure rates.
> > Now that mind set, of course, describes many a business....
>
> I think this is a silly line of argument. All you can ever do is buy
> "insurance" against low probability events occuring. Annoyingly the
> "insurance" in this scenario doesn't always pay out and so the question
> is how much to spend on orthogonal types of insurance to increase the
> chance of a payout in the case of disaster...
>
> It's always easy in the event of some disaster to point out how you
> should have bought some different type of "insurance", but equally it's
> also dead money that a business could spend to generate income...
> Balancing funding between profitable activities and insurance is a fine
> line (especially since you are insuring against infrequent events)
>
> As engineers, yes it's always easy to prefer to spend money on technical
> "insurance", but accept also that there are competing demands on where
> cash gets deployed to earn a return?
Well, there is a big difference between "insurance" in the ordinary
sense, which is to say a recurring premium paid ad infinitum and a one time
capital outlay that offers greater reliability for the indefinite future.
In addition, depending upon the application, performance does have value.
All that said, I agree that as long as the performance is acceptable, and as
long as the average reliability is reasonable, the lower cost solution
coupled with a solid backup strategy is the better choice.
^ permalink raw reply
* RE: HBA Adaptor advice
From: Leslie Rhorer @ 2011-05-21 17:05 UTC (permalink / raw)
To: 'Rudy Zijlstra', 'Ed W'
Cc: 'Stan Hoeppner', linux-raid
In-Reply-To: <4DD7A205.8070106@grumpydevil.homelinux.org>
> -----Original Message-----
> From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
> owner@vger.kernel.org] On Behalf Of Rudy Zijlstra
> Sent: Saturday, May 21, 2011 6:29 AM
> To: Ed W
> Cc: Stan Hoeppner; linux-raid@vger.kernel.org
> Subject: Re: HBA Adaptor advice
>
> Hi Ed,
>
> I understand your thinking. There is one big cost not mentioned in this
> calculation though:
> - what is the cost if the data is lost/corrupt?
>
> compared to that cost, how relevant is the cost of a proper card?
>
> I am getting the feeling of "penny wise, pound foolish"
Well, not necessarily. Your point is taken, but some data is simply
not critical. A backup system, for example, may not be as critical as a
main system. There are also some cases where availability is quite properly
deemed more important than reliability.
^ permalink raw reply
* Re: Software raid, booting and bios
From: Paul van der Vlis @ 2011-05-21 16:58 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <4DD6BD65.7020702@wildgooses.com>
Op 20-05-11 21:13, Ed W schreef:
> On 20/05/2011 09:33, Paul van der Vlis 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".
>
> Hi, what I have done with all my supermicro servers is to buy a tiny USB
> flash drive (physically small, not capacity small) - I think what I
> bought might be one of the tiny PNY devices, not sure though
>
> The Supermicro boards have internal USB headers mounted on the
> motherboard, even with a 1U server I have plenty of room to install my
> USB on the MB (could stick them out the back of the server and cable tie
> them (or superglue them))
Nice to hear.
> Then I put SysrescueCD on my stick and setup GRUB with a bunch of boot
> options.
>
> In my case I'm under the possibly misguided apprehension that my boot
> will fail over to the spare disks if one fails. However, I can set the
> subsequent failover to be my USB stick also. I think I have them set at
> the moment that the USB stick boots the main drives as normal, but has a
> boot menu where I can also boot the sysrescueimage if I need to (I use
> this (over IPMI) for initial system installation and serious
> maintenance, eg failed grub upgrade or similar).
Interesting.
> The only other option that I think the big hosting guys use is to have a
> netboot setup which boots everything and can also offer rescue images,
> etc. Beyond my skills to setup for my meagre number of servers, but if
> you have more than a couple of machines this could be a very good solution?
I don't have much machines, but I have my own IPv4 range.
So it is possible.
> For my needs the USB stick option is perfect
I will think about it. A little disadvantage is that it's not so easy to
have access to the USB stick maybe (you have to open the machine).
> Sysrescuecd suits me because all my servers are gentoo based - clearly
> it will work for other distros also, but you might want to evaluate
> other rescue distros before choosing one?
I use Debian, so I think I would choose a Debian-based rescue system.
What still a question is for me:
Is it better to put /boot on such an usb-stick or only the MBR?
Grub2 can boot from lvm/raid, and when I would have /boot on disk I can
have an MBR on disks too (for the case the usb stick would fail).
But difficult for me to understand that things like the initrd comes
from a software raid....
Another way would be make a /boot on a raid1 with 3 devices: the
harddisks and the USB stick.
With regards,
Paul van der Vlis.
--
http://www.vandervlis.nl/
^ permalink raw reply
* Re: Software raid, booting and bios
From: Paul van der Vlis @ 2011-05-21 16:43 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <4DD63BC3.3010009@gmail.com>
Op 20-05-11 12:00, Simon McNair schreef:
> 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).
It's not easy. I have machines in production and I had to reboot them to
do this. And I want to buy a new machine, but I don't have it yet.
> Can you ask you rack space vendor the specific question 'how do I set up
> a secondary boot device ?".
I can talk with them about it, but I think in most cases the first
device will be detected, so the second device will not be used.
With regards,
Paul van der Vlis.
^ permalink raw reply
* Re: Performarce raid6 degraded
From: NeilBrown @ 2011-05-21 12:37 UTC (permalink / raw)
To: Pol Hallen; +Cc: Linux-RAID
In-Reply-To: <201105211316.18565.raid1@fuckaround.org>
On Sat, 21 May 2011 13:16:18 +0200 Pol Hallen <raid1@fuckaround.org> wrote:
> Hi folks, after fail of a disk on my raid6 sw I check with dd the performance
> of raid:
>
> dd if=/dev/zero of=degradedraid bs=1000024 count=100
> 100+0 records in
> 100+0 records out
> 100002400 bytes (100 MB) copied, 288.254 s, 347 kB/s
>
> is it correct? only 347Kb/s on a raid6 degraded?
What was it when the array was not degraded?
1000024 is a rather strange block size to use. Try a power of 2 and see if
it makes a difference.
I would expect large sequential writes to go at much the same speed as
non-degraded, but smaller or non-aligned writes could certainly go more
slowly - maybe half speed at a guess.
NeilBrown
>
> mdadm --detail /dev/md0
> /dev/md0:
> Version : 0.90
> Creation Time : Mon Sep 27 14:19:15 2010
> Raid Level : raid6
> Array Size : 5860543744 (5589.05 GiB 6001.20 GB)
> Used Dev Size : 1465135936 (1397.26 GiB 1500.30 GB)
> Raid Devices : 6
> Total Devices : 7
> Preferred Minor : 0
> Persistence : Superblock is persistent
>
> Update Time : Sat May 21 13:14:43 2011
> State : active, degraded
> Active Devices : 5
> Working Devices : 5
> Failed Devices : 2
> Spare Devices : 0
>
> Layout : left-symmetric
> Chunk Size : 64K
>
> UUID : 9bd6372e:e2eab1d5:d2bdc3cb:ad12f41d
> Events : 0.385693
>
> Number Major Minor RaidDevice State
> 0 8 1 0 active sync /dev/sda1
> 1 8 17 1 active sync /dev/sdb1
> 2 0 0 2 removed
> 3 8 81 3 active sync /dev/sdf1
> 4 8 65 4 active sync /dev/sde1
> 5 8 49 5 active sync /dev/sdd1
>
> 6 8 145 - faulty spare
> 7 8 33 - faulty spare
>
> thanks!
>
> Pol
> --
> 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 git, -Werror=unused-but-set-variable
From: Mathias Burén @ 2011-05-21 12:32 UTC (permalink / raw)
To: NeilBrown; +Cc: Linux-RAID
In-Reply-To: <20110521222718.55ac4bae@notabene.brown>
On 21 May 2011 13:27, NeilBrown <neilb@suse.de> wrote:
> On Sat, 21 May 2011 11:20:01 +0100 Mathias Burén <mathias.buren@gmail.com>
> wrote:
>
>> The git as of today "fails" to compile on my Archlinux system:
>>
>> ==> Starting build()...
>> ==> Fetching sources...
>> Cloning into ./mdadm...
>> remote: Counting objects: 9107, done.
>> remote: Compressing objects: 100% (6096/6096), done.
>> remote: Total 9107 (delta 6874), reused 3903 (delta 3004)
>> Receiving objects: 100% (9107/9107), 2.46 MiB | 12 KiB/s, done.
>> Resolving deltas: 100% (6874/6874), done.
>> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
>> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
>> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
>> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
>> -DMDMON_DIR=\"/dev/.mdadm\"
>> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
>> mdadm.o mdadm.c
>> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
>> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
>> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
>> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
>> -DMDMON_DIR=\"/dev/.mdadm\"
>> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
>> config.o config.c
>> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
>> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
>> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
>> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
>> -DMDMON_DIR=\"/dev/.mdadm\"
>> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
>> policy.o policy.c
>> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
>> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
>> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
>> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
>> -DMDMON_DIR=\"/dev/.mdadm\"
>> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
>> mdstat.o mdstat.c
>> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
>> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
>> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
>> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
>> -DMDMON_DIR=\"/dev/.mdadm\"
>> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
>> ReadMe.o ReadMe.c
>> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
>> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
>> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
>> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
>> -DMDMON_DIR=\"/dev/.mdadm\"
>> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
>> util.o util.c
>> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
>> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
>> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
>> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
>> -DMDMON_DIR=\"/dev/.mdadm\"
>> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
>> maps.o maps.c
>> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
>> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
>> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
>> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
>> -DMDMON_DIR=\"/dev/.mdadm\"
>> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
>> lib.o lib.c
>> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
>> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
>> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
>> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
>> -DMDMON_DIR=\"/dev/.mdadm\"
>> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
>> Manage.o Manage.c
>> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
>> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
>> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
>> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
>> -DMDMON_DIR=\"/dev/.mdadm\"
>> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
>> Assemble.o Assemble.c
>> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
>> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
>> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
>> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
>> -DMDMON_DIR=\"/dev/.mdadm\"
>> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
>> Build.o Build.c
>> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
>> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
>> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
>> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
>> -DMDMON_DIR=\"/dev/.mdadm\"
>> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
>> Create.o Create.c
>> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
>> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
>> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
>> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
>> -DMDMON_DIR=\"/dev/.mdadm\"
>> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
>> Detail.o Detail.c
>> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
>> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
>> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
>> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
>> -DMDMON_DIR=\"/dev/.mdadm\"
>> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
>> Examine.o Examine.c
>> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
>> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
>> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
>> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
>> -DMDMON_DIR=\"/dev/.mdadm\"
>> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
>> Grow.o Grow.c
>> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
>> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
>> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
>> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
>> -DMDMON_DIR=\"/dev/.mdadm\"
>> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
>> Monitor.o Monitor.c
>> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
>> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
>> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
>> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
>> -DMDMON_DIR=\"/dev/.mdadm\"
>> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
>> dlink.o dlink.c
>> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
>> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
>> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
>> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
>> -DMDMON_DIR=\"/dev/.mdadm\"
>> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
>> Kill.o Kill.c
>> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
>> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
>> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
>> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
>> -DMDMON_DIR=\"/dev/.mdadm\"
>> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
>> Query.o Query.c
>> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
>> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
>> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
>> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
>> -DMDMON_DIR=\"/dev/.mdadm\"
>> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
>> Incremental.o Incremental.c
>> Query.c: In function ‘Query’:
>> Query.c:38:16: error: variable ‘superrno’ set but not used
>> [-Werror=unused-but-set-variable]
>> cc1: all warnings being treated as errors
>>
>> make: *** [Query.o] Error 1
>> make: *** Waiting for unfinished jobs....
>> ==> ERROR: A failure occurred in build().
>> Aborting...
>>
>> This with gcc 4.6.0.
>>
>> Regards,
>> /M
>
> Thanks for the report.
> This patch will go in in the near future.
> (The variable has been unused since 2005 !!!)
>
> Thanks,
> NeilBrown
>
> diff --git a/Query.c b/Query.c
> index f9857d6..0b15e28 100644
> --- a/Query.c
> +++ b/Query.c
> @@ -35,7 +35,7 @@ int Query(char *dev)
> int fd = open(dev, O_RDONLY);
> int vers;
> int ioctlerr;
> - int superror, superrno;
> + int superror;
> struct mdinfo info;
> mdu_array_info_t array;
> struct supertype *st = NULL;
> @@ -82,10 +82,9 @@ int Query(char *dev)
> array.spare_disks, array.spare_disks==1?"":"s");
> }
> st = guess_super(fd);
> - if (st) {
> + if (st)
> superror = st->ss->load_super(st, fd, dev);
> - superrno = errno;
> - } else
> + else
> superror = -1;
> close(fd);
> if (superror == 0) {
>
2005, hah! Thanks :)
/M
--
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 git, -Werror=unused-but-set-variable
From: NeilBrown @ 2011-05-21 12:27 UTC (permalink / raw)
To: Mathias Burén; +Cc: Linux-RAID
In-Reply-To: <BANLkTinf5OaDXN5KMrdP5ZOCADS=zXRwnQ@mail.gmail.com>
On Sat, 21 May 2011 11:20:01 +0100 Mathias Burén <mathias.buren@gmail.com>
wrote:
> The git as of today "fails" to compile on my Archlinux system:
>
> ==> Starting build()...
> ==> Fetching sources...
> Cloning into ./mdadm...
> remote: Counting objects: 9107, done.
> remote: Compressing objects: 100% (6096/6096), done.
> remote: Total 9107 (delta 6874), reused 3903 (delta 3004)
> Receiving objects: 100% (9107/9107), 2.46 MiB | 12 KiB/s, done.
> Resolving deltas: 100% (6874/6874), done.
> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
> -DMDMON_DIR=\"/dev/.mdadm\"
> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
> mdadm.o mdadm.c
> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
> -DMDMON_DIR=\"/dev/.mdadm\"
> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
> config.o config.c
> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
> -DMDMON_DIR=\"/dev/.mdadm\"
> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
> policy.o policy.c
> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
> -DMDMON_DIR=\"/dev/.mdadm\"
> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
> mdstat.o mdstat.c
> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
> -DMDMON_DIR=\"/dev/.mdadm\"
> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
> ReadMe.o ReadMe.c
> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
> -DMDMON_DIR=\"/dev/.mdadm\"
> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
> util.o util.c
> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
> -DMDMON_DIR=\"/dev/.mdadm\"
> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
> maps.o maps.c
> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
> -DMDMON_DIR=\"/dev/.mdadm\"
> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
> lib.o lib.c
> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
> -DMDMON_DIR=\"/dev/.mdadm\"
> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
> Manage.o Manage.c
> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
> -DMDMON_DIR=\"/dev/.mdadm\"
> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
> Assemble.o Assemble.c
> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
> -DMDMON_DIR=\"/dev/.mdadm\"
> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
> Build.o Build.c
> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
> -DMDMON_DIR=\"/dev/.mdadm\"
> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
> Create.o Create.c
> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
> -DMDMON_DIR=\"/dev/.mdadm\"
> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
> Detail.o Detail.c
> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
> -DMDMON_DIR=\"/dev/.mdadm\"
> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
> Examine.o Examine.c
> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
> -DMDMON_DIR=\"/dev/.mdadm\"
> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
> Grow.o Grow.c
> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
> -DMDMON_DIR=\"/dev/.mdadm\"
> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
> Monitor.o Monitor.c
> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
> -DMDMON_DIR=\"/dev/.mdadm\"
> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
> dlink.o dlink.c
> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
> -DMDMON_DIR=\"/dev/.mdadm\"
> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
> Kill.o Kill.c
> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
> -DMDMON_DIR=\"/dev/.mdadm\"
> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
> Query.o Query.c
> gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
> -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
> -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
> -DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
> -DMDMON_DIR=\"/dev/.mdadm\"
> -DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
> Incremental.o Incremental.c
> Query.c: In function ‘Query’:
> Query.c:38:16: error: variable ‘superrno’ set but not used
> [-Werror=unused-but-set-variable]
> cc1: all warnings being treated as errors
>
> make: *** [Query.o] Error 1
> make: *** Waiting for unfinished jobs....
> ==> ERROR: A failure occurred in build().
> Aborting...
>
> This with gcc 4.6.0.
>
> Regards,
> /M
Thanks for the report.
This patch will go in in the near future.
(The variable has been unused since 2005 !!!)
Thanks,
NeilBrown
diff --git a/Query.c b/Query.c
index f9857d6..0b15e28 100644
--- a/Query.c
+++ b/Query.c
@@ -35,7 +35,7 @@ int Query(char *dev)
int fd = open(dev, O_RDONLY);
int vers;
int ioctlerr;
- int superror, superrno;
+ int superror;
struct mdinfo info;
mdu_array_info_t array;
struct supertype *st = NULL;
@@ -82,10 +82,9 @@ int Query(char *dev)
array.spare_disks, array.spare_disks==1?"":"s");
}
st = guess_super(fd);
- if (st) {
+ if (st)
superror = st->ss->load_super(st, fd, dev);
- superrno = errno;
- } else
+ else
superror = -1;
close(fd);
if (superror == 0) {
--
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: Ed W @ 2011-05-21 11:54 UTC (permalink / raw)
To: Rudy Zijlstra; +Cc: Stan Hoeppner, linux-raid
In-Reply-To: <4DD7A205.8070106@grumpydevil.homelinux.org>
Hi
> I understand your thinking. There is one big cost not mentioned in this
> calculation though:
> - what is the cost if the data is lost/corrupt?
I think it's fair to say that the loss of all your business data is the
loss of your entire business?!
That said if you are Skype you don't spend 8.5 billion on raid cards,
instead you choose a layered approach to availability which normally
trades speed of restore time vs cost.
Eg one might specify raid 6, dual mirrored servers, backed up to some
spare disks, blueray and some offsite storage service. This would give
resilliance to various types of disaster without spending the entire
budget on a fancy raid card?
In fact if you go back to my question, the *entire* point is that I
don't want the choice of card to be a point of failure, ie it's my
specific point to purchase a card such that it can be swapped out for
near any other card in the event of failure.
> compared to that cost, how relevant is the cost of a proper card?
See point above. I don't get a strong feeling that a "proper card" is
any more reliable and resiliant than a well chosen cheap card? If that
theory is correct then the ability to swap in another cheap card in the
event of disaster is valuable and eliminates a point of failure for
little cost?
> I am getting the feeling of "penny wise, pound foolish"
I don't see that your logic leads here?
There is a clear definition of good/bad here. The only acceptable
performance is that all reads/writes are accurate and completed. No
data should be lost or corrupted. Assuming that the market can be
partitioned into good/bad cards based on the definition above, then if
we select from only "good" cards, then price appears to only buy me
performance, nothing else?
So my question is how to choose from all the "good" cards, the best bang
for buck. I don't see any reason not to buy a cheaper card that
performs well, subject to it being reliable and doesn't loose data.
Does someone have a claim that dataloss is actually on a curve and that
more expensive cards corrupt less data and cheaper cards corrupt more
data... That doesn't seem to fit with expectation... (I expect either
working cards that loose nothing, or bad cards that loose some data.
Black and white)
> Now that mind set, of course, describes many a business....
I think this is a silly line of argument. All you can ever do is buy
"insurance" against low probability events occuring. Annoyingly the
"insurance" in this scenario doesn't always pay out and so the question
is how much to spend on orthogonal types of insurance to increase the
chance of a payout in the case of disaster...
It's always easy in the event of some disaster to point out how you
should have bought some different type of "insurance", but equally it's
also dead money that a business could spend to generate income...
Balancing funding between profitable activities and insurance is a fine
line (especially since you are insuring against infrequent events)
As engineers, yes it's always easy to prefer to spend money on technical
"insurance", but accept also that there are competing demands on where
cash gets deployed to earn a return?
Cheers
Ed W
^ permalink raw reply
* Re: HBA Adaptor advice
From: Rudy Zijlstra @ 2011-05-21 11:29 UTC (permalink / raw)
To: Ed W; +Cc: Stan Hoeppner, linux-raid
In-Reply-To: <4DD79F4E.7000509@wildgooses.com>
Hi Ed,
I understand your thinking. There is one big cost not mentioned in this
calculation though:
- what is the cost if the data is lost/corrupt?
compared to that cost, how relevant is the cost of a proper card?
I am getting the feeling of "penny wise, pound foolish"
Now that mind set, of course, describes many a business....
Cheers,
Rudy
On 05/21/2011 01:17 PM, Ed W wrote:
> Hi Stan
>
> Thanks for the time in composing your reply
>
>
>> I'm curious why you are convinced that you need BBWC, or even simply WC,
>> on an HBA used for md RAID.
>>
> In the past I have used battery backed cards and where the write speed
> is "fsync constrained" the writeback cache makes the app performance fly
> at perhaps 10-100x the speed
>
> So for example postfix delivery speeds and mysql write performance are
> examples of applications which generate regular fsyncs. The whole app
> pauses for basically the seek time of the drive head and performance is
> bounded by seek time (assuming spinning media).
>
> If we add a writeback cache then it would appear that you take a couple
> of "green" 2TB drives and suddenly your desktop server acquires short
> term performance which matches a bunch of high end drives? (noted only
> in bursts, after some seconds you catch up with the drives IOPs). For
> my basically "small server" requirements this gives me a big boost in
> the feeling of interactivity for perhaps less than the price of a couple
> of those high end drives
>
>
>
>> I'm also curious as to why you are so
>> adamant about _not_ using the RAID ASIC on an HBA, given that it will
>> take much greater advantage of the BBWC than md RAID will.
>>
> Only for a single reason: Its a small office server and I want the
> flexibility to move the drives to a different card (eg failed server,
> failed card or something else). Buying a spare card changes the
> dynamics quite a bit when the whole server (sans raid card) only costs
> £1,000 ish?
>
>
> You may be
>
>> interested to know:
>>
>> 1. When BBWC is enabled, all internal drive caches must be disabled.
>> Otherwise you eliminate the design benefit of the BBU, and may as
>> well not have one.
>>
> Yes, I hadn't thought of that. Good point!
>
>
>> 2. w/md RAID on an HBA, if you have a good UPS and don't suffer
>> kernel panics, crashes, etc, you can disable barrier support in
>> your FS and you can use the drive caches.
>>
> I don't buy this...
>
> Note we are discussing "long tail events" here. ie catastrophic events
> which occur very infrequently. At this point experience is everything
> and I concede limited experience, you likely have more, but I'm going to
> claim that these events are sufficiently rare that your experience
> probably still isn't sufficient to draw proper conclusions...
>
> In my limited experience hardware is pretty reliable and goes bad
> rarely. However, my estimate is that powercables fall out, PSUs fail
> and UPSs go bad at least as often as the power fails?
>
> Obviously it's application dependent, some may tolerate small dataloss
> in the event of powerdown, but I should think most people want a
> guarantee that the system is "recoverable" in the event of sudden
> powerdown.
>
> I think disabling barriers might not be the best way to avoid fsync
> delays, compared with the incremental cost of adding BBU writeback
> cache? (basically the same thing, but smaller chance of failure)
>
>
>
>> For a stable system with good UPS and auto shutdown configured, BBWC is
>> totally overrated. If the system never takes a nose dive from power
>> drop, and doesn't crash due to software or hardware failure, then BBWC
>> is a useless $200-1000 option.
>>
> It depends on the application, but I claim that there is a fairly
> significant chance of hard unexpected powerdown even with a good UPS.
> You still are at risk from cables getting pulled, UPSs failing, etc
>
> I think in a properly setup datacenter (racked) environment then it's
> easier to control these accidents. Cables can be tied in, layers of
> power backup can be managed, it becomes efficient to add quality
> surge/lightning protection, etc. However, there is a large proportion
> of the market that have a few machines in an office and now it's much
> harder to stop the cleaner tripping over the UPS, or hiding it under
> boxes of paper until it melts due to overheating...
>
>
>
>> If your current reasoning for wanting write cache on the HBA is
>> performance, then forget about the write cache as you don't need it with
>> md RAID. If you want the BBWC combo for safety as your system isn't
>> stable or you have a crappy or no UPS, then forgo md RAID and use the
>> hardware RAID and BBWC combo.
>>
> I want BB writeback cache purely to get the performance of effectively
> disabling fsync, but without the loss of protection which occurs if you
> do so.
>
>
>
>> One last point: If you're bargain hunting, especially if looking at
>> used gear on Ebay, that mindset is antithetical to proper system
>> integration, especially when talking about a RAID card BBU.
>>
> I think there are few businesses who actually don't care about budget.
> Everything is about optimisation of cost vs performance vs reliability.
> Like everything else, my question is really about the tradeoff of a
> small incremental spend, which in turn might generate a substantial
> performance increase for certain classes of application. Largely I'm
> thinking about performance tradeoffs for small office servers priced in
> the £500-3,000 kind of range (not "proper" high end storage devices)
>
> I think at that kind of level it makes sense to look for bargains,
> especially if you are adding servers in small quantities, eg singles or
> pairs.
>
>
>
>> If you buy
>> a use card, the first thing you muse do is chuck the BBU and order a new
>> one,
>>
> Agreed
>
>
>
>> Buy 12:
>> http://www.seagate.com/ww/v/index.jsp?name=st91000640ss-constellation2-6gbs-sas-1-tb-hd&vgnextoid=ff13c5b2933d9210VgnVCM1000001a48090aRCRD&vgnextchannel=f424072516d8c010VgnVCM100000dd04090aRCRD&locale=en-US&reqPage=Support#tTabContentSpecifications
>>
> Out of curiosity I check the power consumption and reliability numbers
> of the 3.5" "Green" drives and it's not so clear cut that the 2.5"
> drives outperform?
>
>
> Thanks for your thoughts - I think this thread has been very
> constructive - still very interested to hear good/bad reports of
> specific cards - perhaps someone might archive it into some kind of list?
>
> Cheers
>
> 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
>
--
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-21 11:17 UTC (permalink / raw)
To: Stan Hoeppner; +Cc: linux-raid
In-Reply-To: <4DD6409F.9070904@hardwarefreak.com>
Hi Stan
Thanks for the time in composing your reply
> I'm curious why you are convinced that you need BBWC, or even simply WC,
> on an HBA used for md RAID.
In the past I have used battery backed cards and where the write speed
is "fsync constrained" the writeback cache makes the app performance fly
at perhaps 10-100x the speed
So for example postfix delivery speeds and mysql write performance are
examples of applications which generate regular fsyncs. The whole app
pauses for basically the seek time of the drive head and performance is
bounded by seek time (assuming spinning media).
If we add a writeback cache then it would appear that you take a couple
of "green" 2TB drives and suddenly your desktop server acquires short
term performance which matches a bunch of high end drives? (noted only
in bursts, after some seconds you catch up with the drives IOPs). For
my basically "small server" requirements this gives me a big boost in
the feeling of interactivity for perhaps less than the price of a couple
of those high end drives
> I'm also curious as to why you are so
> adamant about _not_ using the RAID ASIC on an HBA, given that it will
> take much greater advantage of the BBWC than md RAID will.
Only for a single reason: Its a small office server and I want the
flexibility to move the drives to a different card (eg failed server,
failed card or something else). Buying a spare card changes the
dynamics quite a bit when the whole server (sans raid card) only costs
£1,000 ish?
You may be
> interested to know:
>
> 1. When BBWC is enabled, all internal drive caches must be disabled.
> Otherwise you eliminate the design benefit of the BBU, and may as
> well not have one.
Yes, I hadn't thought of that. Good point!
> 2. w/md RAID on an HBA, if you have a good UPS and don't suffer
> kernel panics, crashes, etc, you can disable barrier support in
> your FS and you can use the drive caches.
I don't buy this...
Note we are discussing "long tail events" here. ie catastrophic events
which occur very infrequently. At this point experience is everything
and I concede limited experience, you likely have more, but I'm going to
claim that these events are sufficiently rare that your experience
probably still isn't sufficient to draw proper conclusions...
In my limited experience hardware is pretty reliable and goes bad
rarely. However, my estimate is that powercables fall out, PSUs fail
and UPSs go bad at least as often as the power fails?
Obviously it's application dependent, some may tolerate small dataloss
in the event of powerdown, but I should think most people want a
guarantee that the system is "recoverable" in the event of sudden
powerdown.
I think disabling barriers might not be the best way to avoid fsync
delays, compared with the incremental cost of adding BBU writeback
cache? (basically the same thing, but smaller chance of failure)
> For a stable system with good UPS and auto shutdown configured, BBWC is
> totally overrated. If the system never takes a nose dive from power
> drop, and doesn't crash due to software or hardware failure, then BBWC
> is a useless $200-1000 option.
It depends on the application, but I claim that there is a fairly
significant chance of hard unexpected powerdown even with a good UPS.
You still are at risk from cables getting pulled, UPSs failing, etc
I think in a properly setup datacenter (racked) environment then it's
easier to control these accidents. Cables can be tied in, layers of
power backup can be managed, it becomes efficient to add quality
surge/lightning protection, etc. However, there is a large proportion
of the market that have a few machines in an office and now it's much
harder to stop the cleaner tripping over the UPS, or hiding it under
boxes of paper until it melts due to overheating...
> If your current reasoning for wanting write cache on the HBA is
> performance, then forget about the write cache as you don't need it with
> md RAID. If you want the BBWC combo for safety as your system isn't
> stable or you have a crappy or no UPS, then forgo md RAID and use the
> hardware RAID and BBWC combo.
I want BB writeback cache purely to get the performance of effectively
disabling fsync, but without the loss of protection which occurs if you
do so.
> One last point: If you're bargain hunting, especially if looking at
> used gear on Ebay, that mindset is antithetical to proper system
> integration, especially when talking about a RAID card BBU.
I think there are few businesses who actually don't care about budget.
Everything is about optimisation of cost vs performance vs reliability.
Like everything else, my question is really about the tradeoff of a
small incremental spend, which in turn might generate a substantial
performance increase for certain classes of application. Largely I'm
thinking about performance tradeoffs for small office servers priced in
the £500-3,000 kind of range (not "proper" high end storage devices)
I think at that kind of level it makes sense to look for bargains,
especially if you are adding servers in small quantities, eg singles or
pairs.
> If you buy
> a use card, the first thing you muse do is chuck the BBU and order a new
> one,
Agreed
> Buy 12:
> http://www.seagate.com/ww/v/index.jsp?name=st91000640ss-constellation2-6gbs-sas-1-tb-hd&vgnextoid=ff13c5b2933d9210VgnVCM1000001a48090aRCRD&vgnextchannel=f424072516d8c010VgnVCM100000dd04090aRCRD&locale=en-US&reqPage=Support#tTabContentSpecifications
Out of curiosity I check the power consumption and reliability numbers
of the 3.5" "Green" drives and it's not so clear cut that the 2.5"
drives outperform?
Thanks for your thoughts - I think this thread has been very
constructive - still very interested to hear good/bad reports of
specific cards - perhaps someone might archive it into some kind of list?
Cheers
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
* Performarce raid6 degraded
From: Pol Hallen @ 2011-05-21 11:16 UTC (permalink / raw)
To: Linux-RAID
Hi folks, after fail of a disk on my raid6 sw I check with dd the performance
of raid:
dd if=/dev/zero of=degradedraid bs=1000024 count=100
100+0 records in
100+0 records out
100002400 bytes (100 MB) copied, 288.254 s, 347 kB/s
is it correct? only 347Kb/s on a raid6 degraded?
mdadm --detail /dev/md0
/dev/md0:
Version : 0.90
Creation Time : Mon Sep 27 14:19:15 2010
Raid Level : raid6
Array Size : 5860543744 (5589.05 GiB 6001.20 GB)
Used Dev Size : 1465135936 (1397.26 GiB 1500.30 GB)
Raid Devices : 6
Total Devices : 7
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Sat May 21 13:14:43 2011
State : active, degraded
Active Devices : 5
Working Devices : 5
Failed Devices : 2
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 64K
UUID : 9bd6372e:e2eab1d5:d2bdc3cb:ad12f41d
Events : 0.385693
Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
1 8 17 1 active sync /dev/sdb1
2 0 0 2 removed
3 8 81 3 active sync /dev/sdf1
4 8 65 4 active sync /dev/sde1
5 8 49 5 active sync /dev/sdd1
6 8 145 - faulty spare
7 8 33 - faulty spare
thanks!
Pol
^ permalink raw reply
* mdadm git, -Werror=unused-but-set-variable
From: Mathias Burén @ 2011-05-21 10:20 UTC (permalink / raw)
To: Linux-RAID, Neil Brown
The git as of today "fails" to compile on my Archlinux system:
==> Starting build()...
==> Fetching sources...
Cloning into ./mdadm...
remote: Counting objects: 9107, done.
remote: Compressing objects: 100% (6096/6096), done.
remote: Total 9107 (delta 6874), reused 3903 (delta 3004)
Receiving objects: 100% (9107/9107), 2.46 MiB | 12 KiB/s, done.
Resolving deltas: 100% (6874/6874), done.
gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
-ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
-DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
-DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
-DMDMON_DIR=\"/dev/.mdadm\"
-DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
mdadm.o mdadm.c
gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
-ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
-DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
-DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
-DMDMON_DIR=\"/dev/.mdadm\"
-DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
config.o config.c
gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
-ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
-DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
-DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
-DMDMON_DIR=\"/dev/.mdadm\"
-DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
policy.o policy.c
gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
-ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
-DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
-DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
-DMDMON_DIR=\"/dev/.mdadm\"
-DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
mdstat.o mdstat.c
gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
-ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
-DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
-DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
-DMDMON_DIR=\"/dev/.mdadm\"
-DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
ReadMe.o ReadMe.c
gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
-ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
-DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
-DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
-DMDMON_DIR=\"/dev/.mdadm\"
-DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
util.o util.c
gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
-ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
-DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
-DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
-DMDMON_DIR=\"/dev/.mdadm\"
-DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
maps.o maps.c
gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
-ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
-DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
-DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
-DMDMON_DIR=\"/dev/.mdadm\"
-DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
lib.o lib.c
gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
-ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
-DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
-DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
-DMDMON_DIR=\"/dev/.mdadm\"
-DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
Manage.o Manage.c
gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
-ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
-DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
-DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
-DMDMON_DIR=\"/dev/.mdadm\"
-DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
Assemble.o Assemble.c
gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
-ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
-DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
-DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
-DMDMON_DIR=\"/dev/.mdadm\"
-DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
Build.o Build.c
gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
-ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
-DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
-DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
-DMDMON_DIR=\"/dev/.mdadm\"
-DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
Create.o Create.c
gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
-ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
-DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
-DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
-DMDMON_DIR=\"/dev/.mdadm\"
-DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
Detail.o Detail.c
gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
-ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
-DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
-DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
-DMDMON_DIR=\"/dev/.mdadm\"
-DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
Examine.o Examine.c
gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
-ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
-DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
-DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
-DMDMON_DIR=\"/dev/.mdadm\"
-DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
Grow.o Grow.c
gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
-ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
-DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
-DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
-DMDMON_DIR=\"/dev/.mdadm\"
-DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
Monitor.o Monitor.c
gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
-ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
-DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
-DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
-DMDMON_DIR=\"/dev/.mdadm\"
-DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
dlink.o dlink.c
gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
-ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
-DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
-DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
-DMDMON_DIR=\"/dev/.mdadm\"
-DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
Kill.o Kill.c
gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
-ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
-DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
-DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
-DMDMON_DIR=\"/dev/.mdadm\"
-DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
Query.o Query.c
gcc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
-ggdb -DSendmail=\""/usr/sbin/sendmail -t"\"
-DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\"
-DMAP_DIR=\"/dev/.mdadm\" -DMAP_FILE=\"map\"
-DMDMON_DIR=\"/dev/.mdadm\"
-DFAILED_SLOTS_DIR=\"/dev/.mdadm/failed-slots\" -DUSE_PTHREADS -c -o
Incremental.o Incremental.c
Query.c: In function ‘Query’:
Query.c:38:16: error: variable ‘superrno’ set but not used
[-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors
make: *** [Query.o] Error 1
make: *** Waiting for unfinished jobs....
==> ERROR: A failure occurred in build().
Aborting...
This with gcc 4.6.0.
Regards,
/M
--
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-21 9:52 UTC (permalink / raw)
To: Stan Hoeppner; +Cc: linux-raid
In-Reply-To: <4DD5FC66.5020209@hardwarefreak.com>
On 20/05/2011 06:30, Stan Hoeppner wrote:
>> 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.
>
Something I didn't consider:
When you setup most hardware raid cards to have a whole bunch of RAID0
arrays (that are then assembled as software raid), *can* I swap that
hardware raid card for a different make/model or even non raid HBA?
If I can't do this then I don't want such a card... The entire point of
avoiding hardware raid was simply to avoid the proprietory lockin...
So, to be specific, given one of the LSI/3Ware/Areca fast hardware raid
cards mentioned in this thread, and assuming that I have created a bunch
of raid0 arrays, each containing 1 drive, can anyone confirm/deny if
those single disks than then be moved to a) non raid HBA controller, b)
another hardware raid controller as a new raid0 array
I'm rather expecting that a) might be possible if the HBA can ignore the
proprietory bit and see a raw partition, but b) seems highly unlikely
since the new controller presumably wants to reformat the array in it's
own format before it will use it?
If neither are possible then there seems little advantage in using a
hardware raid as a write caching HBA card (unless the card is too
underpowered that it's a bottleneck)
Thanks
Ed W
^ permalink raw reply
* RE: Software raid, booting and bios
From: Leslie Rhorer @ 2011-05-21 8:19 UTC (permalink / raw)
To: 'Brad Campbell', linux-raid
In-Reply-To: <4DD6E293.8000503@wasp.net.au>
> -----Original Message-----
> From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
> owner@vger.kernel.org] On Behalf Of Brad Campbell
> Sent: Friday, May 20, 2011 4:52 PM
> To: linux-raid@vger.kernel.org
> Subject: Re: Software raid, booting and bios
>
> On 21/05/11 03:32, Phil Turmel wrote:
>
> > the big deal is the lack of moving parts: No spindle bearing, no head
> positioner gear train.
>
> Sorry, this just tickled me. "gear train" ? Which decade are we talking
> about? The last drive I saw
> that had any form of mechanical power transfer mechanism for head
> positioning was a 60MB RLL Seagate
> clunker.
Yeah, the number of moving parts in a hard drive is minimal. OTOH,
it's not zero.
> Now, to add some form of use to the thread I've been using commodity CF
> cards in home-brew CF to ATA
> adaptors in embedded systems for 10 years. Flash is _the_ way to go for
> high reliability systems
> that don't have lots of write cycles.
>
> My TV box that has no on-board PXE has been booting from a 10MB USB stick
> using loadlinux since
> 2003. Dead reliable after ~69,000 hours power on time. I've not had a hard
> disk last that long since
> my old 200MB WD IDE drive (which is still running with over 100,000 hours
> on it).
Oh, we have quite a number of embedded controllers with SCSI hard
drives that have been spinning continuously since 1992.
^ permalink raw reply
* Western Digital giving away dual port pcie (2 lane) hba's
From: Daniel Reurich @ 2011-05-21 1:23 UTC (permalink / raw)
To: RAID Linux
Hi,
I got my hands on some of the hba's that Western Digital are providing
along with their 3TB Green power harddrives. They didn't cost any extra
then the bare drives. I believe the hba's are being supplied along with
the drives to get around a potential bios size limitation of ~ 2.3TB and
allow these drives to function correctly under windoze.
These hba's are a rocket raid 62X sporting a Marvell 88SE9125-NAA2
chipset.
Can anyone tell me whether these are going to be reliable enough to use
for extra sata ports in md raid scenarios?
Thanks,
--
Daniel Reurich.
Centurion Computer Technology (2005) Ltd
Mobile 021 797 722
^ permalink raw reply
* Re: Software raid, booting and bios
From: Brad Campbell @ 2011-05-20 21:52 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <4DD6C1EB.1030907@turmel.org>
On 21/05/11 03:32, Phil Turmel wrote:
> the big deal is the lack of moving parts: No spindle bearing, no head positioner gear train.
Sorry, this just tickled me. "gear train" ? Which decade are we talking about? The last drive I saw
that had any form of mechanical power transfer mechanism for head positioning was a 60MB RLL Seagate
clunker.
Now, to add some form of use to the thread I've been using commodity CF cards in home-brew CF to ATA
adaptors in embedded systems for 10 years. Flash is _the_ way to go for high reliability systems
that don't have lots of write cycles.
My TV box that has no on-board PXE has been booting from a 10MB USB stick using loadlinux since
2003. Dead reliable after ~69,000 hours power on time. I've not had a hard disk last that long since
my old 200MB WD IDE drive (which is still running with over 100,000 hours on it).
Brad
--
Dolphins are so intelligent that within a few weeks they can
train Americans to stand at the edge of the pool and throw them
fish.
^ permalink raw reply
* Re: Software raid, booting and bios
From: Roberto Spadim @ 2011-05-20 21:27 UTC (permalink / raw)
To: Phil Turmel; +Cc: Paul van der Vlis, linux-raid
In-Reply-To: <4DD6C1EB.1030907@turmel.org>
i´m using usb 'pendrives' for 3 years without problems, only damn
small linux, or slitaz running in a desktop machine
2011/5/20 Phil Turmel <philip@turmel.org>:
> {do use reply-to-all on kernel.org lists... not everyone is subscribed}
>
> On 05/20/2011 11:53 AM, Paul van der Vlis wrote:
>> Op 20-05-11 14:11, Phil Turmel schreef:
>>> (Just to show what's out there.) The embedded boards I use
>>> occasionally have the equivalent of this soldered to their
>>> motherboards.
>>>
>>> The best DMA capable CF cards are usually found in markets that cater
>>> to industrial designers or to professional photographers.
>>
>> Do you think the risk of a problem with a CF card (or something like
>> that) is much lower then the risk of a problem with a harddisk?
>
> the big deal is the lack of moving parts: No spindle bearing, no head positioner gear train. On top of that, when set up to support your boot tasks only, there's no write activity to wear it out.
>
>> And what about booting from an USB stick?
>
> Just as good, technically, IMHO. If mounted internally, just as good, period. Plugged into an external port, I'd be wary of some uninformed soul pulling it out. CF cards look like they "belong".
>
> I like Ed W's suggestions, as well, with the caveat that their usefulness would make them more likely to be "borrowed". Even by yourself, in a pinch.
>
> Phil
> --
> 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
>
--
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
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