On Fri, Sep 07, 2018 at 09:27:28AM +0530, Lakshmipathi.G wrote: > > > > One question: > > Why not ioctl_fideduperange? > > i.e. you kill most of benefits from that ioctl - atomicity. > > > I plan to add fideduperange as an option too. User can > choose between fideduperange and ficlonerange call. > > If I'm not wrong, with fideduperange, kernel performs > comparsion check before dedupe. And it will increase > time to dedupe files.
Creating the backup reflink file takes far more time than you will ever save from fideduperange. You don't need the md5sum either, unless you have a data set that is full of crc32 collisions (e.g. a file format that puts a CRC32 at the end of each 4K block). The few people who have such a data set can enable md5sums, everyone else can have md5sums disabled by default. > I believe the risk involved with ficlonerange is minimized > by having a backup file(reflinked). We can revert to older > original file, if we encounter some problems. With fideduperange the risk is more than minimized--it's completely eliminated. If you don't use fideduperange you can't use the tool on a live data set at all. > > > > -- > > Have a nice day, > > Timofey. > > Cheers. > Lakshmipathi.G
signature.asc
Description: PGP signature
