Firstly, I would like to congratulate everyone for pulling the conversation this long - this is the 100th element in this thread....and my gmail is getting slower... Anyway....way back 10 years ago....it is common practise both in Unix/AIX/Oracle database world....that harddisk reorganization/defragmentation is always done by just creating a new disk, and moving all files to the new disk.....files will automatically get created contiguously......that solved the defragmentation problem. In all these attempt at doing things the new ways, do we have any performance figures that it is better that the simple old way? On Tue, Jan 20, 2009 at 2:58 AM, Greg Freemyer <greg.freemyer@xxxxxxxxx> wrote: > On Mon, Jan 19, 2009 at 7:10 AM, Manish Katiyar <mkatiyar@xxxxxxxxx> wrote: > <snip> >> >> Here is a link to ext4 defrag design. >> >> www.kernel.org/doc/ols/2007/ols2007v2-pages-179-186.pdf >> >> Thanks - >> Manish > > Very, very interesting. > > The 3 key things I saw were: > > 1) The order of the steps outlined in section 3.2 > > (a) Read data from original file to memory page. > (b) Swap the blocks between the original inode > and the temporary inode. > (c) Write data in memory page to new block. > > Need to look at the actual patch and see where / how they copy the > data between the blocks. And I'm curious what "Write data ..." really > means. I suspect they mean to allow the block queues etc. to process > the data out to the drives. > > 2) Jan Kara. "[RFC] Ext3 online defrag," > http://marc.info/?l=linux-fsdevel&m=116160640814410&w=2. > > I was not aware of that patch. > > I followed this patch forward and found that Takashi Sato (the > ext4_defrag author) modified the patch and resubmitted in Dec. 2007. > I don't think it was accepted for inclusion and Takashi Sato seems to > have moved his efforts to ext4 after this. > > See http://marc.info/?l=linux-fsdevel&m=116531832022541&w=2 > > Might be an excellent source of implementation details as the ext2 / > ext3 effort moves from proof-of-concept to trying to get it in shape > for merging into mainline. I still suspect OHSM will not be > considered for ext3. And like Takashi Sato's effort, it will need to > be updated to be for ext4 prior to being accepted. > > 3) Jan Kara. "[RFC] Defragmentation interface," > http://marc.info/?l=linux-ext4&m=116247851712898&w=2. > > As I understood the OLS paper, this interface was proposed, but then > abandoned. ie. At the end of section 6 "Therefore this discussion has > gone away." So, much to my surprise the ioctl() approach was > initially shot down, but has somehow survived to still be part of the > ext4_defrag() patch. > > Reading the thread initiated by 2) leads to: > http://marc.info/?l=linux-fsdevel&m=116161573226826&w=2 > > Which is comment about how XFS does its online_defrag. Worth noting > somewhere so that in a year or two if you decide to implement this for > XFS, you have a starting point for it too. > > 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, Peter Teoh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
