All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kazuya Mio <k-mio@sx.jp.nec.com>
To: Andreas Dilger <adilger@sun.com>
Cc: linux-ext4@vger.kernel.org, Theodore Tso <tytso@mit.edu>
Subject: Re: [PATCH 2/2] ext4: update donor file's ctime/mtime
Date: Wed, 14 Oct 2009 10:49:34 +0900	[thread overview]
Message-ID: <4AD52E2E.80404@sx.jp.nec.com> (raw)
In-Reply-To: <EE52B431-D993-47A3-B914-5FE2ACE953B8@sun.com>

2009/10/10 2:20, Andreas Dilger wrote::
> 
> On 8-Oct-09, at 02:04, Kazuya Mio wrote:
> 
>> EXT4_IOC_MOVE_EXT changes donor file data, but doesn't update 
>> ctime/mtime.
>> This patch fixes this problem.
> 
> I would argue that just migrating the file data shouldn't update the 
> ctime/mtime.
> Those are used to determine if the file has changed in some way, usually 
> for the
> purpose of backup.  Migrating the data does not change anything from the 
> user-space
> POV and shouldn't force a new backup of the file.

EXT4_IOC_MOVE_EXT always changes the original actual contents of donor file
if orig file and donor file aren't the same. It may be that some of
user-space implementations hide such a changing. For example, e4defrag
unlinks the donor file, and removes it by decreasing reference count after
calling EXT4_IOC_MOVE_EXT. But from the ioctl point of view,
EXT4_IOC_MOVE_EXT doesn't know whether donor file will be removed or not,
so I think we should update ctime/mtime.

Am I missing something?

Regards,
Kazuya Mio

  reply	other threads:[~2009-10-14  1:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-08  8:04 [PATCH 2/2] ext4: update donor file's ctime/mtime Kazuya Mio
2009-10-09 17:20 ` Andreas Dilger
2009-10-14  1:49   ` Kazuya Mio [this message]
2009-10-14 18:10     ` Andreas Dilger
2009-10-14 21:19       ` Greg Freemyer

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=4AD52E2E.80404@sx.jp.nec.com \
    --to=k-mio@sx.jp.nec.com \
    --cc=adilger@sun.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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.