"Default" path modes in IGFS

[Vladimir Ozerov <vo...@gridgain.com>]

Folks,

We have a concept of "default" path modes in IGFS which appears quite
strange to me. Basically, it creates 4 hard path <-> mode mappings which
cannot be overriden:

/ignite/primary -> PRIMARY mode
/ignite/sync -> DUAL_SYNC mode
/ignite/async -> DUAL_ASYNC mode
/ignite/proxy -> PROXY mode

I hardly find this feature useful. First, it is counterintuitive and might
lead to strange conflicts with real user paths. Second, it leads to funny
performance problem: as PROXY mode always defined, users of
IgniteHadoopFileSystem will observe unnecessary initialization of secondary
file system, even if it is not needed.

I considered several approaches to fix that:
1) Add boolean flag to configuration to control whether to initialize these
paths or not;
2) Just remove this feature.

The second option looks more suitable to me because I do not see what value
do these defaults add. So I'd like to remove these dafaults.

Any objections/thoughts?

Vladimir.

Re: "Default" path modes in IGFS

[Vladimir Ozerov <vo...@gridgain.com>]

Well, yes - preserving semantics for existing users is a good point. Let's
go this way.
Initially I named this method "isInitializeDefaulPathModes" (we use "path
mode" instead of "path" in other existing getters/setters).

On Mon, Dec 28, 2015 at 7:37 PM, Dmitriy Setrakyan <ds...@apache.org>
wrote:

> Vova,
>
> I like the 1st option, simply because users may already depend on the
> default folders being initialized. How about isDefaultPaths() or
> isInitDefaultPaths() property?
>
> D.
>
> On Mon, Dec 28, 2015 at 6:52 AM, Vladimir Ozerov <vo...@gridgain.com>
> wrote:
>
> > Folks,
> >
> > We have a concept of "default" path modes in IGFS which appears quite
> > strange to me. Basically, it creates 4 hard path <-> mode mappings which
> > cannot be overriden:
> >
> > /ignite/primary -> PRIMARY mode
> > /ignite/sync -> DUAL_SYNC mode
> > /ignite/async -> DUAL_ASYNC mode
> > /ignite/proxy -> PROXY mode
> >
> > I hardly find this feature useful. First, it is counterintuitive and
> might
> > lead to strange conflicts with real user paths. Second, it leads to funny
> > performance problem: as PROXY mode always defined, users of
> > IgniteHadoopFileSystem will observe unnecessary initialization of
> secondary
> > file system, even if it is not needed.
> >
> > I considered several approaches to fix that:
> > 1) Add boolean flag to configuration to control whether to initialize
> these
> > paths or not;
> > 2) Just remove this feature.
> >
> > The second option looks more suitable to me because I do not see what
> value
> > do these defaults add. So I'd like to remove these dafaults.
> >
> > Any objections/thoughts?
> >
> > Vladimir.
> >
>

Re: "Default" path modes in IGFS

[Dmitriy Setrakyan <ds...@apache.org>]

Vova,

I like the 1st option, simply because users may already depend on the
default folders being initialized. How about isDefaultPaths() or
isInitDefaultPaths() property?

D.

On Mon, Dec 28, 2015 at 6:52 AM, Vladimir Ozerov <vo...@gridgain.com>
wrote:

> Folks,
>
> We have a concept of "default" path modes in IGFS which appears quite
> strange to me. Basically, it creates 4 hard path <-> mode mappings which
> cannot be overriden:
>
> /ignite/primary -> PRIMARY mode
> /ignite/sync -> DUAL_SYNC mode
> /ignite/async -> DUAL_ASYNC mode
> /ignite/proxy -> PROXY mode
>
> I hardly find this feature useful. First, it is counterintuitive and might
> lead to strange conflicts with real user paths. Second, it leads to funny
> performance problem: as PROXY mode always defined, users of
> IgniteHadoopFileSystem will observe unnecessary initialization of secondary
> file system, even if it is not needed.
>
> I considered several approaches to fix that:
> 1) Add boolean flag to configuration to control whether to initialize these
> paths or not;
> 2) Just remove this feature.
>
> The second option looks more suitable to me because I do not see what value
> do these defaults add. So I'd like to remove these dafaults.
>
> Any objections/thoughts?
>
> Vladimir.
>