Hey Manish, On Wed, Jan 7, 2009 at 10:29 PM, Manish Katiyar <mkatiyar@xxxxxxxxx> wrote: > On Wed, Jan 7, 2009 at 12:44 PM, Manish Katiyar <mkatiyar@xxxxxxxxx> wrote: >> On Wed, Jan 7, 2009 at 12:17 PM, Sandeep K Sinha >> <sandeepksinha@xxxxxxxxx> 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..... > I knew I was missing something.... so you want to move the blocks to > another disk which is of low *priority*. Yes in that case copy is > necessary. Apart from copy, you may also want to do some kind of > readaheads for the source file. doing this in userspace is easy, but I think readaheads would be just for the sake of optimization. The point I would like to make here is that, in the context of OHSM, a manual HSM would also take time to move the data from one tier to the other, right ? And ours times should be able to beat that, which I believe is what I am looking forward to, initally. definitely, we can have a lot of optimizations later on. > if you do this in kernel, even if you have done readahead you cannot > hold kernel for that much time to copy all the data :-( > Also, firstly consider the time taken to copy a file from source to destination through cp command, and on the other hand consider our idea of copying just the data blocks within the kenrel, without any context switches and other overheads. Which one would be faster ? What exactly do you mean by holding the kernel, only the inode will be locked for say the time of moving of these blocks. And our idea is to queue all the operations for that time. Also, for a context, when we start our relocation phase, we intent to queue all the incoming real i/o , scan the fs, find candidates for relocation, perform relocation and then move the FS to normal state. This will have a downtime, for some time but firstly, this a triggered action by the admin and secondly, it wont change the namespace, also it wont break any i/o's. HTH, > thanks - > Manish > > If you have more queries, go ahead. >> . 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 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 :-) >> >> Thanks - >> Manish. >> >>> >>> And release the old inode and its data blocks and update the dentry >>> with the new inode number. >>> PS: The file system remains completely frozen in this time. >>> >>> >>> On Wed, Jan 7, 2009 at 4:02 AM, Om <om.turyx@xxxxxxxxx> wrote: >>>> Erik Mouw wrote: >>>>> >>>>> On Tue, 6 Jan 2009 23:16:14 +0530 "Rohit Sharma" <imreckless@xxxxxxxxx> >>>>> wrote: >>>>>> >>>>>> On Tue, Jan 6, 2009 at 11:09 PM, Manish Katiyar <mkatiyar@xxxxxxxxx> >>>>>> wrote: >>>>>>> >>>>>>> Apart from performance, is there anything else you are worried >>>>>>> about ? >>>>>> >>>>>> Performance is only a bottleneck, >>>>>> this can be done in user land >>>>>> but kernel space solution will be more efficient. >>>>> >>>>> Hardly more efficient. Your main bottleneck will be IO from/to the >>>>> device. If you are worried about copying between kernel and userland, >>>>> you could use the tee(2) and splice(2) system calls. They are relatively >>>>> new, so your system might not yet have manual pages for them. In that >>>>> case, see http://linux.die.net/man/2/tee and >>>>> http://linux.die.net/man/2/splice . >>>> >>>> Hm.. that is pretty enlightening... >>>> Thanks, >>>> Om. >>>> >>>> >>>> -- >>>> To unsubscribe from this list: send an email with >>>> "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx >>>> Please read the FAQ at http://kernelnewbies.org/FAQ >>>> >>>> >>> >>> >>> >>> -- >>> 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 ecartis@xxxxxxxxxxxx >>> Please read the FAQ at http://kernelnewbies.org/FAQ >>> >>> >> > -- 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 ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
