[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.047 / U:1.436 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site