On Tue, Jan 6, 2009 at 12:46 PM, Rohit Sharma <imreckless@xxxxxxxxx> wrote: > On Tue, Jan 6, 2009 at 11:09 PM, Manish Katiyar <mkatiyar@xxxxxxxxx> wrote: >> On Tue, Jan 6, 2009 at 11:06 PM, Rohit Sharma <imreckless@xxxxxxxxx> wrote: >>> On Tue, Jan 6, 2009 at 10:58 PM, Manish Katiyar <mkatiyar@xxxxxxxxx> wrote: >>>> On Tue, Jan 6, 2009 at 10:55 PM, Rohit Sharma <imreckless@xxxxxxxxx> 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. >> >> 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. > For normal disks, the real bottleneck is the drive / io subsystem. The cpu will barely be taxed. If I understand what you said previously, you are trying to write code to migrate a ext2/3 filesystem to a new destination filesystem. Is the concept that the new filesystem will be ext4? Are you going to try to get this accepted into the vanilla kernel? If so, I suggest you be minimally invasive to the kernel. 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 -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
