On 2005-03-15T09:54:52, Neil Brown [EMAIL PROTECTED] wrote:
It arbitrarily chooses one. It doesn't matter which. The code
currently happens to choose the first, but this is not a significant choice.
True enough. I had a typical case of tomatoes. Thanks.
I think each disk needs to have
I'm going to run some kind of cluster using shared
fiber channel disks with linux sw raid on top.
Is it possible to start a raid device on more than one
machine? Is there any write access for example to the
superblock structure when or after starting a raid
device that might crash with a second
On 2005-03-18T13:52:54, Peter T. Breuer [EMAIL PROTECTED] wrote:
(proviso - I didn't read the post where you set out the error
situations, but surely, on theoretical grounds, all that can happen is
that the bitmap causes more to be synced than need be synced).
You missed the point.
The
Lars Marowsky-Bree [EMAIL PROTECTED] wrote:
On 2005-03-18T13:52:54, Peter T. Breuer [EMAIL PROTECTED] wrote:
(proviso - I didn't read the post where you set out the error
situations, but surely, on theoretical grounds, all that can happen is
that the bitmap causes more to be synced than
Peter T. Breuer wrote:
Lars Marowsky-Bree [EMAIL PROTECTED] wrote:
On 2005-03-18T13:52:54, Peter T. Breuer [EMAIL PROTECTED] wrote:
The problem is for multi-nodes, both sides have their own bitmap. When a
split scenario occurs,
Here I think you mean that both nodes go their independent ways, due
On Fri, Mar 18, 2005 at 02:42:55PM +0100, Lars Marowsky-Bree wrote:
The problem is for multi-nodes, both sides have their own bitmap. When a
split scenario occurs, and both sides begin modifying the data, that
bitmap needs to be merged before resync, or else we risk 'forgetting'
that one side
On 2005-03-18T18:16:08, Luca Berra [EMAIL PROTECTED] wrote:
The problem is for multi-nodes, both sides have their own bitmap. When a
split scenario occurs, and both sides begin modifying the data, that
bitmap needs to be merged before resync, or else we risk 'forgetting'
that one side dirtied
Peter T. Breuer [EMAIL PROTECTED] wrote:
Paul Clements [EMAIL PROTECTED] wrote:
The solution is to combine the bitmaps and resync in one direction or
the other. Otherwise, you've got to do a full resync...
I don't see that this solves anything. If you had both sides going at
once, receiving
Mario Holbe [EMAIL PROTECTED] wrote:
Peter T. Breuer [EMAIL PROTECTED] wrote:
different (legitimate) data. It doesn't seem relevant to me to consider
if they are equally up to date wrt the writes they have received. They
will be in the wrong even if they are up to date.
The goal is to
Peter T. Breuer wrote:
Paul Clements [EMAIL PROTECTED] wrote:
I don't see that this solves anything. If you had both sides going at
once, receiving different writes, then you are sc**ed, and no
resolution of bitmaps will help you, since both sides have received
different (legitimate) data. It
On Fri, Mar 18, 2005 at 09:24:05PM +0100, Mario Holbe wrote:
There is no such thing like the right data from a block device's
point of view. Both mirrors have right data, since both got written
independently. Thus, somebody has to choose one mirror being the
more right one. This, of course, is
I'm running a Linux system with a Adaptec 3210S controller. Right now the
system has nothing on it and I have not created any RAID. I've notice
that when I boot into the Adaptec CD and watch the drives they keep
getting flagged as missing. If I do a Read system config the drives
show up and
12 matches
Mail list logo
