Fwd: IGFS backed by persistence on physical filesystem

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: IGFS backed by persistence on physical filesystem

Valentin Kulichenko
Moving this discussion to the dev list.

As far as I know, IGFS stores data in blocks, so one file can be
distributed across nodes. So I don't see how each node can persist locally.
In my understanding it should be designated shared directory where all
files are persisted. This is actually analogous to how our persistence
store works for regular cache data.

Ivan, correct me if I'm wrong.

-Val

---------- Forwarded message ----------
From: Ivan Veselovsky <[hidden email]>
Date: Tue, Nov 17, 2015 at 11:48 AM
Subject: Re: IGFS backed by persistence on physical filesystem
To: [hidden email]


Paolo Di Tommaso wrote
> What if you have multiple nodes in a cluster using
> org.apache.hadoop.fs.LocalFileSystem as a secondary file system? Each node
> saves the IGFS content locally?

In my understanding yes, each node that was requested to do the file
operation will store the file locally.


Paolo Di Tommaso wrote
> Could it be used to save the data over a NFS mount ?

LocalFileSystem runs over OS file system with "/" being the roott of the
file system, so if an NFS path is mounted , say, in /mnt/nfs/, the files
written under there will be shared. We may think about some kind of "chroot"
there to isolate the Ignite file system from other things.



--
View this message in context:
http://apache-ignite-users.70518.x6.nabble.com/IGFS-backed-by-persistence-on-physical-filesystem-tp1882p1991.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Reply | Threaded
Open this post in threaded view
|

Re: IGFS backed by persistence on physical filesystem

Ivan V.
Valentin, my reply possibly was not enough exact, sorry, so let me bring
clarity there.
If we store a file, in case of LocalFileSystem secondary Fs the file will
be stored locally not on *each* Ignite node in the cluster, but *only* on
the node where the operation was requested.
E.g. if a cluster consists of nodes A, B, C, we connect to node A and write
file "/tmp/f", the file "/tmp/f" will be written locally only on the node
where node A runs, and nowhere else.
Yes, data cache in IGFS is patitioned, so file blocks are distributed. But
this is about IGFS, which in DUAL mode only plays role of intermediate
layer (a cache) between secondary Fs and the client.

On Wed, Nov 18, 2015 at 12:24 AM, Valentin Kulichenko <
[hidden email]> wrote:

> Moving this discussion to the dev list.
>
> As far as I know, IGFS stores data in blocks, so one file can be
> distributed across nodes. So I don't see how each node can persist locally.
> In my understanding it should be designated shared directory where all
> files are persisted. This is actually analogous to how our persistence
> store works for regular cache data.
>
> Ivan, correct me if I'm wrong.
>
> -Val
>
> ---------- Forwarded message ----------
> From: Ivan Veselovsky <[hidden email]>
> Date: Tue, Nov 17, 2015 at 11:48 AM
> Subject: Re: IGFS backed by persistence on physical filesystem
> To: [hidden email]
>
>
> Paolo Di Tommaso wrote
> > What if you have multiple nodes in a cluster using
> > org.apache.hadoop.fs.LocalFileSystem as a secondary file system? Each
> node
> > saves the IGFS content locally?
>
> In my understanding yes, each node that was requested to do the file
> operation will store the file locally.
>
>
> Paolo Di Tommaso wrote
> > Could it be used to save the data over a NFS mount ?
>
> LocalFileSystem runs over OS file system with "/" being the roott of the
> file system, so if an NFS path is mounted , say, in /mnt/nfs/, the files
> written under there will be shared. We may think about some kind of
> "chroot"
> there to isolate the Ignite file system from other things.
>
>
>
> --
> View this message in context:
>
> http://apache-ignite-users.70518.x6.nabble.com/IGFS-backed-by-persistence-on-physical-filesystem-tp1882p1991.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>