ocfs2 for OSDs?

ocfs2 for OSDs?

[Ugis]

Hi,

I wonder is ocfs2 suitable for hosting OSD data?
In ceph documentation only XFS, ext4 and btrfs are discussed, but
looking at ocfs2 feature list it theoretically also could host OSDs:

Some of the notable features of the file system are:
Optimized Allocations (extents, reservations, sparse, unwritten
extents, punch holes)
REFLINKs (inode-based writeable snapshots)
Indexed Directories
Metadata Checksums
Extended Attributes (unlimited number of attributes per inode)
Advanced Security (POSIX ACLs and SELinux)
User and Group Quotas
Variable Block and Cluster sizes
Journaling (Ordered and Writeback data journaling modes)
Endian and Architecture Neutral (x86, x86_64, ia64 and ppc64)
Buffered, Direct, Asynchronous, Splice and Memory Mapped I/Os
In-built Clusterstack with a Distributed Lock Manager
Cluster-aware Tools (mkfs, fsck, tunefs, etc.)

ocfs2 can work in cluster mode but it can also work for single node.

Just wondering would OSD work on ocfs2 and what would performance
characteristics be.
Any thoughts/experience?

BR,
Ugis Racko

Re: ocfs2 for OSDs?

[Sage Weil]

On Wed, 11 Sep 2013, Ugis wrote:
> Hi,
> 
> I wonder is ocfs2 suitable for hosting OSD data?
> In ceph documentation only XFS, ext4 and btrfs are discussed, but
> looking at ocfs2 feature list it theoretically also could host OSDs:
> 
> Some of the notable features of the file system are:
> Optimized Allocations (extents, reservations, sparse, unwritten
> extents, punch holes)
> REFLINKs (inode-based writeable snapshots)

This is the one item on this list I see that the ceph-osds could take real 
advantage of; it would make object clones triggered by things like RBD 
snapshots faster.  What is missing from this list that would be similarly 
(or more) useful is a volume/fs snapshot feature.

Of course, ocfs2 only makes sense when run in a single-node mode 
underneath ceph-osds.

sage


> Indexed Directories
> Metadata Checksums
> Extended Attributes (unlimited number of attributes per inode)
> Advanced Security (POSIX ACLs and SELinux)
> User and Group Quotas
> Variable Block and Cluster sizes
> Journaling (Ordered and Writeback data journaling modes)
> Endian and Architecture Neutral (x86, x86_64, ia64 and ppc64)
> Buffered, Direct, Asynchronous, Splice and Memory Mapped I/Os
> In-built Clusterstack with a Distributed Lock Manager
> Cluster-aware Tools (mkfs, fsck, tunefs, etc.)
> 
> ocfs2 can work in cluster mode but it can also work for single node.
> 
> Just wondering would OSD work on ocfs2 and what would performance
> characteristics be.
> Any thoughts/experience?
> 
> BR,
> Ugis Racko
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: ocfs2 for OSDs?

[David Disseldorp]

Hi Sage,

On Wed, 11 Sep 2013 09:18:13 -0700 (PDT)
Sage Weil <sage@inktank.com> wrote:

> > REFLINKs (inode-based writeable snapshots)  
> 
> This is the one item on this list I see that the ceph-osds could take real 
> advantage of; it would make object clones triggered by things like RBD 
> snapshots faster.  What is missing from this list that would be similarly 
> (or more) useful is a volume/fs snapshot feature.

I must be missing something here, but I don't see how this would offer
any advantage over Btrfs, which provides the same feature via
BTRFS_IOC_CLONE and BTRFS_IOC_CLONE_RANGE.

Cheers, David

Re: ocfs2 for OSDs?

[Gregory Farnum]

On Wed, Sep 11, 2013 at 12:55 PM, David Disseldorp <ddiss@suse.de> wrote:
> Hi Sage,
>
> On Wed, 11 Sep 2013 09:18:13 -0700 (PDT)
> Sage Weil <sage@inktank.com> wrote:
>
>> > REFLINKs (inode-based writeable snapshots)
>>
>> This is the one item on this list I see that the ceph-osds could take real
>> advantage of; it would make object clones triggered by things like RBD
>> snapshots faster.  What is missing from this list that would be similarly
>> (or more) useful is a volume/fs snapshot feature.
>
> I must be missing something here, but I don't see how this would offer
> any advantage over Btrfs, which provides the same feature via
> BTRFS_IOC_CLONE and BTRFS_IOC_CLONE_RANGE.

Yep, we do that on btrfs. Sage was just looking at things we could use
which aren't part of the standard POSIX spec. This could give ocfs2 an
advantage over xfs/ext4 if we implemented that awareness.
-Greg
Software Engineer #42 @ http://inktank.com | http://ceph.com

Re: ocfs2 for OSDs?

[Jeff Bachtel]

[-- Attachment #1.1: Type: text/plain, Size: 1660 bytes --]

Previous experience with OCFS2 was that its actual performance was pretty
lackluster/awful. The bits Oracle threw on top of (I think) ext3 to make it
work as a multi-writer filesystem with all of the signalling that implies
brought the overall performance down.

Jeff


On Wed, Sep 11, 2013 at 9:58 AM, Ugis <ugis22-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> Hi,
>
> I wonder is ocfs2 suitable for hosting OSD data?
> In ceph documentation only XFS, ext4 and btrfs are discussed, but
> looking at ocfs2 feature list it theoretically also could host OSDs:
>
> Some of the notable features of the file system are:
> Optimized Allocations (extents, reservations, sparse, unwritten
> extents, punch holes)
> REFLINKs (inode-based writeable snapshots)
> Indexed Directories
> Metadata Checksums
> Extended Attributes (unlimited number of attributes per inode)
> Advanced Security (POSIX ACLs and SELinux)
> User and Group Quotas
> Variable Block and Cluster sizes
> Journaling (Ordered and Writeback data journaling modes)
> Endian and Architecture Neutral (x86, x86_64, ia64 and ppc64)
> Buffered, Direct, Asynchronous, Splice and Memory Mapped I/Os
> In-built Clusterstack with a Distributed Lock Manager
> Cluster-aware Tools (mkfs, fsck, tunefs, etc.)
>
> ocfs2 can work in cluster mode but it can also work for single node.
>
> Just wondering would OSD work on ocfs2 and what would performance
> characteristics be.
> Any thoughts/experience?
>
> BR,
> Ugis Racko
> _______________________________________________
> ceph-users mailing list
> ceph-users-idqoXFIVOFJgJs9I8MT0rw@public.gmane.org
> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
>

[-- Attachment #1.2: Type: text/html, Size: 2274 bytes --]

[-- Attachment #2: Type: text/plain, Size: 178 bytes --]

_______________________________________________
ceph-users mailing list
ceph-users-idqoXFIVOFJgJs9I8MT0rw@public.gmane.org
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com