On Thu, Sep 3, 2009 at 1:13 AM, Peng Tao<bergwolf@xxxxxxxxx> wrote: > Hi, Greg, > > On Thu, Sep 3, 2009 at 4:59 AM, Greg Freemyer<greg.freemyer@xxxxxxxxx> wrote: >> Peng, >> >> I have not looked at the code very closely, but can you tell me where >> a file corruption can take place? Not completing the replacement of >> extents with donor extents is one thing. Corrupting the original file >> contents is another. > The file corruption is mainly because of the half done replacement. > > My test case is here: > http://marc.info/?l=linux-ext4&m=124992522305319&w=2 > > With Akira's previous patch > (http://marc.info/?l=linux-ext4&m=124937430627867&w=2), > EXT4_IOC_MOVE_EXT does not panic the kernel any more. But it leaves > the orig file's extent tree corrupted. Is this highly repeatable, e4defrag using EXT4_IOC_MOVE_EXT corrupts sparse files? If so, it seems like a pretty major bug that will be exposed to userspace when 2.6.31 goes final. It seems to me at a minimum a Kconfig option should be added to enable the ioctl to userspace and that it should have depends on EXPERIMENTAL and default to NO for now. We don't want people thinking that this feature is stable in 2.6.31. Greg -- Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer Preservation and Forensic processing of Exchange Repositories White Paper - <http://www.norcrossgroup.com/forms/whitepapers/tng_whitepaper_fpe.html> The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
