I want to read data blocks from one inode
and copy it to other inode.
I mean to copy data from data blocks associated with one inode
to the data blocks associated with other inode.
Is that possible in kernel space.?
there is one operation called send_file() (i dont know the corresponding sys call for it ...)
i think its ment to do what u want to do ...
thankx
kanishk
________________________________
From: Rohit Sharma <[email protected]>
To: ext4 <[email protected]>; Kernelnewbies <[email protected]>
Sent: Tuesday, 6 January, 2009 4:06:59 PM
Subject: Copying Data Blocks
I want to read data blocks from one inode
and copy it to other inode.
I mean to copy data from data blocks associated with one inode
to the data blocks associated with other inode.
Is that possible in kernel space.?
On Tue, Jan 6, 2009 at 4:06 PM, Rohit Sharma <[email protected]> wrote:
> I want to read data blocks from one inode
> and copy it to other inode.
>
> I mean to copy data from data blocks associated with one inode
> to the data blocks associated with other inode.
Copying 4K chunk of data itself is a costly operation. and depending
on the size of your donor inode this can be huge . Why do you want to
do that ? Do you know the inode of the donor inode ?
thanks -
Manish
>
> Is that possible in kernel space.?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
yes i suppose the donor inode is known
moreover the receiver inode's number is also known
On Tue, Jan 6, 2009 at 6:54 PM, Manish Katiyar <[email protected]> wrote:
> On Tue, Jan 6, 2009 at 4:06 PM, Rohit Sharma <[email protected]> wrote:
> > I want to read data blocks from one inode
> > and copy it to other inode.
> >
> > I mean to copy data from data blocks associated with one inode
> > to the data blocks associated with other inode.
>
> Copying 4K chunk of data itself is a costly operation. and depending
> on the size of your donor inode this can be huge . Why do you want to
> do that ? Do you know the inode of the donor inode ?
>
> thanks -
> Manish
> >
> > Is that possible in kernel space.?
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Regards,
Rishi B. Agrawal
On Tue, Jan 6, 2009 at 7:42 PM, rishi agrawal <[email protected]> wrote:
> yes i suppose the donor inode is known
> moreover the receiver inode's number is also known
>
> On Tue, Jan 6, 2009 at 6:54 PM, Manish Katiyar <[email protected]> wrote:
>>
>> On Tue, Jan 6, 2009 at 4:06 PM, Rohit Sharma <[email protected]> wrote:
>> > I want to read data blocks from one inode
>> > and copy it to other inode.
>> >
>> > I mean to copy data from data blocks associated with one inode
>> > to the data blocks associated with other inode.
>>
>> Copying 4K chunk of data itself is a costly operation. and depending
Yes its a costly operation, but if this can be done then
we can definitely copy n blocks at a time.
>> on the size of your donor inode this can be huge . Why do you want to
>> do that ? Do you know the inode of the donor inode ?
For physically relocating a file from one disk to other.
Yes Manish, i know the donor inode and i will create the reciever inode.
Can we do that in kernel space.?
>>
>> thanks -
>> Manish
>> >
>> > Is that possible in kernel space.?
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>> > the body of a message to [email protected]
>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>> >
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Regards,
> Rishi B. Agrawal
>
>
On Tue, Jan 6, 2009 at 10:15 PM, Rohit Sharma <[email protected]> wrote:
> On Tue, Jan 6, 2009 at 7:42 PM, rishi agrawal <[email protected]> wrote:
>> yes i suppose the donor inode is known
>> moreover the receiver inode's number is also known
>>
>> On Tue, Jan 6, 2009 at 6:54 PM, Manish Katiyar <[email protected]> wrote:
>>>
>>> On Tue, Jan 6, 2009 at 4:06 PM, Rohit Sharma <[email protected]> wrote:
>>> > I want to read data blocks from one inode
>>> > and copy it to other inode.
>>> >
>>> > I mean to copy data from data blocks associated with one inode
>>> > to the data blocks associated with other inode.
>>>
>>> Copying 4K chunk of data itself is a costly operation. and depending
>
> Yes its a costly operation, but if this can be done then
> we can definitely copy n blocks at a time.
>
>>> on the size of your donor inode this can be huge . Why do you want to
>>> do that ? Do you know the inode of the donor inode ?
>
> For physically relocating a file from one disk to other.
>
> Yes Manish, i know the donor inode and i will create the reciever inode.
I am guessing .......will something like this work ?
ino_t donor_inode_num;
struct inode *donor_inode = FS_iget(sb , donor_inode_num);
struct FS_inode_info * fsi = FSI(donor_inode) ; // Do the regular
container_of stuff here
for ( i = 0; i < (donor_inode->i_size + sb->s_blocksize -
1)/sb->s_blocksize ; i ++ ) {
// Do a memmove or memcpy here from fsi->i_data[i]
}
I am not sure though how will you prevent the donor inode from being
changed/resized during this period.
Thanks -
Manish
>
> Can we do that in kernel space.?
>>>
>>> thanks -
>>> Manish
>>> >
>>> > Is that possible in kernel space.?
>>> > --
>>> > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>>> > the body of a message to [email protected]
>>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> >
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>>> the body of a message to [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>> --
>> Regards,
>> Rishi B. Agrawal
>>
>>
>
On Tue, Jan 6, 2009 at 10:43 PM, Manish Katiyar <[email protected]> wrote:
> On Tue, Jan 6, 2009 at 10:15 PM, Rohit Sharma <[email protected]> wrote:
>> On Tue, Jan 6, 2009 at 7:42 PM, rishi agrawal <[email protected]> wrote:
>>> yes i suppose the donor inode is known
>>> moreover the receiver inode's number is also known
>>>
>>> On Tue, Jan 6, 2009 at 6:54 PM, Manish Katiyar <[email protected]> wrote:
>>>>
>>>> On Tue, Jan 6, 2009 at 4:06 PM, Rohit Sharma <[email protected]> wrote:
>>>> > I want to read data blocks from one inode
>>>> > and copy it to other inode.
>>>> >
>>>> > I mean to copy data from data blocks associated with one inode
>>>> > to the data blocks associated with other inode.
>>>>
>>>> Copying 4K chunk of data itself is a costly operation. and depending
>>
>> Yes its a costly operation, but if this can be done then
>> we can definitely copy n blocks at a time.
>>
>>>> on the size of your donor inode this can be huge . Why do you want to
>>>> do that ? Do you know the inode of the donor inode ?
>>
>> For physically relocating a file from one disk to other.
>>
>> Yes Manish, i know the donor inode and i will create the reciever inode.
>
> I am guessing .......will something like this work ?
>
> ino_t donor_inode_num;
> struct inode *donor_inode = FS_iget(sb , donor_inode_num);
> struct FS_inode_info * fsi = FSI(donor_inode) ; // Do the regular
> container_of stuff here
>
> for ( i = 0; i < (donor_inode->i_size + sb->s_blocksize -
> 1)/sb->s_blocksize ; i ++ ) {
> // Do a memmove or memcpy here from fsi->i_data[i]
> }
>
> I am not sure though how will you prevent the donor inode from being
> changed/resized during this period.
I am thinking of remounting ext2 in readonly mode, or i'll change the
mount flags to readonly. But i m not sure if internally i can copy the
data from one block to other.
>
> Thanks -
> Manish
>
>
>>
>> Can we do that in kernel space.?
>>>>
>>>> thanks -
>>>> Manish
>>>> >
>>>> > Is that possible in kernel space.?
>>>> > --
>>>> > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>>>> > the body of a message to [email protected]
>>>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>> >
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>>>> the body of a message to [email protected]
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Rishi B. Agrawal
>>>
>>>
>>
>
We can find out no. of block currently being used by the donor inode,
The data we read from donor inode has to be in some buffer or page,
is there a way we can associate this buffer with the reciever inode
or write the contents of the buffer to the new inode.
On Tue, Jan 6, 2009 at 10:46 PM, Rohit Sharma <[email protected]> wrote:
> On Tue, Jan 6, 2009 at 10:43 PM, Manish Katiyar <[email protected]> wrote:
>> On Tue, Jan 6, 2009 at 10:15 PM, Rohit Sharma <[email protected]> wrote:
>>> On Tue, Jan 6, 2009 at 7:42 PM, rishi agrawal <[email protected]> wrote:
>>>> yes i suppose the donor inode is known
>>>> moreover the receiver inode's number is also known
>>>>
>>>> On Tue, Jan 6, 2009 at 6:54 PM, Manish Katiyar <[email protected]> wrote:
>>>>>
>>>>> On Tue, Jan 6, 2009 at 4:06 PM, Rohit Sharma <[email protected]> wrote:
>>>>> > I want to read data blocks from one inode
>>>>> > and copy it to other inode.
>>>>> >
>>>>> > I mean to copy data from data blocks associated with one inode
>>>>> > to the data blocks associated with other inode.
>>>>>
>>>>> Copying 4K chunk of data itself is a costly operation. and depending
>>>
>>> Yes its a costly operation, but if this can be done then
>>> we can definitely copy n blocks at a time.
>>>
>>>>> on the size of your donor inode this can be huge . Why do you want to
>>>>> do that ? Do you know the inode of the donor inode ?
>>>
>>> For physically relocating a file from one disk to other.
>>>
>>> Yes Manish, i know the donor inode and i will create the reciever inode.
>>
>> I am guessing .......will something like this work ?
>>
>> ino_t donor_inode_num;
>> struct inode *donor_inode = FS_iget(sb , donor_inode_num);
>> struct FS_inode_info * fsi = FSI(donor_inode) ; // Do the regular
>> container_of stuff here
>>
>> for ( i = 0; i < (donor_inode->i_size + sb->s_blocksize -
>> 1)/sb->s_blocksize ; i ++ ) {
>> // Do a memmove or memcpy here from fsi->i_data[i]
>> }
>>
>> I am not sure though how will you prevent the donor inode from being
>> changed/resized during this period.
>
> I am thinking of remounting ext2 in readonly mode, or i'll change the
> mount flags to readonly. But i m not sure if internally i can copy the
> data from one block to other.
>
>>
>> Thanks -
>> Manish
>>
>>
>>>
>>> Can we do that in kernel space.?
>>>>>
>>>>> thanks -
>>>>> Manish
>>>>> >
>>>>> > Is that possible in kernel space.?
>>>>> > --
>>>>> > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>>>>> > the body of a message to [email protected]
>>>>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>> >
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>>>>> the body of a message to [email protected]
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Rishi B. Agrawal
>>>>
>>>>
>>>
>>
>
On Tue, Jan 6, 2009 at 10:55 PM, Rohit Sharma <[email protected]> wrote:
> We can find out no. of block currently being used by the donor inode,
> The data we read from donor inode has to be in some buffer or page,
Since we know the blocknumber of donor inode, it should be possible to
do a raw read and get the memory address of the data page using
sb_bread() and then accessing bh->b_data . Isn't it ?
Thanks -
Manish
> is there a way we can associate this buffer with the reciever inode
> or write the contents of the buffer to the new inode.
>
>
> On Tue, Jan 6, 2009 at 10:46 PM, Rohit Sharma <[email protected]> wrote:
>> On Tue, Jan 6, 2009 at 10:43 PM, Manish Katiyar <[email protected]> wrote:
>>> On Tue, Jan 6, 2009 at 10:15 PM, Rohit Sharma <[email protected]> wrote:
>>>> On Tue, Jan 6, 2009 at 7:42 PM, rishi agrawal <[email protected]> wrote:
>>>>> yes i suppose the donor inode is known
>>>>> moreover the receiver inode's number is also known
>>>>>
>>>>> On Tue, Jan 6, 2009 at 6:54 PM, Manish Katiyar <[email protected]> wrote:
>>>>>>
>>>>>> On Tue, Jan 6, 2009 at 4:06 PM, Rohit Sharma <[email protected]> wrote:
>>>>>> > I want to read data blocks from one inode
>>>>>> > and copy it to other inode.
>>>>>> >
>>>>>> > I mean to copy data from data blocks associated with one inode
>>>>>> > to the data blocks associated with other inode.
>>>>>>
>>>>>> Copying 4K chunk of data itself is a costly operation. and depending
>>>>
>>>> Yes its a costly operation, but if this can be done then
>>>> we can definitely copy n blocks at a time.
>>>>
>>>>>> on the size of your donor inode this can be huge . Why do you want to
>>>>>> do that ? Do you know the inode of the donor inode ?
>>>>
>>>> For physically relocating a file from one disk to other.
>>>>
>>>> Yes Manish, i know the donor inode and i will create the reciever inode.
>>>
>>> I am guessing .......will something like this work ?
>>>
>>> ino_t donor_inode_num;
>>> struct inode *donor_inode = FS_iget(sb , donor_inode_num);
>>> struct FS_inode_info * fsi = FSI(donor_inode) ; // Do the regular
>>> container_of stuff here
>>>
>>> for ( i = 0; i < (donor_inode->i_size + sb->s_blocksize -
>>> 1)/sb->s_blocksize ; i ++ ) {
>>> // Do a memmove or memcpy here from fsi->i_data[i]
>>> }
>>>
>>> I am not sure though how will you prevent the donor inode from being
>>> changed/resized during this period.
>>
>> I am thinking of remounting ext2 in readonly mode, or i'll change the
>> mount flags to readonly. But i m not sure if internally i can copy the
>> data from one block to other.
>>
>>>
>>> Thanks -
>>> Manish
>>>
>>>
>>>>
>>>> Can we do that in kernel space.?
>>>>>>
>>>>>> thanks -
>>>>>> Manish
>>>>>> >
>>>>>> > Is that possible in kernel space.?
>>>>>> > --
>>>>>> > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>>>>>> > the body of a message to [email protected]
>>>>>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>> >
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>>>>>> the body of a message to [email protected]
>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Rishi B. Agrawal
>>>>>
>>>>>
>>>>
>>>
>>
>
On Tue, Jan 6, 2009 at 10:58 PM, Manish Katiyar <[email protected]> wrote:
> On Tue, Jan 6, 2009 at 10:55 PM, Rohit Sharma <[email protected]> wrote:
>> We can find out no. of block currently being used by the donor inode,
>> The data we read from donor inode has to be in some buffer or page,
>
> Since we know the blocknumber of donor inode, it should be possible to
> do a raw read and get the memory address of the data page using
> sb_bread() and then accessing bh->b_data . Isn't it ?
Yes that's the way we can read blocks but the major issue here
is copying this content to newly allocated block.
>
> Thanks -
> Manish
>
>> is there a way we can associate this buffer with the reciever inode
>> or write the contents of the buffer to the new inode.
>>
>>
>> On Tue, Jan 6, 2009 at 10:46 PM, Rohit Sharma <[email protected]> wrote:
>>> On Tue, Jan 6, 2009 at 10:43 PM, Manish Katiyar <[email protected]> wrote:
>>>> On Tue, Jan 6, 2009 at 10:15 PM, Rohit Sharma <[email protected]> wrote:
>>>>> On Tue, Jan 6, 2009 at 7:42 PM, rishi agrawal <[email protected]> wrote:
>>>>>> yes i suppose the donor inode is known
>>>>>> moreover the receiver inode's number is also known
>>>>>>
>>>>>> On Tue, Jan 6, 2009 at 6:54 PM, Manish Katiyar <[email protected]> wrote:
>>>>>>>
>>>>>>> On Tue, Jan 6, 2009 at 4:06 PM, Rohit Sharma <[email protected]> wrote:
>>>>>>> > I want to read data blocks from one inode
>>>>>>> > and copy it to other inode.
>>>>>>> >
>>>>>>> > I mean to copy data from data blocks associated with one inode
>>>>>>> > to the data blocks associated with other inode.
>>>>>>>
>>>>>>> Copying 4K chunk of data itself is a costly operation. and depending
>>>>>
>>>>> Yes its a costly operation, but if this can be done then
>>>>> we can definitely copy n blocks at a time.
>>>>>
>>>>>>> on the size of your donor inode this can be huge . Why do you want to
>>>>>>> do that ? Do you know the inode of the donor inode ?
>>>>>
>>>>> For physically relocating a file from one disk to other.
>>>>>
>>>>> Yes Manish, i know the donor inode and i will create the reciever inode.
>>>>
>>>> I am guessing .......will something like this work ?
>>>>
>>>> ino_t donor_inode_num;
>>>> struct inode *donor_inode = FS_iget(sb , donor_inode_num);
>>>> struct FS_inode_info * fsi = FSI(donor_inode) ; // Do the regular
>>>> container_of stuff here
>>>>
>>>> for ( i = 0; i < (donor_inode->i_size + sb->s_blocksize -
>>>> 1)/sb->s_blocksize ; i ++ ) {
>>>> // Do a memmove or memcpy here from fsi->i_data[i]
>>>> }
>>>>
>>>> I am not sure though how will you prevent the donor inode from being
>>>> changed/resized during this period.
>>>
>>> I am thinking of remounting ext2 in readonly mode, or i'll change the
>>> mount flags to readonly. But i m not sure if internally i can copy the
>>> data from one block to other.
>>>
>>>>
>>>> Thanks -
>>>> Manish
>>>>
>>>>
>>>>>
>>>>> Can we do that in kernel space.?
>>>>>>>
>>>>>>> thanks -
>>>>>>> Manish
>>>>>>> >
>>>>>>> > Is that possible in kernel space.?
>>>>>>> > --
>>>>>>> > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>>>>>>> > the body of a message to [email protected]
>>>>>>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>> >
>>>>>>> --
>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>>>>>>> the body of a message to [email protected]
>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>> Rishi B. Agrawal
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Here are some tips on the blockdevice API:
http://lkml.org/lkml/2006/1/24/287
http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-01/msg09388.html
as indicated, documentation is rather sparse in this area.
not sure if anyone else have a summary list of blockdevice API and its
explanation?
thanks.
On Tue, Jan 6, 2009 at 6:36 PM, Rohit Sharma <[email protected]> wrote:
> I want to read data blocks from one inode
> and copy it to other inode.
>
> I mean to copy data from data blocks associated with one inode
> to the data blocks associated with other inode.
>
> Is that possible in kernel space.?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Regards,
Peter Teoh
Sorry.....some mistakes...a resent:
Here are some tips on the blockdevice API:
http://lkml.org/lkml/2006/1/24/287
http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-01/msg09388.html
as indicated, documentation is rather sparse in this area.
not sure if anyone else have a summary list of blockdevice API and its
explanation?
not wrt the following "cleanup patch", i am not sure how the API will change:
http://lwn.net/Articles/304485/
thanks.
On Tue, Jan 6, 2009 at 6:36 PM, Rohit Sharma <[email protected]> wrote:
>
> I want to read data blocks from one inode
> and copy it to other inode.
>
> I mean to copy data from data blocks associated with one inode
> to the data blocks associated with other inode.
>
> Is that possible in kernel space.?
> --
--
Regards,
Peter Teoh
Hi,
I am having some issues in locking inode while copying data blocks.
We are trying to keep file system live during this operation, so
both read and write operations should work.
In this case what type of lock on inode should be used, semaphore,
mutex or spinlock?
On Sun, Jan 11, 2009 at 8:45 PM, Peter Teoh <[email protected]> wrote:
> Sorry.....some mistakes...a resent:
>
> Here are some tips on the blockdevice API:
>
> http://lkml.org/lkml/2006/1/24/287
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-01/msg09388.html
>
> as indicated, documentation is rather sparse in this area.
>
> not sure if anyone else have a summary list of blockdevice API and its
> explanation?
>
> not wrt the following "cleanup patch", i am not sure how the API will change:
>
> http://lwn.net/Articles/304485/
>
> thanks.
>
> On Tue, Jan 6, 2009 at 6:36 PM, Rohit Sharma <[email protected]> wrote:
>>
>> I want to read data blocks from one inode
>> and copy it to other inode.
>>
>> I mean to copy data from data blocks associated with one inode
>> to the data blocks associated with other inode.
>>
>> Is that possible in kernel space.?
>> --
>
>
>
> --
> Regards,
> Peter Teoh
>
Hi Peter,
As our work veery tightly couples with the FS for our intial
implementation and we are working around with the inodes, we will
require to work at the filesystem level itself.
Though it may not be very feasible, but we will try to push everything
to the blockdev level once our base system is up and running.
Thanks a lot for your finding, I went through it and found that it
will be useful, but with some kind of tweaking around here and there.
We have taken note of the links that you have provided.
Thanks again.
On Sun, Jan 11, 2009 at 8:45 PM, Peter Teoh <[email protected]> wrote:
> Sorry.....some mistakes...a resent:
>
> Here are some tips on the blockdevice API:
>
> http://lkml.org/lkml/2006/1/24/287
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-01/msg09388.html
>
> as indicated, documentation is rather sparse in this area.
>
> not sure if anyone else have a summary list of blockdevice API and its
> explanation?
>
> not wrt the following "cleanup patch", i am not sure how the API will change:
>
> http://lwn.net/Articles/304485/
>
> thanks.
>
> On Tue, Jan 6, 2009 at 6:36 PM, Rohit Sharma <[email protected]> wrote:
>>
>> I want to read data blocks from one inode
>> and copy it to other inode.
>>
>> I mean to copy data from data blocks associated with one inode
>> to the data blocks associated with other inode.
>>
>> Is that possible in kernel space.?
>> --
>
>
>
> --
> Regards,
> Peter Teoh
>
> --
> To unsubscribe from this list: send an email with
> "unsubscribe kernelnewbies" to [email protected]
> Please read the FAQ at http://kernelnewbies.org/FAQ
>
>
--
Regards,
Sandeep.
"To learn is to change. Education is a process that changes the learner."
Hi Rohit,
On Mon, Jan 12, 2009 at 11:48 AM, Rohit Sharma <[email protected]> wrote:
> Hi,
>
> I am having some issues in locking inode while copying data blocks.
> We are trying to keep file system live during this operation, so
> both read and write operations should work.
> In this case what type of lock on inode should be used, semaphore,
> mutex or spinlock?
>
Now here you need to do some homework first.
Each of the locks have its own meaning and particular uses cases.
The current inode struct has the following locks:
1. i_lock
2. i_alloc_sem
3. i_mutex
4. i_flock
646 spinlock_t i_lock; /* i_blocks, i_bytes,
maybe i_size */
647 struct mutex i_mutex;
648 struct rw_semaphore i_alloc_sem;
649 const struct inode_operations *i_op;
650 const struct file_operations *i_fop; /* former
->i_op->default_file_ops */
651 struct super_block *i_sb;
652 struct file_lock *i_flock;
Read the difference between spinlock, mutex, and semaphore.
You will be able to understand the semantics of each of these.
>
> On Sun, Jan 11, 2009 at 8:45 PM, Peter Teoh <[email protected]> wrote:
>> Sorry.....some mistakes...a resent:
>>
>> Here are some tips on the blockdevice API:
>>
>> http://lkml.org/lkml/2006/1/24/287
>> http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-01/msg09388.html
>>
>> as indicated, documentation is rather sparse in this area.
>>
>> not sure if anyone else have a summary list of blockdevice API and its
>> explanation?
>>
>> not wrt the following "cleanup patch", i am not sure how the API will change:
>>
>> http://lwn.net/Articles/304485/
>>
>> thanks.
>>
>> On Tue, Jan 6, 2009 at 6:36 PM, Rohit Sharma <[email protected]> wrote:
>>>
>>> I want to read data blocks from one inode
>>> and copy it to other inode.
>>>
>>> I mean to copy data from data blocks associated with one inode
>>> to the data blocks associated with other inode.
>>>
>>> Is that possible in kernel space.?
>>> --
>>
>>
>>
>> --
>> Regards,
>> Peter Teoh
>>
>
> --
> To unsubscribe from this list: send an email with
> "unsubscribe kernelnewbies" to [email protected]
> Please read the FAQ at http://kernelnewbies.org/FAQ
>
>
--
Regards,
Sandeep.
"To learn is to change. Education is a process that changes the learner."
If u grep for spinlock, mutex, or "sem" in the fs/ext4 directory, u
can find all three types of lock are used - for different class of
object.
For data blocks I guessed is semaphore - read this
fs/ext4/inode.c:ext4_get_branch():
/**
* ext4_get_branch - read the chain of indirect blocks leading to data
<snip>
*
* Need to be called with
* down_read(&EXT4_I(inode)->i_data_sem)
*/
i guess u have no choice, as it is semaphore, have to follow the rest
of kernel for consistency - don't create your own semaphore :-).
There exists i_lock as spinlock - which so far i know is for i_blocks
counting purposes:
spin_lock(&inode->i_lock);
inode->i_blocks += tmp_inode->i_blocks;
spin_unlock(&inode->i_lock);
up_write(&EXT4_I(inode)->i_data_sem);
But for data it should be i_data_sem. Is that correct?
On Mon, Jan 12, 2009 at 2:18 PM, Rohit Sharma <[email protected]> wrote:
> Hi,
>
> I am having some issues in locking inode while copying data blocks.
> We are trying to keep file system live during this operation, so
> both read and write operations should work.
> In this case what type of lock on inode should be used, semaphore,
> mutex or spinlock?
>
>
> On Sun, Jan 11, 2009 at 8:45 PM, Peter Teoh <[email protected]> wrote:
>> Sorry.....some mistakes...a resent:
>>
>> Here are some tips on the blockdevice API:
>>
>> http://lkml.org/lkml/2006/1/24/287
>> http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-01/msg09388.html
>>
>> as indicated, documentation is rather sparse in this area.
>>
>> not sure if anyone else have a summary list of blockdevice API and its
>> explanation?
>>
>> not wrt the following "cleanup patch", i am not sure how the API will change:
>>
>> http://lwn.net/Articles/304485/
>>
>> thanks.
>>
>> On Tue, Jan 6, 2009 at 6:36 PM, Rohit Sharma <[email protected]> wrote:
>>>
>>> I want to read data blocks from one inode
>>> and copy it to other inode.
>>>
>>> I mean to copy data from data blocks associated with one inode
>>> to the data blocks associated with other inode.
>>>
>>> Is that possible in kernel space.?
>>> --
>>
>>
>>
>> --
>> Regards,
>> Peter Teoh
>>
>
--
Regards,
Peter Teoh
Hi Peter,
Don't you think that if will restrict this to a specific file system.
VFS inode should be used rather than the FS incore inode ?
The purpose if to sleep all the i/o's when we are updating the i_data
from the new inode to the old inode ( updation of the data blocks ).
I think i_alloc_sem should work here, but could not find any instance
of its use in the code.
It's working fine currently with i_mutex, meaning if we hold a i_mutex
lock on the inode while updating the i_data pointers.
And try to perform i/o from user space, they are queued. The file was
opened in r/w mode prior to taking the lock inside the kernel.
But, I still feel i_alloc_sem would be the right option to go ahead with.
On Mon, Jan 12, 2009 at 1:11 PM, Peter Teoh <[email protected]> wrote:
> If u grep for spinlock, mutex, or "sem" in the fs/ext4 directory, u
> can find all three types of lock are used - for different class of
> object.
>
> For data blocks I guessed is semaphore - read this
> fs/ext4/inode.c:ext4_get_branch():
>
> /**
> * ext4_get_branch - read the chain of indirect blocks leading to data
> <snip>
> *
> * Need to be called with
> * down_read(&EXT4_I(inode)->i_data_sem)
> */
>
> i guess u have no choice, as it is semaphore, have to follow the rest
> of kernel for consistency - don't create your own semaphore :-).
>
> There exists i_lock as spinlock - which so far i know is for i_blocks
> counting purposes:
>
> spin_lock(&inode->i_lock);
> inode->i_blocks += tmp_inode->i_blocks;
> spin_unlock(&inode->i_lock);
> up_write(&EXT4_I(inode)->i_data_sem);
>
> But for data it should be i_data_sem. Is that correct?
>
> On Mon, Jan 12, 2009 at 2:18 PM, Rohit Sharma <[email protected]> wrote:
>> Hi,
>>
>> I am having some issues in locking inode while copying data blocks.
>> We are trying to keep file system live during this operation, so
>> both read and write operations should work.
>> In this case what type of lock on inode should be used, semaphore,
>> mutex or spinlock?
>>
>>
>> On Sun, Jan 11, 2009 at 8:45 PM, Peter Teoh <[email protected]> wrote:
>>> Sorry.....some mistakes...a resent:
>>>
>>> Here are some tips on the blockdevice API:
>>>
>>> http://lkml.org/lkml/2006/1/24/287
>>> http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-01/msg09388.html
>>>
>>> as indicated, documentation is rather sparse in this area.
>>>
>>> not sure if anyone else have a summary list of blockdevice API and its
>>> explanation?
>>>
>>> not wrt the following "cleanup patch", i am not sure how the API will change:
>>>
>>> http://lwn.net/Articles/304485/
>>>
>>> thanks.
>>>
>>> On Tue, Jan 6, 2009 at 6:36 PM, Rohit Sharma <[email protected]> wrote:
>>>>
>>>> I want to read data blocks from one inode
>>>> and copy it to other inode.
>>>>
>>>> I mean to copy data from data blocks associated with one inode
>>>> to the data blocks associated with other inode.
>>>>
>>>> Is that possible in kernel space.?
>>>> --
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Peter Teoh
>>>
>>
>
>
>
> --
> Regards,
> Peter Teoh
>
> --
> To unsubscribe from this list: send an email with
> "unsubscribe kernelnewbies" to [email protected]
> Please read the FAQ at http://kernelnewbies.org/FAQ
>
>
--
Regards,
Sandeep.
"To learn is to change. Education is a process that changes the learner."