On Fri, Jul 27, 2007 at 06:46:17PM +, Pavel Machek wrote:
> Hi!
>
> > > >We implement shared-disk semantics in a shared-nothing cluster.
> > >
> > > If nothing is shared, the disk is not shared, but got shared-disk
> > > semantics? A little confusing.
> >
> > Think of it as RAID1 over TCP.
>
On Jul 30 2007 21:35, Lars Ellenberg wrote:
>On Fri, Jul 27, 2007 at 06:46:17PM +, Pavel Machek wrote:
>> Hi!
>>
>> > > >We implement shared-disk semantics in a shared-nothing cluster.
>> > >
>> > > If nothing is shared, the disk is not shared, but got shared-disk
>> > > semantics? A little
Hi!
> > >We implement shared-disk semantics in a shared-nothing cluster.
> >
> > If nothing is shared, the disk is not shared, but got shared-disk
> > semantics? A little confusing.
>
> Think of it as RAID1 over TCP.
> Typically you have one Node in Primary, the other as Secondary,
> replication
Hi Kyle.
On Wed, Jul 25, 2007 at 11:43:38PM -0400, Kyle Moffett ([EMAIL PROTECTED])
wrote:
> If you made all your sockets and inter-thread pipes nonblocking then
> in userspace you would just epoll_wait() on the sockets and pipes and
> be easily able to react to any IO from anywhere.
>
> In
On Jul 25, 2007, at 22:03:37, [EMAIL PROTECTED] wrote:
On Wed, 25 Jul 2007, Satyam Sharma wrote:
On 7/25/07, Lars Ellenberg <[EMAIL PROTECTED]> wrote:
On Wed, Jul 25, 2007 at 04:41:53AM +0530, Satyam Sharma wrote:
[...]
But where does the "send" come into the picture over here -- a
send won'
On Wed, 25 Jul 2007, Satyam Sharma wrote:
On 7/25/07, Lars Ellenberg <[EMAIL PROTECTED]> wrote:
On Wed, Jul 25, 2007 at 04:41:53AM +0530, Satyam Sharma wrote:
> [...]
>
> But where does the "send" come into the picture over here -- a send
> won't block forever, so I don't foresee any issu
On 7/25/07, Lars Ellenberg <[EMAIL PROTECTED]> wrote:
On Wed, Jul 25, 2007 at 04:41:53AM +0530, Satyam Sharma wrote:
> [...]
>
> But where does the "send" come into the picture over here -- a send
> won't block forever, so I don't foresee any issues whatsoever w.r.t.
> kthreads conversion for tha
On Wed, Jul 25, 2007 at 04:41:53AM +0530, Satyam Sharma wrote:
> Hi Lars,
>
>
> On 7/24/07, Lars Ellenberg <[EMAIL PROTECTED]> wrote:
> >On Mon, Jul 23, 2007 at 07:10:58PM +0530, Satyam Sharma wrote:
> >> On 7/23/07, Lars Ellenberg <[EMAIL PROTECTED]> wrote:
> >> >On Sun, Jul 22, 2007 at 09:32:02
Hi Lars,
On 7/24/07, Lars Ellenberg <[EMAIL PROTECTED]> wrote:
On Mon, Jul 23, 2007 at 07:10:58PM +0530, Satyam Sharma wrote:
> On 7/23/07, Lars Ellenberg <[EMAIL PROTECTED]> wrote:
> >On Sun, Jul 22, 2007 at 09:32:02PM -0400, Kyle Moffett wrote:
> >[...]
> >> Don't use signals between kernel t
On Mon, Jul 23 2007, Lars Ellenberg wrote:
> On Mon, Jul 23, 2007 at 07:10:58PM +0530, Satyam Sharma wrote:
> > On 7/23/07, Lars Ellenberg <[EMAIL PROTECTED]> wrote:
> > >On Sun, Jul 22, 2007 at 09:32:02PM -0400, Kyle Moffett wrote:
> > >[...]
> > >> Don't use signals between kernel threads, use pr
For the guys on netdev, would you please look at the tcp_recvmsg-
threading and TCP_NAGLE_CORK issues below and give opinions on the
best way to proceed?
One thing to remember, you don't necessarily have to merge every
feature right away. As long as the new code is configured "off" by
def
On Mon, Jul 23, 2007 at 07:10:58PM +0530, Satyam Sharma wrote:
> On 7/23/07, Lars Ellenberg <[EMAIL PROTECTED]> wrote:
> >On Sun, Jul 22, 2007 at 09:32:02PM -0400, Kyle Moffett wrote:
> >[...]
> >> Don't use signals between kernel threads, use proper primitives like
> >> notifiers and waitqueues, w
On Mon, Jul 23, 2007 at 03:37:04PM +0200, Jens Axboe wrote:
> On Mon, Jul 23 2007, Lars Ellenberg wrote:
> > > +/* THINK maybe we actually want to use the default "event/%s" worker
> > > threads
> > > + * or similar in linux 2.6, which uses per cpu data and threads.
> > > + *
> > > + * To be gener
On 21/07/07, Lars Ellenberg <[EMAIL PROTECTED]> wrote:
DRBD wants to go mainline.
please have a look at the "for-linus" branch of
git://git.drbd.org/home/git/linux-drbd.git.
A few more comments.
In drbd_main.c::after_state_ch() there's this code :
...
i
On 7/23/07, Lars Ellenberg <[EMAIL PROTECTED]> wrote:
On Sun, Jul 22, 2007 at 09:32:02PM -0400, Kyle Moffett wrote:
[...]
> Don't use signals between kernel threads, use proper primitives like
> notifiers and waitqueues, which means you should also probably switch away
> from kernel_thread() to t
On Mon, Jul 23 2007, Lars Ellenberg wrote:
> > +/* THINK maybe we actually want to use the default "event/%s" worker
> > threads
> > + * or similar in linux 2.6, which uses per cpu data and threads.
> > + *
> > + * To be general, this might need a spin_lock member.
> > + * For now, please use the
On Sun, Jul 22, 2007 at 09:32:02PM -0400, Kyle Moffett wrote:
> Ok, I didn't have a chance to get through anywhere near all of it, but
> here's my comments so far. I didn't really go through things in any
> particular order but most of these comments are about your drbd_int.h
> header file. Hopef
On Mon, Jul 23, 2007 at 11:19:40AM +0200, Sam Ravnborg wrote:
> The message is quite clear.
> For a driver like this do something like:
> - Describe the functionality / the problem is solved
> - Describe the overall design (maybe as a file in Documentation/?)
I'm currently writing the paper for li
On Mon, Jul 23, 2007 at 10:01:01AM +0100, Christoph Hellwig wrote:
> On Mon, Jul 23, 2007 at 11:00:38AM +0200, Sam Ravnborg wrote:
> > On Mon, Jul 23, 2007 at 09:49:03AM +0100, Christoph Hellwig wrote:
> > > On Sun, Jul 22, 2007 at 09:32:02PM -0400, Kyle Moffett wrote:
> > > > First of all, if you
On Mon, Jul 23, 2007 at 11:00:38AM +0200, Sam Ravnborg wrote:
> On Mon, Jul 23, 2007 at 09:49:03AM +0100, Christoph Hellwig wrote:
> > On Sun, Jul 22, 2007 at 09:32:02PM -0400, Kyle Moffett wrote:
> > > First of all, if you could break this up into chunks (even if they
> > > aren't useful individua
On Mon, Jul 23, 2007 at 09:49:03AM +0100, Christoph Hellwig wrote:
> On Sun, Jul 22, 2007 at 09:32:02PM -0400, Kyle Moffett wrote:
> > First of all, if you could break this up into chunks (even if they
> > aren't useful individually) just to make it easier to review.
>
> No, please don't do that I
On Sun, Jul 22, 2007 at 09:32:02PM -0400, Kyle Moffett wrote:
> First of all, if you could break this up into chunks (even if they
> aren't useful individually) just to make it easier to review.
No, please don't do that I have no idea why people say that except for
drinking too much "small patches
Ok, I didn't have a chance to get through anywhere near all of it, but
here's my comments so far. I didn't really go through things in any
particular order but most of these comments are about your drbd_int.h
header file. Hopefully a lot of the comments will be useful to fix
similar/identical pro
Satyam Sharma wrote:
> On 7/22/07, Lars Ellenberg <[EMAIL PROTECTED]> wrote:
>> 94 WARNING: declaring multiple variables together should be avoided
>> int snr, enr;
>> does this really need to become two lines?
>
> No, if these are some unimportant temporary/automatic variables in
> some f
On 7/22/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
On 7/22/07, Lars Ellenberg <[EMAIL PROTECTED]> wrote:
[...]
> 8 ERROR: Macros with multiple statements should be enclosed in a do - while
loop
You don't want to break if-else constructs.
> 1 ERROR: Macros with complex values should be encl
On 7/22/07, Lars Ellenberg <[EMAIL PROTECTED]> wrote:
On Sun, Jul 22, 2007 at 07:52:36AM +0200, Jens Axboe wrote:
> [...]
> Yep, cleanup the style issues (that make sense) from checkpatch and then
> psot as a series of patches that can be reviewed. Linking to a git tree
> wont get you very far.
On Sun, Jul 22, 2007 at 03:58:14PM +0200, Lars Ellenberg wrote:
> On Sun, Jul 22, 2007 at 07:52:36AM +0200, Jens Axboe wrote:
> > On Sun, Jul 22 2007, Andi Kleen wrote:
> > > Lars Ellenberg <[EMAIL PROTECTED]> writes:
> > > >
> > > > Jens, Andrew, anyone: please review,
> > > > and give me advice
On Sun, Jul 22, 2007 at 03:58:14PM +0200, Lars Ellenberg wrote:
> On Sun, Jul 22, 2007 at 07:52:36AM +0200, Jens Axboe wrote:
> > On Sun, Jul 22 2007, Andi Kleen wrote:
> > > Lars Ellenberg <[EMAIL PROTECTED]> writes:
> > > >
> > > > Jens, Andrew, anyone: please review,
> > > > and give me advice
On Sun, Jul 22, 2007 at 11:06:59AM +0200, Jan Engelhardt wrote:
>
> On Jul 22 2007 00:43, Lars Ellenberg wrote:
> >On Sat, Jul 21, 2007 at 11:17:43PM +0200, Jan Engelhardt wrote:
> >> On Jul 21 2007 22:38, Lars Ellenberg wrote:
> >> >
> >> >We implement shared-disk semantics in a shared-nothing cl
On Sun, Jul 22, 2007 at 07:52:36AM +0200, Jens Axboe wrote:
> On Sun, Jul 22 2007, Andi Kleen wrote:
> > Lars Ellenberg <[EMAIL PROTECTED]> writes:
> > >
> > > Jens, Andrew, anyone: please review,
> > > and give me advice how to proceed from here.
> >
> > The standard procedure would be to post a
Jan Engelhardt wrote
On Jul 22 2007 00:43, Lars Ellenberg wrote:
Think of it as RAID1 over TCP.
And what does it do better than raid1-over-NBD? (Which is already N-disk,
and, logically, seems to support cluster filesystems)
I don't know about DRDB, but NBD doesn't handle network disconnec
On Jul 22 2007 00:43, Lars Ellenberg wrote:
>On Sat, Jul 21, 2007 at 11:17:43PM +0200, Jan Engelhardt wrote:
>> On Jul 21 2007 22:38, Lars Ellenberg wrote:
>> >
>> >We implement shared-disk semantics in a shared-nothing cluster.
>>
>> If nothing is shared, the disk is not shared, but got shared-d
Hi Sam,
On 7/22/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
So essentially smaller pieces that can be revied but when ready for inclusion
it should go in as _one_ commit to avoid breaking bisect.
Or alternatively, put all Kconfig and Makefile changes in the last patch.
-
To unsubscribe from th
Hi Lars,
On 7/22/07, Lars Ellenberg <[EMAIL PROTECTED]> wrote:
there is just one logical piece, the drbd module...
it is all in its own subdirectory.
it does not really touch anything else.
I don't think it is feasible to split it further.
I don't know your code at all but the diffstat suggest
> there is just one logical piece, the drbd module...
> it is all in its own subdirectory.
For review purposes the split is often file based.
Something along the lines of:
Makefile + Kconfig
include/linux/drdb* <= why 5 files for one module?
drdb_main.c
drdb_req.{c+h}
etc..
So essentially smal
On Sun, Jul 22, 2007 at 01:50:09AM +0200, Andi Kleen wrote:
> Lars Ellenberg <[EMAIL PROTECTED]> writes:
> >
> > Jens, Andrew, anyone: please review,
> > and give me advice how to proceed from here.
>
> The standard procedure would be to post all the source code in logical
> pieces on the list fo
On Sun, Jul 22 2007, Andi Kleen wrote:
> Lars Ellenberg <[EMAIL PROTECTED]> writes:
> >
> > Jens, Andrew, anyone: please review,
> > and give me advice how to proceed from here.
>
> The standard procedure would be to post all the source code in logical
> pieces on the list for review. Then iterat
Lars Ellenberg <[EMAIL PROTECTED]> writes:
>
> Jens, Andrew, anyone: please review,
> and give me advice how to proceed from here.
The standard procedure would be to post all the source code in logical
pieces on the list for review. Then iterate until all comments are addressed.
-Andi
-
To unsu
On Sat, Jul 21, 2007 at 11:17:43PM +0200, Jan Engelhardt wrote:
>
> On Jul 21 2007 22:38, Lars Ellenberg wrote:
> >
> >We implement shared-disk semantics in a shared-nothing cluster.
>
> If nothing is shared, the disk is not shared, but got shared-disk
> semantics? A little confusing.
Think of i
On 21/07/07, Lars Ellenberg <[EMAIL PROTECTED]> wrote:
DRBD wants to go mainline.
please have a look at the "for-linus" branch of
git://git.drbd.org/home/git/linux-drbd.git.
I just fetched yourt branch and had a (very) quick look.
Some comments.
Try running your patc
On Jul 21 2007 22:38, Lars Ellenberg wrote:
>
>We implement shared-disk semantics in a shared-nothing cluster.
If nothing is shared, the disk is not shared, but got shared-disk
semantics? A little confusing.
Jan
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kerne
DRBD wants to go mainline.
please have a look at the "for-linus" branch of
git://git.drbd.org/home/git/linux-drbd.git.
Longer story:
Hi there,
for lkml readers who don't know about DRBD yet:
DRBD is the distributed replicated block device,
a stacked block device driver a
42 matches
Mail list logo
