On Sep 11, 2014, at 1:48 PM, TR Reardon <thomas_reardon@xxxxxxxxxxx> wrote: > Picking this back up. How would O_TMPFILE avoid races? It definitely avoids the unwanted mtime/atime update, but then the existing "<filename>.defrag" pseudo-lock file would no longer be available. How could you use O_TMPFILE and still avoid multiple defrag? If this isn't possible, then resetting the parent times on unlink(tmpfile), as you suggest, is the simplest way out of this. Looking at this the opposite way - what are the chances that there will be concurrent defrags on the same file? Basically no chance at all. So long as it doesn't explode (the kernel would need to protect against this anyway to avoid malicious apps), the worst case is that there will be some extra defragmentation done in a very rare case. Conversely, creating a temporary filename and then resetting the parent directory timestamp is extra work for every file defragmented, and is racy because e4defrag may "reset" the time to before the temp file was created, but clobber a legitimate timestamp update in the directory from some other concurrent update. That timestamp update is always going to be racy, even if e4defrag tries to be careful. Cheers, Andreas >> From: adilger@xxxxxxxxx >> Subject: Re: possible different donor file naming in e4defrag >> Date: Fri, 15 Aug 2014 23:04:21 +0200 >> To: thomas_reardon@xxxxxxxxxxx >> >> The reason the donor file is created in the same directory as the source is to try and keep the block allocation policy consistent with the original inode. >> >> You may not need a SIGINT handler, since the timestamp could be reset as soon as the file is created and unlinked. >> >> It may also be possible to use O_TMPFILE on newer kernels to create the donor file to avoid any races? >> >> Cheers, Andreas >> > > Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
