Doug Ledford [EMAIL PROTECTED] wrote:
Now, if I recall correctly, Peter posted a patch that changed this
semantic in the raid1 code. The raid1 code does not complete a write to
the upper layers of the kernel until it's been completed on all devices
and his patch made it such that as
Hi Doug,
(in case you are short in time, please just answer to the last part)
(or at the very
absolute least, it should be in a small enough queue of pending writes
that should the power get lost, it can still write the last bits out
during spin down).
Whow. I have heard about this before,
I forgot to say thanks! Thanks for the breakdown.
Doug Ledford [EMAIL PROTECTED] wrote:
(of event count increment)
I think the best explanation is this: any change in array state that
OK ..
would necessitate kicking a drive out of the array if it didn't also
make this change in state with
On Thu, 2005-04-07 at 17:35 +0200, Schuett Thomas EXT wrote:
[Please excuse, my mailtool breaks threads ...]
Reply to mail from 2005-04-05
Hello Doug,
many thanks for this highly detailed and structured posting.
You're welcome.
A few questions are left: Is it common today, that a (eide)
On Tue, 2005-03-29 at 13:26 +0200, Peter T. Breuer wrote:
Neil Brown [EMAIL PROTECTED] wrote:
On Tuesday March 29, [EMAIL PROTECTED] wrote:
Don't put the journal on the raid device, then - I'm not ever sure why
people do that! (they probably have a reason that is good - to them).
Does this sound reasonable?
Does to me. Great example!
Thanks for painting the pretty picture :-).
Seeing as you're clearly the superior thinker, I'll address your brain
instead of wasting wattage on my own.
Let's say that MD had the feature to read from both disks in a mirror
and perform a
Schuett Thomas EXT [EMAIL PROTECTED] wrote:
And here the fault happens:
By chance, it reads the transaction log from hda, then sees, that the
transaction was finished, and clears the overall unclean bit.
This cleaning is a write, so it goes to *both* HDs.
Don't put the journal on the raid
On Tuesday March 29, [EMAIL PROTECTED] wrote:
But:
If you have a raid1 and a journaling fs, see the following:
If the system chrashes at the end of a write transaction,
then the end-of-transaction information may got written
to hda already, but not to hdb. On the next boot, the
journaling
Neil Brown [EMAIL PROTECTED] wrote:
Due to the system crash the data on hdb is completely ignored. Data
Neil - can you explain the algorithm that stamps the superblocks with
an event count, once and for all? (until further amendment :-).
It goes without saying that sb's are not stamped at
Neil Brown [EMAIL PROTECTED] wrote:
On Tuesday March 29, [EMAIL PROTECTED] wrote:
Don't put the journal on the raid device, then - I'm not ever sure why
people do that! (they probably have a reason that is good - to them).
Not good advice. DO put the journal on a raid device. It is
Does this sound reasonable?
Does to me. Great example!
Thanks for the flowers :)
However, I am sure, the raid developers have thought through
all this over and over, and still have some asses in their hands.
I'd like to hear from them about the event count in the superblock
Peter mentioned,
On Tue, Mar 29, 2005 at 01:29:22PM +0200, Peter T. Breuer wrote:
Neil Brown [EMAIL PROTECTED] wrote:
Due to the system crash the data on hdb is completely ignored. Data
Neil - can you explain the algorithm that stamps the superblocks with
an event count, once and for all? (until further amendment
Luca Berra [EMAIL PROTECTED] wrote:
On Tue, Mar 29, 2005 at 01:29:22PM +0200, Peter T. Breuer wrote:
Neil Brown [EMAIL PROTECTED] wrote:
Due to the system crash the data on hdb is completely ignored. Data
Neil - can you explain the algorithm that stamps the superblocks with
an event
Neil Brown wrote:
Is there any way to tell MD to do verify-on-write and
read-from-all-disks on a RAID1 array?
No.
I would have thought that modern disk drives did some sort of
verify-on-write, else how would they detect write errors, and they are
certainly in the best place to do
Neil Brown wrote:
Is there any way to tell MD to [...] and
read-from-all-disks on a RAID1 array?
Not sure why a checksum of X data blocks should be cheaper
performance-wise than a comparison between X data blocks, but I can
see the point in that you only have to load the data once and check
the
On Wednesday March 16, [EMAIL PROTECTED] wrote:
Just wondering;
Is there any way to tell MD to do verify-on-write and
read-from-all-disks on a RAID1 array?
No.
I would have thought that modern disk drives did some sort of
verify-on-write, else how would they detect write errors, and they are
Just wondering;
Is there any way to tell MD to do verify-on-write and
read-from-all-disks on a RAID1 array?
I was thinking of setting up a couple of RAID1s with maximum data safety.
I'd like to verify after each write to a disk plus I'd like to read
from all disks and perform data comparison
17 matches
Mail list logo
