From: Andreas Dilger <adilger@dilger.ca>
To: TR Reardon <thomas_reardon@hotmail.com>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: possible different donor file naming in e4defrag
Date: Thu, 11 Sep 2014 15:19:44 -0600 [thread overview]
Message-ID: <25905DD3-CD3E-42F2-A101-715E7C205CEB@dilger.ca> (raw)
In-Reply-To: <BAY179-W923915B59A3302CF7A1CB0FDCC0@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 1903 bytes --]
On Sep 11, 2014, at 1:48 PM, TR Reardon <thomas_reardon@hotmail.com> 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@dilger.ca
>> Subject: Re: possible different donor file naming in e4defrag
>> Date: Fri, 15 Aug 2014 23:04:21 +0200
>> To: thomas_reardon@hotmail.com
>>
>> 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 #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2014-09-11 21:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-15 20:12 possible different donor file naming in e4defrag TR Reardon
2014-08-15 20:39 ` Darrick J. Wong
2014-08-15 20:45 ` TR Reardon
2014-08-15 21:04 ` Andreas Dilger
2014-09-11 19:48 ` TR Reardon
2014-09-11 21:19 ` Andreas Dilger [this message]
2014-09-11 22:49 ` TR Reardon
2014-09-11 23:03 ` TR Reardon
2014-09-12 19:41 ` Andreas Dilger
2014-09-13 20:23 ` TR Reardon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=25905DD3-CD3E-42F2-A101-715E7C205CEB@dilger.ca \
--to=adilger@dilger.ca \
--cc=darrick.wong@oracle.com \
--cc=linux-ext4@vger.kernel.org \
--cc=thomas_reardon@hotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.