Hi Yan, I just found the wip-zfs branch in your repo and noticed your comment on the wiki; somehow I missed that (and your message in #ceph-summit) during the actual session! This branch looks great! My one suggestion is that the FileStore code would be cleaner if we implement a GenericFileStoreBackend that does the standard xfs/ext4 stuff and the things like the crufty chain of attempts to call syncfs(2). Separating out the refactor from the addition of the ZFS backend into separate patches would also be nice. I'd love to pull this in even if you're still seeing zfs stability issues, as the refactor is a good thing, and we can point Brian at the standalone ceph_test_filestore_workloadgen tool which will hopefully also be sufficient to make zfs break for him with minimal reproduction effort. sage On Mon, 5 Aug 2013, Yan, Zheng wrote: > On Mon, Aug 5, 2013 at 7:39 AM, Noah Watkins <noah.watkins@xxxxxxxxxxx> wrote: > > It seems to make sense that fiemap should be part of the `class > > BackingFileSystem` abstraction? > > > > FS_IOC_FIEMAP is a standard API, I think no need to implement it in `class > BackingFileSystem`. > > > > On Thu, Jul 25, 2013 at 4:53 PM, Sage Weil <sage@xxxxxxxxxxx> wrote: > >> http://wiki.ceph.com/01Planning/02Blueprints/Emperor/osd:_ceph_on_zfs > >> > >> We've done some preliminary testing and xattr debugging that allows > >> ceph-osd to run on zfsforlinux using the normal writeahead journaling mode > >> (the same mode used for xfs and ext4). However, we aren't doing anything > >> special to take advantage of zfs's capabilities. > >> > >> This session would go over what is needed to make parallel journaling work > >> (which would leverage zfs snapshots). I would also like to have a > >> discussion about whether other longer-term possibilities, such as storing > >> objects directly using the DMU, make sense given what ceph-osd's > >> ObjectStore interface really needs. It might also be an appropriate time > >> to visit whether other snapshotting linux filesystems (like nilfs2) would > >> fit well into any generalization of the filestore code that comes out of > >> this effort. > >> > >> If anybody is interested in this, please add yourself to the interested > >> parties section (or claim ownership) of this blueprint! > >> > >> > >> -- > >> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > >> the body of a message to majordomo@xxxxxxxxxxxxxxx > >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- > > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
