On Nov. 03, 2008, 23:07 +0200, Jeff Garzik <jeff@xxxxxxxxxx> 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: >> http://wiki.linux-nfs.org/wiki/index.php/PNFS_prototype_design) >> >> osdfs was originally developed by Avishay Traeger <avishay@xxxxxxxxx> >> 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://git-open-osd.org/open-osd.git osdfs-devel >> or on the web at: >> http://git.open-osd.org/gitweb.cgi?p=open-osd.git;a=shortlog;h=refs/heads/osdfs-devel >> >> 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... Absolutely. Thanks for your comments! Benny > > Jeff > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
