On Thu, Jan 15, 2009 at 12:47 PM, Sandeep K Sinha <sandeepksinha@xxxxxxxxx> wrote: > Hey, > > On Thu, Jan 15, 2009 at 10:27 PM, Greg Freemyer <snip> >> I think I've said it before, but I would think the best real world >> implementation would be: >> >> === >> pre-allocate destination data blocks >> >> For each block >> prefetch source data block >> lock inode >> copy source data block to dest data block IN MEMORY ONLY and put in >> block queue for delivery to disk >> release lock >> end >> >> perform_inode_level_block_pointer_swap >> === >> > > I would be more than very happy if I am able to accomplish this. Greg, > the only problem that I see here is somebody who has already opened > the file is making the size of the file to increase, once I > preallocate destination data blocks. > And I don;t see a way to avoid that. But surely looking forward to. > > I have seen many similar implementations and most of them suffer from > this issue. But surely there can be a way to optimize it, if not avoid > it. The way ext4_defrag works I believe is to put a lock around the inode's block list every 64MB and I assume that under that lock it has a static list of inode block pointers to work with. At the conclusion of the 64MB chunk, it releases the lock and allows writes to occur. That includes writes that extend the file. Then it locks the inode again and once again gets a full fresh list of the inode block pointers. If the file has grown between release and the next lock, then the new inode block pointer list will reflect those new blocks as well. I think you said ext4_defrag() is using 2 different locks. Maybe one is just to stop updates to the inode data block pointers, and the other is finer grained and deals with individual blocks being locked? That would make me happier and seems like a more reasonable implementation than locking the file for all writes for the full 64MB move. This brings up a question. Are you always "moving" a data block, or do you have a test in the loop to verify it is not already on the correct teir of storage? 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
