Harry,
Can you do simple things with /dev/hdl like... ?
dd count=10 if=/dev/hdl of=/dev/null
It might help to see your device entry and other information, can you give us
the output of...
ls -l /dev/hdl
cat /etc/mtab
cat /proc/mdstat
cat /etc/mdtab
dd count=10 if=/dev/hdl
I hope this helps. See below.
Lance.
my questions are:
2. the disk seems to be "cured" by re-enabling DMA . . . but what is the state
of my array likely to be after the errors above? Can I safely assume this was
harmless? I mean, they WERE write errors after all, yes? Is my array still
Darren Nickerson wrote:
+ 4. is there some way to mark this disk bad right now, so that
+ reconstruction is carried out from the disks I trust? I do have a hot
+ spare . . .
Lance You can use the 'raidhotremove' utility.
This has never worked for me when the disk had not been
It is a very bad idea to prevent resyncs after a volume has possibly becoming out of
sync.
It is important to have the disks in sync--even if the data is the wrong data. The way
raid-1's balancing works, you don't know what disk will be read. For the same block,
the
system may read different
The event counter (and serial number) only indicates that the superblock is the most
current.
The SB_CLEAN bit is cleared when an array gets started, and is set when it is stopped
(this
automatically happens during a normal shutdown.) But, if the system crashes or the
power gets
yanked, the
i have set up an md (raid1) device. it has two hard disks.
Something has gone bad on the disks, such
that whenever I do a raidstart or mkraid, it
says
raid set md0 not clean. starting background reconstr.. ..
what can I do to clean my md device.
If the raid device isn't stopped
Johan,
Thanks for sending the bulk information about this bug. I have never seen the buffer
bug
when running local loads, only when using nfs. The bug appears more often when running
with 64MB of RAM or less, but has been seen when using more memory.
Below is a sample of the errors seen while
Perhaps if you also modified MAX_REAL in the md_k.h file to 15, it will like more
than 12. This value is only used by raid0.
Lance.
[EMAIL PROTECTED] wrote:
i tried this but mkraid still gives the same error of "a maximum of 12
disks is supported."
i set MD_SB_DISKS_WORDS to 480 to give me
I assume you are looking for double redundancy--survive a double failure.
It would be more efficient to do raid5 on top of several raid1 arrays. You
will have more arrays, but the checksum will only be calculated once. If you
tried raid1 above raid5, you would be calculating the checksum twice
Ingo,
I can fairly regularly generate corruption (data or ext2 filesystem) on a busy
RAID-5 by adding a spare drive to a degraded array and letting it build the
parity. Could the problem be from the bad (illegal) buffer interactions you
mentioned, or are there other areas that need fixing as
Scott,
1. Use raidhotremove to take out the IDE drive. Example:
raidhotremove /dev/md0 /dev/hda5
2. Use raidhotadd to add the SCSI drive. Example: raidhotadd /dev/md0
/dev/sda5
3. Correct your /etc/raidtab file with the changed device.
Lance.
Scott Patten wrote:
I'm sorry if this is
SCSI works quite well with many devices connected to the same cable. The PCI bus
turns out to be the bottleneck with the faster scsi modes, so it doesn't matter
how many channels you have. If performance was the issue, but the original poster
wasn't interested in performance, multiple channels
Roland,
The messages are not to be feared. To prevent thrashing on a drive between multiple
resync processes, the
raid resync routine checks to see if any of the disks in the array are already active
in another resync.
If so, then it waits for the other process to finish before starting. Thus,
Hi Brian,
You wrote:
Ignoring CPU, filesystem, and library limitations, what is the theoretical
maximum size of a raid device?
The raid superblock appears to store the block size of each physical
device
in an unsigned 32-bit integer allowing a maximum physical device size of
4 terabytes.
Use the raidhotadd utility. This updates the raid superblock on all the
disks in the raid set to know about the spare. This information is
remembered and does not need to be done again.
Lance
- Original Message -
From: Johan Ekenberg [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent:
Makoto,
The normal raid driver only handles 12 disk entries (or slots). Unfortunately, a
spare disk counts as another disk slot, and you need a spare slot to rebuild the
failed disk. But, with your setup of 12 disk raid 5, you have already defined all
the available disk slots.
To recover your
Attached is a program that will let you get or set the read ahead value
for any major device. You can easily change the value and then do a
performance test.
Lance.
Jakob Østergaard wrote:
Hi all !
I was looking into tuning the readahead done on disks in a RAID.
It seems as though
There is a constant specifying the maximum number of md devices. But,
there is no variable stating how many active md devices are around. This
wouldn't make much sense anyway since the md devices are not allocated
sequentially. You can start with md3, for example.
You can have a program analyze
OOPS! I copied the first echo line, but didn't edit it.
Lance Robinson wrote:
You should first use:
echo "scsi remove-single-device a b c d" /proc/scsi/scsi
then use:
echo "scsi remove-single-device a b c d " /proc/scsi/scsi
The second echo should b
- Original Message -
From: Tomas Fasth [EMAIL PROTECTED]
To: Brian Murphy [EMAIL PROTECTED]
Cc: Linux Raid List [EMAIL PROTECTED]
Sent: Monday, October 04, 1999 5:16 AM
Subject: Re: How do I spin up a SCSI disk after being hot swapped?
Brian Murphy wrote:
echo "scsi add-single-disk
Jakob Østergaard wrote:
IIRC the 12 disk limit is a ``feature''. Actually you can have up to 15 disks. Simply
grep for the 12 disk constant in the raidtools and flip it up to 15. You can't go
further than that though.
I forget the exact number, but Ingo said that the drive count can be
Optimizing the md driver for Bonnie, IMHO, is foolishness. Bonnie is a
sequential read/write test and does not produce numbers that mean much
in typical data access patterns. Example: the read_ahead value is bumped
way up (1024), this kills performance when doing more normal accesses.
Linux's
Hi Mike,
You are using a very small chunk size. Increase this number to 128. I
think you may need to remake the array though. This is kind of silly
since in RAID-1, the data isn't laid out any differently for different
chunk sizes as other raid personalities are. It would be nice to be able
to
Lawrence,
If you don't care about being 'standard', There is plenty of fluff in
the superblock to make room for more disks. I don't know how well
behaved all the tools are at using the symbolic constants though. To
Support 18 devices, you will need to allow at least 19 disks (one for
the
James,
There are currently 128 possible SCSI disk device allocated in the
device map--see linux/Documentation/devices.txt . Now, each of these
supports partitions 1..15 (lower 4 bits) with 0 being the raw device,
and the other bits for the base device are mapped into various places.
There is a
the
requests). 128KB may work just as well, but this exceeds the size of some cache
buffers and some device drivers cannot request more than 64KB in one request.
My two cents worth.
Lance.
Marc Mutz wrote:
D. Lance Robinson wrote:
Try bumping your chunk-size up. I usually use 64. When
Try bumping your chunk-size up. I usually use 64. When this number is low,
you cause more scsi requests to be performed than needed. If really big (
=256 ) RAID 0 won't help much.
Lance.
Richard Schroeder wrote:
Help,
I have set up RAID-0 on my Linux Redhat 6.0. I am using RAID-0
Hi Lucio,
Lucio Godoy wrote:
The idea of using raid is to add more disks onto the scsi
controler (Hot adding ?) when needed and combine the newly
added disk to the previous disks as one physical device.
Is it possible to add another disk without having to switch of the
machine?
There
To identify the spare devices through /proc/mdstat...
1) Look for the [#/#] value on a line. The first number is the
number of a complete raid device as defined. Lets say it is 'n'.
2) The raid role numbers [#] following each device indicate its
role, or function, within the raid set.
Don't start to think that Bonnie gives real world performance numbers.
It gives single tasking sequential access throughput values. Sure
Bonnie's numbers have some value, but don't think that its results match
typical system access patterns.
The performance difference with Raid-1 is seen when
Osma,
RAID-1 does read balancing which may(?) be better than striping. Each
read request is checked against the previous request, if it is
contiguious with the previous request, it uses the same device,
otherwise it switches to the next mirror. This process cycles through
the mirrors (n-way
The bottom line: Read performance for a RAID-1 device is better than a
single (JBOD) device. The bigger the n in n-way mirroring gives better
read performance, but slightly worse write performance.
But using n-way mirrors will also increase cpu utilization during reads
-
or am I
The answer is still the same (May 1999).
Lance.
Scott Smyth wrote:
I would like to explore the requirements of expanding
RAID 0,4, and 5 levels from an existing configuration.
For example, if you have 3 disks in a RAID 5 configuration,
you currently cannot add a disk to the RAID 5
Hi all,
Attached is a fix for a problem that happens when /proc/mdstat is read
when a raid device is being stopped. A panic could result.
Not many users are reading /proc/mdstat much or stopping a raid device
manually, but this problem caused us many headaches.
The problem happens something
Hi,
You can run a system without a swap device. But if you do 'swapoff -a'
_after_ a swap device failure, you are dead (if swap had any virtual
data stored in it.)
'swapoff -a' copies virtual data stored in the swap device to physical
memory before closing the device. This is much different
There seems to be a major problem when reading /proc/mdstat while a raid
set is being stopped. This rarely conflict will very rarely be seen, but
I have a daemon that monitors /proc/mdstat every two seconds and once in
a while the system panics when doing testing.
While running the script below
I have linux 2.2.3 with raid014519990309.. patch.
On a PPC (Mac G3) system, I am getting what seems to be memory buffer
courruption when using raidstart. The same kernel source run with i386
architecture seems to be fine.
To show the problem, I do something like the following...
# cd ~me
#
Hi,
I have noticed that the read_ahead value is set to 1024 in the md
driver. Why is this value so large? I would think a value of 128 or so
would be more appropriate.
Lance.
steve rader wrote:
Some eec person once told me that disconnecting live molex
(power) scsi connectors can kill a disk drive. And I'm also
not confortable futzing with scsi connectors on live busses.
I assume the perferred method is to put the disk-to-kill
on a external power supply with
I have also noticed this type of problem. It seems as though the RAID5
driver generates a growing write backlog and keeps allocating new
buffers when new asynchronous write requests get in. Eventually it
reserves all the available physical memory. Trying to swap data to
virtual memory storage
James,
First of all, you probably want to reboot. This will rename your devices
to their typical values. To add a device into a failed raid slot, you
can use the raidhotadd command. do something like:
raidhotadd /dev/md0 /dev/hdc2
This will add the device to the raid set and start a
Eric van Dijken wrote:
Is there somebody working on joining the devfs patch and the raid patch in
the linux kernel (2.1.130) ?
I am planning on working on this issue sometime this week.
Lance.
Hi all,
The RAID5 md driver pauses for 10-11 seconds, many times, while doing a
mke2fs. The pauses start after 300-400 groups have been written, then a
small amount of transfers happen between pauses until the process is
done. The spurts of transfers between pauses range between .01 seconds
to
43 matches
Mail list logo
