[Gluster-users] GlusterFS compared to KosmosFS (now called cloudstore)?

[Krishna Srinivas]

On Mon, Oct 20, 2008 at 9:19 PM, Vikas Gorur <vikas at zresearch.com> wrote:
> 2008/10/18 Stas Oskin <stas.oskin at gmail.com>:
>> Hi.
>>
>> I'm evaluating GlusterFS for our DFS implementation, and wondered how it
>> compares to KFS/CloudStore?
>>
>> These features here look especially nice
>> (http://kosmosfs.sourceforge.net/features.html). Any idea what of them exist
>> in GlusterFS as well?
>
> Stas,
>
> Here's how GlusterFS compares to KFS, feature by feature:
>
>> Incremental scalability:
>
> Currently adding new storage nodes requires a change in the config
> file and restarting servers and clients. However, there is no need to
> move/copy data or perform any other maintenance steps. "Hot add"
> capability is planned for the 1.5 release.
>
>> Availability
>
> GlusterFS supports n-way data replication through the AFR translator.
>
>> Per file degree of replication
>
> GlusterFS used to have this feature, but it was dropped due to lack
> of interest. It would not be too hard to bring it back.

We moved this functionality to unify's switch scheduler from AFR, so
glusterfs supports per file degree of replication - based on the file
name.

>
>> Re-balancing
>
> The DHT and unify translators have extensive support for distributing
> data across nodes. One can use unify schedulers to define file creation
> policies such as:
>
> * ALU - Adaptively (based on disk space utilization, disk speed, etc.)
> schedule file creation.
>
> * Round robin
>
> * Non uniform (NUFA) - prefer a local volume for file creation and use remote
> ones only when there is no space on the local volume.
>
>> Data integrity
>
> GlusterFS arguably provides better data integrity since it runs over
> an existing filesystem, and does not access disks at the block level.
> Thus in the worst case (which shouldn't happen), even if GlusterFS
> crashes, your data will still be readable with normal tools.
>
>> Rack-aware data placement
>
> None of our users have mentioned this need until now, thus GlusterFS
> has no rack awareness. One could incorporate this intelligence into
> our cluster translators (unify, afr, stripe) quite easily.
>
>> File writes and caching
>
> GlusterFS provides a POSIX-compliant filesystem interface. GlusterFS
> has fine-tunable caching translators, such as read-ahead (to read ahead),
> write-behind (to reduce write latency), and io-cache (caching file data).
>
>> Language support
>
> This is irrelevant to GlusterFS since it is mounted and accessed as a normal
> filesystem, through FUSE. This means all your applications can run on GlusterFS
> without any modifications.
>
>> Deploy scripts
>
> Users have found GlusterFS to be so simple to setup compared to other
> cluster filesystems that there isn't really a need for deploy scripts. ;)
>
>> Local read optimization
>
> As mentioned earlier, if your data access patterns justify it (that
> is, if users generally access local data and only occassionly want
> remote data), you can configure 'unify' with the NUFA scheduler to achieve
> this.
>
> In addition, I'd like to mention two particular strengths of GlusterFS.
>
> 1) GlusterFS has no notion of a 'meta-server'. I have not looked through
> KFS' design in detail, but the mention of a 'meta-server' leads me to
> believe that failure of the meta-server will take the entire cluster offline.
> Please correct me if the impression is wrong.
>
> GlusterFS on the other hand has no single point of failure such as central
> meta server.
>
> 2) GlusterFS 1.4 will have a web-based interface which will allow
> you to start/stop GlusterFS, monitor logs and performance, and do
> other admin activities.
>
>
> Please contact us if you need further clarifications or details.
>
> Vikas Gorur
> Engineer - Z Research
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users
>