On Tue, Feb 23, 2010 at 7:57 PM, Jan Kara <jack@xxxxxx> wrote: > Hello Manish, > >> We are pleased to announce the first official functional release of Online >> Hierarchical Storage Manager (OHSM v1.2). This is a RFC release and >> not yet aimed at mainline inclusion. >> >> OHSM is a tool to manage and move data across various class of storage. >> It can help users to selectively place and move data across tiers such >> as SSD, Raid 10, Raid 6 based on the attributes of the data. OHSM >> supports background movement of data >> without any visible change in a files namespace to users and user applications. >> OHSM is built as an external module with recompilation required for >> ext4. The current version of OHSM is based upon kernel 2.6.32.2 >> >> This release includes 3 core kernel patches: >> >> 1) An initial ext4 patch to adjust ext4's block allocation to use a >> preferred block range per Ted >> Tso's Dec 2008 write-up >> (http://markmail.org/message/qp7zjhhdzxum7rfn). This patch is not >> ohsm specific. >> 2) A ohsm specific ext4 patch to provide callouts to the ohsm module. >> 3) The ohsm module itself >> >> The source code for OHSM v1.2 is freely distributable under GPL. >> The latest stable OHSM v1.2 is available at : >> http://sourceforge.net/projects/ohsm/files/OHSMv1.2.tar.gz/download >> Sources are available as git repository at : >> git://ohsm.git.sourceforge.net/gitroot/ohsm/ohsm > Looking at the code, the code deciding where to put a given file isn't > really tied to ext4, is it? Hi Jan, ext4 was our default choice to get started, because of the ioctls provided by Akira and since e4defrag already exists it was much easier for us to refer. Though we have tried to keep the OHSM code as independant as possible so that it would be possible to support other filesystems in future too. > Using pathnames to decide where to put files is ... natural but it has > its downsides. For example your code in build_path() is racy because the > directory hiearchy can change while you climb the tree - not mentioning the > fact that the static buffer of 4096 for pathname is ugly and implementing > that simple walk recursively isn't good either. Kernel already has a d_path > function for constructing path in at least somewhat reliable way. Thanks a lot for your feedback. We have fixed some bugs recently to get rid of static allocations so they will go away. I will have a look at d_path(). > Anyway I suggest you have a look at Tomoyo which implements pathname based > security module so that you can avoid mistakes they did... Sure, will do. Definitely it will help us learn more and make the code base better. Thanks - Manish > > Honza > > -- Thanks - Manish ================================== [$\*.^ -- I miss being one of them ================================== -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
