so that data starts at 128K offset into the raid array.
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
signature.asc
Description
Slot : 0 (0, 1)
Array State : Uu
[EMAIL PROTECTED] ~]#
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
signature.asc
On Fri, 2007-11-02 at 03:41 -0500, Alberto Alonso wrote:
On Thu, 2007-11-01 at 15:16 -0400, Doug Ledford wrote:
Not in the older kernel versions you were running, no.
These old versions (specially the RHEL) are supposed to be
the official versions supported by Redhat and the hardware
On Thu, 2007-11-01 at 11:57 -0700, H. Peter Anvin wrote:
Doug Ledford wrote:
Correct, and that's what you want. The alternative is that if the BIOS
can see the first disk but it's broken and can't be used, and if you
have the boot sector on the second disk set to read from BIOS disk
On Thu, 2007-11-01 at 14:02 -0700, H. Peter Anvin wrote:
Doug Ledford wrote:
I would argue that ext[234] should be clearing those 512 bytes. Why
aren't they cleared
Actually, I didn't think msdos used the first 512 bytes for the same
reason ext3 doesn't: space for a boot sector
On Fri, 2007-11-02 at 13:21 -0500, Alberto Alonso wrote:
On Fri, 2007-11-02 at 11:45 -0400, Doug Ledford wrote:
The key word here being supported. That means if you run across a
problem, we fix it. It doesn't mean there will never be any problems.
On hardware specs I normally read
On Thu, 2007-11-01 at 10:31 -0700, H. Peter Anvin wrote:
Doug Ledford wrote:
device /dev/sda (hd0)
root (hd0,0)
install --stage2=/boot/grub/stage2 /boot/grub/stage1 (hd0)
/boot/grub/e2fs_stage1_5 p /boot/grub/stage2 /boot/grub/menu.lst
device /dev/hdc (hd0)
root (hd0,0)
install
On Thu, 2007-11-01 at 00:08 -0500, Alberto Alonso wrote:
On Tue, 2007-10-30 at 13:39 -0400, Doug Ledford wrote:
Really, you've only been bitten by three so far. Serverworks PATA
(which I tend to agree with the other person, I would probably chock
3 types of bugs is too many
On Thu, 2007-11-01 at 20:04 +0100, Janek Kozicki wrote:
Doug Ledford said: (by the date of Thu, 01 Nov 2007 14:30:58 -0400)
So, what I said is true, the MBR will search on the disk it is being run
from for the files it needs: 0x80.
my motherboard allows to pick a boot device if I
one
will need it.
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
signature.asc
Description: This is a digitally signed message
to get booted
into your / partition.
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
signature.asc
Description: This is a digitally
of things happen.
If not, I would like to see what people that have experienced
hardware failures and survived them are using so that such
a list can be compiled.
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband
On Tue, 2007-10-30 at 00:08 -0500, Alberto Alonso wrote:
On Mon, 2007-10-29 at 13:22 -0400, Doug Ledford wrote:
OK, these you don't get to count. If you run raid over USB...well...you
get what you get. IDE never really was a proper server interface, and
SATA is much better, but USB
it resync, and then the final
step is to run the grub install on hdc to make it match the other two
disks. After that, you have a fully functional and booting raid1 array.
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
On Sun, 2007-10-28 at 20:21 -0400, Bill Davidsen wrote:
Doug Ledford wrote:
On Fri, 2007-10-26 at 11:15 +0200, Luca Berra wrote:
On Thu, Oct 25, 2007 at 02:40:06AM -0400, Doug Ledford wrote:
The partition table is the single, (mostly) universally recognized
arbiter of what
drive tracks, it's about array
tracks, aka chunks. A 64k write, that should write to one and only one
chunk, ends up spanning two. That increases the amount of writing the
array has to do and the number of disks it busies for a typical single
I/O operation.
--
Doug Ledford [EMAIL PROTECTED
has been put in mkinitrd from 5.0 onward.
Imho the correct thing here would not have been copying the existing
mdadm.conf but generating a safe one from output of mdadm -D (note -D,
not -E)
I'm not sure I'd want that. Besides, what makes you say -D is safer
than -E?
--
Doug Ledford [EMAIL
On Mon, 2007-10-29 at 09:18 +0100, Luca Berra wrote:
On Sun, Oct 28, 2007 at 10:59:01PM -0700, Daniel L. Miller wrote:
Doug Ledford wrote:
Anyway, I happen to *like* the idea of using full disk devices, but the
reality is that the md subsystem doesn't have exclusive ownership of the
disks
On Sun, 2007-10-28 at 22:59 -0700, Daniel L. Miller wrote:
Doug Ledford wrote:
Anyway, I happen to *like* the idea of using full disk devices, but the
reality is that the md subsystem doesn't have exclusive ownership of the
disks at all times, and without that it really needs to stake
On Sun, 2007-10-28 at 01:27 -0500, Alberto Alonso wrote:
On Sat, 2007-10-27 at 19:55 -0400, Doug Ledford wrote:
On Sat, 2007-10-27 at 16:46 -0500, Alberto Alonso wrote:
Regardless of the fact that it is not MD's fault, it does make
software raid an invalid choice when combined with those
On Mon, 2007-10-29 at 22:44 +0100, Luca Berra wrote:
On Mon, Oct 29, 2007 at 11:30:53AM -0400, Doug Ledford wrote:
On Mon, 2007-10-29 at 09:41 +0100, Luca Berra wrote:
Remaking the initrd installs the new mdadm.conf file, which would have
then contained the whole disk devices and it's UUID
would seem appropriate as well.
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
signature.asc
Description: This is a digitally
On Sun, 2007-10-28 at 15:13 +0100, Luca Berra wrote:
On Sat, Oct 27, 2007 at 08:26:00PM -0400, Doug Ledford wrote:
On Sat, 2007-10-27 at 00:30 +0200, Gabor Gombas wrote:
On Fri, Oct 26, 2007 at 02:52:59PM -0400, Doug Ledford wrote:
In fact, no you can't. I know, because I've created
On Sun, 2007-10-28 at 14:37 +0100, Luca Berra wrote:
On Sat, Oct 27, 2007 at 04:47:30PM -0400, Doug Ledford wrote:
Most of the time it does. But those times where it can fail, the
failure is due to not taking the precautions necessary to prevent it:
aka labeling disk usage via some sort
On Sat, 2007-10-27 at 10:00 +0200, Luca Berra wrote:
On Fri, Oct 26, 2007 at 02:52:59PM -0400, Doug Ledford wrote:
On Fri, 2007-10-26 at 11:54 +0200, Luca Berra wrote:
On Sat, Oct 20, 2007 at 09:11:57AM -0400, Doug Ledford wrote:
just apply some rules, so if you find a partition table _AND_
On Sat, 2007-10-27 at 09:50 +0200, Luca Berra wrote:
On Fri, Oct 26, 2007 at 03:26:33PM -0400, Doug Ledford wrote:
On Fri, 2007-10-26 at 11:15 +0200, Luca Berra wrote:
On Thu, Oct 25, 2007 at 02:40:06AM -0400, Doug Ledford wrote:
The partition table is the single, (mostly) universally
On Fri, 2007-10-26 at 14:41 -0400, Doug Ledford wrote:
Actually, after doing some research, here's what I've found:
* When using grub2, there is supposedly already support for raid/lvm
devices. However, I do not know if this includes version 1.0, 1.1, or
1.2 superblocks. I intend to find
On Sat, 2007-10-27 at 16:46 -0500, Alberto Alonso wrote:
On Fri, 2007-10-26 at 15:00 -0400, Doug Ledford wrote:
This isn't an md problem, this is a low level disk driver problem. Yell
at the author of the disk driver in question. If that driver doesn't
time things out and return errors
, then it would work again in that
install.
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
signature.asc
Description
On Sat, 2007-10-27 at 00:30 +0200, Gabor Gombas wrote:
On Fri, Oct 26, 2007 at 02:52:59PM -0400, Doug Ledford wrote:
In fact, no you can't. I know, because I've created a device that had
both but wasn't a raid device. And it's matching partner still existed
too. What you are talking
late
to bump the partition table start? They can't. So, that's another
thing I think I will check out today, what the maximum size of grub2
might be with all modules included, and what a common size might be.
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http
On Fri, 2007-10-26 at 11:54 +0200, Luca Berra wrote:
On Sat, Oct 20, 2007 at 09:11:57AM -0400, Doug Ledford wrote:
just apply some rules, so if you find a partition table _AND_ an md
superblock at the end, read both and you can tell if it is an md on a
partition or a partitioned md raid1
On Fri, 2007-10-26 at 11:15 +0200, Luca Berra wrote:
On Thu, Oct 25, 2007 at 02:40:06AM -0400, Doug Ledford wrote:
The partition table is the single, (mostly) universally recognized
arbiter of what possible data might be on the disk. Having a partition
table may not make mdadm recognize
. If that driver doesn't
time things out and return errors up the stack in a reasonable time,
then it's broken. Md should not, and realistically can not, take the
place of a properly written low level driver.
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http
or performance?
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
signature.asc
Description: This is a digitally signed message part
(assuming that once copy A locked the devices during
open, that it then held the devices until time to assemble the array).
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http
. while being 100%
transparent to the rest of the OS. The second you considered FC
connected devices and multi-OS access, that fell apart in a big way.
Very analogous.
So, I wouldn't necessarily call it wrong, but it's fragile.
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
On Wed, 2007-10-24 at 16:22 -0400, Bill Davidsen wrote:
Doug Ledford wrote:
On Mon, 2007-10-22 at 16:39 -0400, John Stoffel wrote:
I don't agree completely. I think the superblock location is a key
issue, because if you have a superblock location which moves depending
(logdev: internal)
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
signature.asc
Description: This is a digitally signed
for embedding a boot sector, the 1.2 superblock may be
the best default.
Since you have to support all of them or break existing arrays, and they
all use the same format so there's no saving of code size to mention,
why even bring this up?
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID
On Tue, 2007-10-23 at 21:21 +0200, Michal Soltys wrote:
Doug Ledford wrote:
Well, first I was thinking of files in the few hundreds of megabytes
each to gigabytes each, and when they are streamed, they are streamed at
a rate much lower than the full speed of the array, but still
for
the version 1 superblock issues to iron out and will do so in a future
release).
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
bytes should be just cleared.. but that's another topic.
I would argue that ext[234] should be clearing those 512 bytes. Why
aren't they cleared
Actually, I didn't think msdos used the first 512 bytes for the same
reason ext3 doesn't: space for a boot sector.
--
Doug Ledford [EMAIL PROTECTED
that this conversion is possible, and I never had the case of a
tool saying hmm, /dev/mdsomething is not there, let's look at
/dev/sdc instead.
mount, pvscan.
thanks,
iustin
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
On Sat, 2007-10-20 at 00:43 +0200, Michal Soltys wrote:
Doug Ledford wrote:
course, this comes at the expense of peak throughput on the device.
Let's say you were building a mondo movie server, where you were
streaming out digital movie files. In that case, you very well may care
more
devices. All around, it's just a
*really* bad idea.
I've heard several descriptions of things you *could* do with the
superblock at the end, but as of yet, not one of them is a good idea if
you really care about your data.
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
On Sat, 2007-10-20 at 22:38 +0400, Michael Tokarev wrote:
Justin Piszcz wrote:
On Fri, 19 Oct 2007, Doug Ledford wrote:
On Fri, 2007-10-19 at 13:05 -0400, Justin Piszcz wrote:
[]
Got it, so for RAID1 it would make sense if LILO supported it (the
later versions of the md superblock
of the device.
As to the people who complained exactly because of this feature, LVM has
two mechanisms to protect from accessing PVs on the raw disks (the
ignore raid components option and the filter - I always set filters when
using LVM ontop of MD).
regards,
iustin
--
Doug Ledford [EMAIL
part of the
version *only* means where to put the version 1 superblock on the disk.
If you just say version 1, then it goes to the default location for
version 1 superblocks, and last I checked that was the end of disk (aka,
1.0).
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID
info at http://vger.kernel.org/majordomo-info.html
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
signature.asc
Description
in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Doug Ledford [EMAIL PROTECTED]
http://people.redhat.com/dledford
Infiniband specific RPMs can be found at
http://people.redhat.com/dledford/Infiniband
-
To unsubscribe from this list: send
);
i_size_write(bdev-bd_inode, (loff_t)mddev-array_size
10);
mutex_unlock(bdev-bd_inode-i_mutex);
bdput(bdev);
}
}
return rv;
}
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
to plain linux, reboot, and you are done.
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
--- /sbin/mkinitrd 2006-09-28 12:51
have built in SATA raid
that dm-raid could make use of.
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
signature.asc
Description
will then print out the ARRAY line device as /dev/md//boot. I
don't think this is documented anywhere. This also raises the question
of how partitionable md devices will be handled in regards to their name
component.
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http
, those are 120cm exhaust and 120cm intake
Hehehe, I'll burn in hell for pointing this out, but as 10mm == 1cm, a
120*mm* fan or 12*cm* fan would be correct. I'm pretty sure your fans
are neither 12mm nor 120cm (or if you do have a 120cm
fan...damn...that's a lot of cooling)...
--
Doug Ledford
needs. When you introduce LVM on top
of raid, there is the possibility that there will be interactions
between the two that have a detrimental impact on performance (this may
not always be the case, and it may not be unfixable, I'm just saying
it's an additional layer you have to deal with).
--
Doug
it
should go to one or the other. But, that's just off the top of my head
and I may be on crack...I didn't check what my wife handed me this
morning.
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available
On Wed, 2006-10-18 at 15:43 +0200, martin f krafft wrote:
also sprach Doug Ledford [EMAIL PROTECTED] [2006.10.18.1526 +0200]:
There are a couple reasons I can think.
Thanks for your elaborate response. If you don't mind, I shall link
to it from the FAQ.
Sure.
I have one other question
On Tue, 2006-10-10 at 11:55 +0200, Gabor Gombas wrote:
On Mon, Oct 09, 2006 at 12:32:00PM -0400, Doug Ledford wrote:
You don't really need to. After a clean install, the operating system
has no business reading any block it didn't write to during the install
unless you are just reading
and there is no one to blame but Hans Reiser for that.
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
signature.asc
Description
COPY command to copy the 0 chunk everywhere it needs to go,
and likewise for the parity chunk, and avoid transferring the data over
the SCSI bus more than once.
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific
in md (there is a price for being very general).
Bleh...sometimes I really dislike always making things cater to the
lowest common denominator...you're never as good as you could be and you
are always as bad as the worst case...
--
Doug Ledford [EMAIL PROTECTED]
GPG KeyID: CFBFF194
command. Anyway, not an md
issue, a sata/scsi issue in terms of why it wasn't getting out of the
reset loop eventually. I would send your bad cable to Jeff Garzik for
further analysis of the problem ;-)
--
Doug Ledford [EMAIL PROTECTED]
http://people.redhat.com/dledford
Infiniband specific RPMs
could
also just enable the SMART daemon and have it tell the drives to do
continuous background media checks to detect sectors that are either
already bad or getting ready to go bad (corrected error conditions).
--
Doug Ledford [EMAIL PROTECTED]
http://www.xsintricity.com/dledford
http
that heat
kills, as it is operating outside of the designed temperature range,
either above or below, that reduces overall life expectancy. Keep your
drives from overheating, but don't try to freeze them would be my
advice.
--
Doug Ledford [EMAIL PROTECTED]
http://people.redhat.com/dledford
output?
Keep in mind the root partitions is already mounted in ro mode by the
time fstab is available and the rc.sysinit script merely remounts it rw.
Again, the command line is the authority.
--
Doug Ledford [EMAIL PROTECTED]
http://people.redhat.com/dledford
-
To unsubscribe from this list
to Neil.
--
Doug Ledford [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-raid in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2005-04-04 at 15:51 -0700, Alvin Oga wrote:
On Mon, 4 Apr 2005, Doug Ledford wrote:
Anyway, it might or might not hurt the drives to run them well below
their designed operating temperature, I don't have schematics and
materials lists in front of me to tell for sure.
ez
69 matches
Mail list logo
