Hi Greg,
On Wed, Jan 7, 2009 at 9:03 PM, Greg Freemyer <[email protected]> wrote:
> On Wed, Jan 7, 2009 at 5:48 AM, Rohit Sharma <[email protected]> wrote:
>> On Wed, Jan 7, 2009 at 12:44 PM, Manish Katiyar <[email protected]> wrote:
>>> On Wed, Jan 7, 2009 at 12:17 PM, Sandeep K Sinha
>>> <[email protected]> wrote:
>>>> Ok, Let me rephrase what rohit is exactly trying to question.
>>>>
>>>> There is an inode X which has say some N number of data blocks.
>>>> Now, through his own kernel module and some changes to the file system,
>>>> he wants to create a new inode Y in the FS and physically copy all the
>>>> data from the old inode to the new inode.
>>>
>>> Errr....... I must be missing something...... For this why do you need
>>> to copy the data blocks ? if you just copy the old inode to new inode,
>>> you have already copied the direct and indirect block pointers right ?
>>> That will not take much time, and now if you free the old inode, you
>>> have virtually changed the ownership of old blocks to the new inode.
>>>
>> The problem is not replacing the inode, i want to physically move the data.
>> That means if inode X and its data blocks are in block group 1, and
>> new inode is in block group 100
>> then i will allocate data blocks in block group 100 and copy the data
>> from inode X to inode Y.
>> So i will be able to physically relocate a file, and change the
>> directory entry to contain inode Y.
>>
>>> The problems i can see with this approach is that if the new inode is
>>> not in the same block group as old inode, you have *kind of broken*
>>> the ext2's intelligence of allocating the blocks in the same block
>>> group.
>>>
>>> CMIIW . btw this thread is interesting :-)
>>
>> Yes its interesting. :-)
>>
>>>
>> I haven't actually broken ext2's intelligence completely, i have only put
>> restrictions in allocation of inode and data blocks.
>> And it works fine with existing optimizations.
>>
>> And the major issue is relocating files between different block group range.
>
> So if I understand your high level desire, you want to write a
> filesystem re-org (or defrag or something) that works one file at a
> time.
>
> You have to do it in the kernel because you want to control the inode
> and data block allocation.
>
> Your current thought is to mount the entire filesystem readonly, do
> the re-org, remount r/w.
>
> If this is just for yourself, it might be acceptable. If this is for
> the community, it is not (IMO).
>
> To be of value to the community, you need to be more aggressive and
> get this to work on a running filesystem.
>
> My first attempt at high-level pseudo code would be:
>
> ===========
> re_org_file()
> {
> read_orig_inode()
> set inode.re_org_in_progress = true
>
> lock(inode.re_org_in_progress)
> allocate destination inode // Do not
> initiate and real i/o
> allocate all destination indirect pointer blocks // Do not initiate
> and real i/o
> allocate all destination data blocks // Do not
> initiate and real i/o
>
Sorry, but i didn't understand what you mean by "Do not initiate and
real i/o" ??
> allocate_file_re_org_done_array // one bit per data block
> memset (file_re_org_done_array, false)
> release_lock(inode.re_org_in_progress)
>
> for each bit in file_re_org_done_array[] {
> if (not file_re_org_done_array[block]) {
> lock(inode_re_org_in_progress)
> copy_block() // I know, your question is how to do this
> set file_re_org_done_array[block] = true
> release_lock(inode_re_org_in_progress)
> }
> }
>
> lock(inode.re_org_in_progress)
> copy_inode_info()
> update_directory_entries()
> release_lock(inode._re_org_in_progress)
>
> set inode.re_org_in_progress = false
> }
>
> Then insert logic into the write() code that does:
>
> // inserted write logic
> if inode.re_org_in_progress == true {
> lock(inode.re_org_in_progress)
> send data to orig block // no real i/o needed
> send data to new dest block // no real i/o needed
What do you mean by no real i/o needed ???
> file_re_org_done_array[block] = true
> release_lock(inode.re_org_in_progress)
> } else
> send data to normal block // no real i/o needed
>
> // end of inserted write logic
> ====================================
>
Do we need to copy the blocks, which has been written after the
initiation of this block relocation ?
I mean the copy operation will be redundant.
What do you say ?
> Does that capture the essence of what you are trying to do?
>
> And I assume your first question is still, how do I write copy_block()?
>
> I don't know the actual semantics for that, but maybe someone can take
> the above and either figure out a better way to accomplish the re-org
> or tell you how to implement copy_block() as needed in the above.
>
> Greg
> --
> Greg Freemyer
> Litigation Triage Solutions Specialist
> http://www.linkedin.com/in/gregfreemyer
> First 99 Days Litigation White Paper -
> http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf
>
> The Norcross Group
> The Intersection of Evidence & Technology
> http://www.norcrossgroup.com
>
--
Regards,
Sandeep.
"To learn is to change. Education is a process that changes the learner."
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to [email protected]
Please read the FAQ at http://kernelnewbies.org/FAQ
