[lkml]   [2005]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: GFS, what's remaining
    Andrew Morton <> writes:

    > > > - Why GFS is better than OCFS2, or has functionality which OCFS2 cannot
    > > > possibly gain (or vice versa)
    > > >
    > > > - Relative merits of the two offerings
    > >
    > > You missed the important one - people actively use it and have been for
    > > some years. Same reason with have NTFS, HPFS, and all the others. On
    > > that alone it makes sense to include.
    > Again, that's not a technical reason. It's _a_ reason, sure. But what are
    > the technical reasons for merging gfs[2], ocfs2, both or neither?

    There seems to be clearly a need for a shared-storage fs of some sort
    for HA clusters and virtualized usage (multiple guests sharing a
    partition). Shared storage can be more efficient than network file
    systems like NFS because the storage access is often more efficient
    than network access and it is more reliable because it doesn't have a
    single point of failure in form of the NFS server.

    It's also a logical extension of the "failover on failure" clusters
    many people run now - instead of only failing over the shared fs at
    failure and keeping one machine idle the load can be balanced between
    multiple machines at any time.

    One argument to merge both might be that nobody really knows yet which
    shared-storage file system (GFS or OCFS2) is better. The only way to
    find out would be to let the user base try out both, and that's most
    practical when they're merged.

    Personally I think ocfs2 has nicer&cleaner code than GFS.
    It seems to be more or less a 64bit ext3 with cluster support, while
    GFS seems to reinvent a lot more things and has somewhat uglier code.
    On the other hand GFS' cluster support seems to be more aimed
    at being a universal cluster service open for other usages too,
    which might be a good thing. OCFS2s cluster seems to be more
    aimed at only serving the file system.

    But which one works better in practice is really an open question.

    The only thing that should be probably resolved is a common API
    for at least the clustered lock manager. Having multiple
    incompatible user space APIs for that would be sad.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-09-02 23:20    [W:0.020 / U:13.988 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site