[lkml]   [2008]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [osd-dev] [RFC 0/9] osdfs
    On Nov. 03, 2008, 23:07 +0200, Jeff Garzik <> wrote:
    > Boaz Harrosh wrote:
    >> Please review an OSD based file system.
    >> Given that our OSD initiator library is accepted into Kernel, we would
    >> like to also submit an osdfs. This is the first iteration of this file system.
    >> The next stage is to make it exportable by the pNFS-over-objects Server.
    >> osdfs is one of the building blocks for a full, end-to-end open source
    >> reference implementation of a Server/Client pNFS-over-objects we
    >> want to have available in Linux. Other parts are the Generic pNFS
    >> client project with the objects-layout-driver, and the generic pNFS
    >> server plus osdfs once it is adapted to be exportable.
    >> (See all about pNFS in Linux at:
    >> osdfs was originally developed by Avishay Traeger <>
    >> from IBM. A very old version of it is hosted on sourceforge as the osdfs
    >> project. It was originally developed for the 2.6.10 Kernel over the old
    >> IBM's osd-initiator Linux driver.
    >> Since then it was picked by us, open-osd, and was both forward ported to
    >> current Kernel, as well as converted to run over our osd Kernel Library.
    >> The conversion effort, if anyone is interested, is also available as a
    >> patchset here:
    >> git-clone git:// osdfs-devel
    >> or on the web at:
    >> The Original code is based on ext2 code from the Kernel at the time.
    >> Further reading is available at the last patch in the osdfs.txt file.
    >> I have mechanically divided the code in parts, each introducing a
    >> group of vfs function vectors, all tied at the end into a full filesystem.
    >> Each patch can be compiled but it will only run at the very end.
    >> This was done for the hope of easier reviewing.
    >> Here is the list of patches
    >> [RFC 1/9] osdfs: osd Swiss army knife
    >> [RFC 2/9] osdfs: file and file_inode operations
    >> [RFC 3/9] osdfs: symlink_inode and fast_symlink_inode operations
    >> [RFC 4/9] osdfs: address_space_operations
    >> [RFC 5/9] osdfs: dir_inode and directory operations
    >> [RFC 6/9] osdfs: super_operations and file_system_type
    >> [RFC 7/9] osdfs: mkosdfs
    >> [RFC 8/9] osdfs: Documentation
    > Pretty cool stuff.
    > I've been wondering when we would start seeing OSD filesystems make
    > their appearance.
    > Random, unordered comments:
    > * This is important stuff. Should have been posted to LKML. Please CC
    > LKML in the future.
    > * As discussed at the filesystem summit, OSD use implies a need for an
    > MD-like layer for OSD objects. Has anyone even started the design work
    > for this?

    Yes. I have.
    I'm coding a prototype to be used by both this file system and by
    the pnfs objects layout driver.
    Initially it will do striping and mirroring, and RAID-5 parity as a
    stretched goal for the initial release.

    > * I tend to think there is room for more than one OSD filesystem in the
    > Linux kernel. Assuming all OSDs will use the same Linux filesystem
    > driver will lead to bloat, and you potentially "code yourself into a
    > corner." Let's not rule out multiple filesystems.
    > As such, "osdfs" seems like too-generic a name. How about boazfs? :)

    I agree. osdfs is the name given by Avishay and IBM and we just adopted it.
    I think that obfs (Object-based File System) would better represent
    what it is (although it's still generic compared to boazfs :-)

    > * Get this into the kernel ASAP! OSD stuff languishes outside the
    > kernel for _far_ too long. OSD is a key storage technology that needs
    > to be developed in the full light of the Linux community, not off in a
    > dark corner somewhere, where few see progress or discussions.

    I completely agree. We've missed the merge window for 2.6.28 but
    if we can get it into 2.6.29 that would be great!

    > Object-based storage, and its SCSI incarnation OSD, is a MAJOR revision
    > of the block storage API, moving away from LBA-addressed linear APIs.
    > That's a big deal, and should be discussed on LKML, IMO...

    Thanks for your comments!


    > Jeff

     \ /
      Last update: 2008-11-04 09:07    [W:0.036 / U:4.832 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site