Hello,
On Wed, Feb 18, 2009 at 10:01 PM, wrote:
> As I already pointed out, sooner or later we will problably need some
> framework to conflate simimlar translator instances in a single process
> -- while dynamic translators are likely to make the problem evident in
> many cases, the problem its
Hi,
On Mon, Feb 09, 2009 at 09:46:30PM +0200, Sergiu Ivanov wrote:
> On Thu, Jan 29, 2009 at 9:19 AM, wrote:
> > On Tue, Jan 13, 2009 at 10:55:05PM +0200, Sergiu Ivanov wrote:
> >> On Fri, Jan 9, 2009 at 9:01 AM, wrote:
> > For each translator in the original tree, we get one nsmux instance.
>
Hello,
On Thu, Jan 29, 2009 at 9:19 AM, wrote:
> On Tue, Jan 13, 2009 at 10:55:05PM +0200, Sergiu Ivanov wrote:
>> On Fri, Jan 9, 2009 at 9:01 AM, wrote:
>> > On Wed, Dec 31, 2008 at 02:42:21PM +0200, Sergiu Ivanov wrote:
>>
>> Too many instances of nsmux, too many context switches, too much
>
Hi,
On Tue, Jan 13, 2009 at 10:55:05PM +0200, Sergiu Ivanov wrote:
> On Fri, Jan 9, 2009 at 9:01 AM, wrote:
> > On Wed, Dec 31, 2008 at 02:42:21PM +0200, Sergiu Ivanov wrote:
> > > On Mon, Dec 29, 2008 at 8:25 AM, wrote:
> > > > The most radical approach would be to actually start a new nsmux
Hi,
On Wed, Dec 31, 2008 at 02:42:21PM +0200, Sergiu Ivanov wrote:
> On Mon, Dec 29, 2008 at 8:25 AM, wrote:
> > On Mon, Dec 22, 2008 at 07:19:50PM +0200, Sergiu Ivanov wrote:
> > The most radical approach would be to actually start a new nsmux
> > instance for each filesystem in the mirrored tr
Hello,
On Mon, Dec 29, 2008 at 8:25 AM, wrote:
> On Mon, Dec 22, 2008 at 07:19:50PM +0200, Sergiu Ivanov wrote:
> > I'm rather inclined to view the node concept introduced in libnetfs as
> > a rather generic concept, and my question arose from such
> > understanding. Still, I realize that such u
Hi,
On Mon, Dec 22, 2008 at 07:19:50PM +0200, Sergiu Ivanov wrote:
> On Thu, Dec 18, 2008 at 4:13 PM, wrote:
> > On Sun, Dec 14, 2008 at 11:34:57PM +0200, Sergiu Ivanov wrote:
> > > I'll put my question differently: are we going to return the
> > > control ports (that is, ports to filesystem) in
On Mon, Dec 22, 2008 at 7:19 PM, Sergiu Ivanov
wrote:
> On Thu, Dec 18, 2008 at 4:13 PM, wrote:
>
>> Wouldn't it be simpler and clearer to process only the first suffix, and
>> pass back any remaining ones as the retry_name, so that they
>> automatically get handled correctly when the client does
Hello,
On Thu, Dec 18, 2008 at 4:13 PM, wrote:
> On Sun, Dec 14, 2008 at 11:34:57PM +0200, Sergiu Ivanov wrote:
> > On Mon, Dec 8, 2008 at 9:28 AM, wrote:
> > I'll put my question differently: are we going to return the control
> > ports (that is, ports to filesystem) inside a instances of stru
Hi,
On Sun, Dec 14, 2008 at 11:34:57PM +0200, Sergiu Ivanov wrote:
> On Mon, Dec 8, 2008 at 9:28 AM, wrote:
> I'll put my question differently: are we going to return the control
> ports (that is, ports to filesystem) inside a instances of struct node
> (provided libnetfs) as it happens in the c
On Sun, Dec 14, 2008 at 11:34 PM, Sergiu Ivanov
wrote:
> [...] I
> supply the source file I used to test this thing as an attachment, so
> that there should not be ambiguities.
Please excuse my forgetfulness... The file is attached to this mail.
Also, I checked it again: the lookup simply fails
Hello,
On Mon, Dec 8, 2008 at 9:28 AM, wrote:
> On Thu, Dec 04, 2008 at 06:49:12PM +0200, Sergiu Ivanov wrote:
> > On Wed, Dec 3, 2008 at 3:40 AM, wrote:
>
> > By proxying control ports do you mean creating shadow nodes containing
> > ports to the real control ports?
>
> Well, the terminology i
Hi,
On Thu, Dec 04, 2008 at 06:49:12PM +0200, Sergiu Ivanov wrote:
> On Wed, Dec 3, 2008 at 3:40 AM, wrote:
> By proxying control ports do you mean creating shadow nodes containing
> ports to the real control ports?
Well, the terminology is totally wrong: We are not creating any *nodes*
here. N
Hello,
On Wed, Dec 3, 2008 at 3:40 AM, <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 25, 2008 at 07:49:18PM +0200, Sergiu Ivanov wrote:
> > On Thu, Nov 20, 2008 at 10:27 PM, <[EMAIL PROTECTED]> wrote:
> > Do you mean that we will have to proxy *each* control port?
>
> Well, we need to make sure that t
Hi,
On Tue, Nov 25, 2008 at 07:49:18PM +0200, Sergiu Ivanov wrote:
> On Thu, Nov 20, 2008 at 10:27 PM, <[EMAIL PROTECTED]> wrote:
> > On Wed, Nov 19, 2008 at 10:33:51PM +0200, Sergiu Ivanov wrote:
> > > It seems to me that in this case the filter will have to be smart
> > > enough to look through
Hello,
On Thu, Nov 20, 2008 at 10:27 PM, <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 19, 2008 at 10:33:51PM +0200, Sergiu Ivanov wrote:
> > On Thu, Nov 13, 2008 at 7:01 AM, <[EMAIL PROTECTED]> wrote:
> > > On Sat, Nov 01, 2008 at 10:57:37PM +0200, Sergiu Ivanov wrote:
>
> > > > Note that the only se
Hi,
On Wed, Nov 19, 2008 at 10:33:51PM +0200, Sergiu Ivanov wrote:
> On Thu, Nov 13, 2008 at 7:01 AM, <[EMAIL PROTECTED]> wrote:
> > On Sat, Nov 01, 2008 at 10:57:37PM +0200, Sergiu Ivanov wrote:
> > > Note that the only sensible use for a filter is placing it at the
> > > bottom of the dynamic t
Hello,
On Thu, Nov 13, 2008 at 7:01 AM, <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 01, 2008 at 10:57:37PM +0200, Sergiu Ivanov wrote:
>
> > When nsmux is asked to do a magic lookup, it creates a new mirror node
> > and sets the requested translator(s) on it.
>
> Well, let's be exact: It creates an
Hi,
On Sat, Nov 01, 2008 at 10:57:37PM +0200, Sergiu Ivanov wrote:
> When nsmux is asked to do a magic lookup, it creates a new mirror node
> and sets the requested translator(s) on it.
Well, let's be exact: It creates an new *shadow* node, i.e. a node that
is visible only as the underlying node
Hello!
I've just encountered a problem in developing the filter for static
translator stacks for nsmux. Let me explain the current architecture
so that my question becomes clear.
When nsmux is asked to do a magic lookup, it creates a new mirror node
and sets the requested translator(s) on it. Whe
20 matches
Mail list logo
