Message-ID: <22700089.post@talk.nabble.com>
Date:	Wed, 25 Mar 2009 04:53:05 -0700 (PDT)
From:	SandeepKsinha <sandeepksinha@...il.com>
To:	linux-ext4@...r.kernel.org
Subject: Re: [RFC][PATCH 0/3] ext4: online defrag (ver 1.0)



Theodore Ts'o-2 wrote:
> 
> On Wed, Feb 04, 2009 at 09:51:07AM -0500, Greg Freemyer wrote:
>  
> If the OHSM team implements a similar ioctl for ext2 and ext3 and
> submits them for mainline at some point, do they have a chance of
> being accepted or are ext2 and ext3 feature frozen?
> 
> It seems unlikely it would be accepted.  If the patch could be done in
> a way that seriously minimized the chances of destablizing the code,
> maybe --- but consider also that the OHSM design is a pretty terrible
> hack.  I'm not at all conviced they will be able to stablize it for
> 

I could not understand what makes you feel like that. The idea of OHSM is 
simply to exploit the underlying device topology on which the file system
resides and
have a better block allocation policy based on that. Just a kind of
handshake 
between the Filesystem and the logical volume.

Can you be a bit more specific on what makes you feel that its not the right 
way to achieve such goals?


> production use, and a scheme that involves using dmapi across multiple
> block devices.
> 

Well, we already have stable ioctls through dmapi which provides the
underlying topology of the logical device.
Which I believe is pretty stable at this point in time.



> Note that they apparently need to make other changes to the core
> filesystem code besides just the ioctl --- to the block allocation
> code, at the very least.
> 

Agreed. There would be considerable changes revolving around the block
allocation.
But, the major change would be revolving around the block allocation ONLY.
And the motivation 
for OHSM to think in the direction of ext4 was the mail from Akira which
mentions that we are in 
plan for a similar ioctl based interface for ext4. 
Just to quote: 
"(2) An (ioctl-based) interface which associates with an inode
preferred range(s) of blocks which the block allocator will try using
first; if those blocks are not available, or the block range(s) is
exhausted, the block allocator use its normal algorithms to pick the
best available block.  The set of preferred blocks is only guaranteed
to persist while the inode is in memory.".

http://patchwork.ozlabs.org/patch/12877/

Other than these most of the other implementation resides in a separate
module.

Don't you think that atleast we are clean at block allocation and dmapi.
The major concerns that you had.



> The right answer is really to use a stackable filesystem, and to use
> separate filesystems for each different tier, and then build on top of
> unionfs to give it its policy support.  I suspect that OHSM will be a
> cute student project, but it won't become anything serious given its
> architecture/design, unfortunately.
> 

This can be one of the possible ways of achieving it and may be a better
one. 

Regards,
Sandeep.



> 						- Ted
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 



-- 
View this message in context: http://www.nabble.com/-RFC--PATCH-0-3--ext4%3A-online-defrag-%28ver-1.0%29-tp21742025p22700089.html
Sent from the linux-ext4 mailing list archive at Nabble.com.

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists