Hi Greg, On Thu, Jan 15, 2009 at 5:13 AM, Greg Freemyer <greg.freemyer@xxxxxxxxx> wrote: > <snip> >>> >>> I again wonder if the ext4_defrag logic uses it? If so, HSM could >>> leverage their design and basically piggy back on top of it. But only >>> for a ext4 implementation. >>> >> Makes sense. >> Yes, We have started analysis this. We will update you on this too. >> I think, it should be helpful for us. > > My 2.6.28 kernel does not have ext4 defrag in it. > > I found it posted to the ext4 mailing list at the end of Sept. > > http://kerneltrap.org/mailarchive/linux-ext4/2008/9/27/3427244 > > The first patch in the series has the entry point ext4_defrag() in it. > They invoke ext4_defrag() via ioctl. > > https://kerneltrap.org/mailarchive/linux-fsdevel/2008/9/27/3427104 > > Per the comments each call to ext4_defrag() defrags 64MB of data by > allocating a 64MB contiguous group of blocks to a temporary inode and > copying the data from the original into the new data blocks, then > swapping just those blocks back into the original inode's block list. > > ext4_defrag() is holding the inodes mutex (lock) for the entire 64MB copy. > > I gather that the ioctl call returns to user space after each 64MB is defraged. > I have looked into the patch, its true that ext4 defrag holds lock for the entire duration of 64MB copy. But i see that it holds both mutex and semaphore locks. We hold lock for the entire duration of reallocation of a file. > Looks like there are some refinements to what has been discussed for > OpenHSM, but nothing overly significant. > > In a very real way it seems to me that the ext4_defrag() should be > generalized to allow multiple block allocation algorithms to be > implemented. The rest of the code is likely identical between what > ext4_defrag() needs and what OpenHSM needs. > > It might warrant ext4_defrag() being renamed to something like > ext4_file_reorg() and then pass in the type of block allocation > strategy to invoke. > > I suggest someone on the OHSM team should post a reply to the ext4 > Sept. post and just let the ext4 team know a little of what you are > working on. I doubt they will modify the patch at this point, but it > is a good idea to let them know that their architecture can be put to > broader use than they may be thinking. > We would definitely like to inform ext4 guys. At present we are totally into ext2/ext3, we are not familiar with implementations of ext4, so it will take some time. And as far as i see we have similar algorithm, only difference is that ext4 defrag use pages and we use buffer heads. > At a minimum the ABI for the ioctl should be flexible enough to allow > OHSM to use the same ioctl and not cause the ext4 userland tools to > have to change. > > 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
